Home » Posts tagged 'Teams' (Page 2)

Tag Archives: Teams

Save Money On Common Area Phones with Microsoft Teams Direct Routing

Now that Direct Routing has been released on General Availability worldwide for Microsoft Teams it is a very exciting time for Microsoft Cloud UC. Aside from the obvious benefits of Direct Routing such as migration path, investment stretching and interop with other systems, it does offer some interesting alternatives to Microsoft’s cloud native offering for those that perhaps have budget constraints.

When evaluating cloud licensing offerings for different use cases, one thing that stood out was the Common Area Phone license. It’s £6 per device plus a calling plan. Add this to the cost of a Skype for Business Online certified phone the cost per unit would be quite high for a device that wouldn’t be used that often. The most common Skype common area phone is the Polycom VVX 301 at £100-£120 per unit, add that to the licence cost £6 for the CAP SKU and £9 for the simplest calling plan licence and you have a monthly commitment of £15 per month or £180 per year. Now multiply that by a few hundred that you may have in your business, you realise that this is quite a substantial investment.

If your deploying Direct Routing then you have an alternative option.

Most SBCs that you’ll buy will come with the ability for local SIP registration subject to a nominal licence fee. You can use this feature for your common area phones. Instead of creating a common area phone account in Office 365 and consuming a licence, create a SIP account on the SBC for the device instead. This allows the phone to register directly to the SBC instead of Microsoft Phone System. The benefits of this mean that you now open yourself to the market of standardised SIP devices such as the SNOM D120 which is about £50 per device as you do not need certified Skype for Business or Teams devices for this.

There are some draw backs of course:

  • Not being able to search the address book
  • Not being able to see a user’s presence
  • No HA or DR – SIP registration is to a single SBC only without failover

But when you look at the usage of a common area phone, in most cases, the person that is using it already knows the number they wish to dial. However, you can use Microsoft Phone System features to provide a directory service to these common area phones

Create an Organizational Auto Attendant in Office 365 that is configured to search the company directory by name and use voice recognition. Create a transformation rule on the SBC to transform a speed dial into the OrgAA phone number and route that through your existing Direct Routing SIP trunk to Microsoft. Then when a user needs to find someone, they can dial the speed dial from the common area phone, speak the name of the person they want to contact and the OrgAA will search the GAL and connect you to that person. No need to remember their number and it often takes the same amount of time, or less to do this than using the dialpad to search the GAL from a SfB phone.

Normal PSTN calls can be routed out of the SBC as normal.

But what if a Microsoft Teams user needs to dial a common area phone? Sometimes this is necessary depending on what you are using the CAP for. So, in order for them to be able to search the GAL for the CAP account you create a contact object in your AD and sync it to Office 365 with the phone number of the CAP. Then create a voice routing policy that routes calls to the SBC over the Direct SIP Trunk.

This solution means that you do not need to purchase the Common Area Phone Office 365 licence or a calling plan.

Direct Routing in Microsoft Teams Could Spark the End to Cloud Voice

Up until now if you wanted cloud voice provided within your Office 365 tenant you had a choice, calling plans and consume Microsoft’s Cloud Phone System, use Cloud Connector Edition to connect your on-premises PSTN investments to the cloud, or hybrid voice if you had an existing Skype for Business Server implementation.

When investigating which one of these three scenarios to implement, you’ll quickly realise that neither option is that silver bullet that is going to see the return on investment you hoped for by consuming cloud.

Microsoft’s cloud only solution is really quite expensive when you start to scale that out to all your estate. It also has holes in coverage, being that it is only available in 9 countries worldwide. For me, the calling plans offered by Microsoft are not good value for money.  They are not flexible in that you pay for an amount of minutes per user, whereas traditional PSTN providers charge an amount of minutes per site / contract typically.  For instance, your business may consume 30,000 minutes per month over 50 consumer users. This works out at 600 minutes per user. To accommodate the users and consumption requirements in Microsoft, you would need 50 calling plans, 1 per user. Each calling plan in the UK gives you 1200 minutes per month, so that’s double the capacity of what you need i.e. 60,000 minutes worth of available usage. So you are paying for 50% capacity that you will never use. Now the cost, Microsoft calling plan vs telco contract may mean the actual monetary cost is less than 50%, but in all likelihood, your on-prem telco solution is more competitive. The question then turns to other organization benefits by moving to cloud only, if they can offset the investment or not.

The feedback I have received from customers is the perception of calling plans is prohibitive to be a complete replacement of on-prem telephony solutions. Therefore, they look for hybrid solutions.

Cloud Connector Edition is free and inclusive to the Phone System license. This allows that hybrid connectivity between your PSTN and the Microsoft Phone System so that existing investments can be realized by the business. The idea of this was sound, the execution, not so. CCE required dedicated hardware, it could not be collocated on existing hardware investments. Furthermore, it was hyper-v only, which for vmware only businesses posed a supportability challenge. If that wasn’t enough, it required Windows Server 2012 R2 Datacenter edition due to the number of VMs required, bringing the cost of a CCE solution from free to somewhere in the region of $20,000 or more.  When considering HA for CCE, this doubled the cost of the solution for each site. An org with 5 sites, that’s near $100k outlay for a solution that the business does not own in perpetual terms.

From the feedback I received, this solution was not really viable for companies, within the UK at least. The reasons given where cost, but more intriguingly, lack of confidence in Microsoft. When explored further, the agile approach that Microsoft is taking towards the cloud and changing products (SfB to Teams for instance) made customers nervous. They didn’t want to invest 100k into a solution the vendor themselves do not believe in because they’ve brought in a completely new UC solution in that of Teams. Customers, just felt CCE was clumsy and had a short shelf life. And they have been proved right in a way, even though CCE and SfBO remain potential solutions today with no sign of end dates as yet.

And then we have businesses who have some on-prem SfB infrastructure. Do they configure hybrid voice knowing that the long term strategy of Microsoft is Teams and not SfBO? At the moment there is no hybrid SfB Server and Teams coexistence story, the islands approach is messy in organizations where the demographic is split between on-prem and cloud SfB. Businesses are looking for a good story and experience with full support for interoperability whether that is for transition, or end state. But in order to consume on-premises PSTN connectivity with Teams when an org already has SfB enterprise voice is no small task. Firstly it is not supported, second the alternative in Direct Routing is possible, but there are some significant reconfiguration challenges at the SBC level which will take a lot of time and effort to implement. And time = money.

As you can see, there are challenges with each of the current solutions above. Now add in the network variables, in cloud only voice, we are relying on internet connections to deliver enterprise grade call quality. We know that is not going to happen consistently and there will be regular challenges to overcome. The alternative is Express Route, which carries some considerable cost plus the complexity of deploying it into your network. CCE mitigated this with media bypass support as well as SfB server hybrid. But for all cloud users, the internet connection is on the critical path and will forever be a problem to some degree or another.

The other quite significant problem with cloud only voice is reliability. There have been some quite significant outages with voice services in Microsoft over the last 2 years and companies tend to have long memories. These outages stick inside people’s mind. We all have outages, but when your entire business is invested into a single solution and that is not available, it becomes a problem. Where voice is concerned, this is a very big problem compared to an outage to a SharePoint site for instance. So the trust that the service is fit for purpose is probably not where it needs to be for cloud voice to really take off.

These are the challenges Microsoft face as I see it. I don’t envy them, but I do respect them for giving this one serious go. And all in, the voice offering today coupled with the collaboration functionality is market leading, there is no one out there with this level of integration between communication, collaboration and productivity. It is an enterprise class solution.

But, and here is the rub. Cloud voice is simply dead.

Strong statement I know. But let me explain. It is acknowledged that calling plans aka cloud voice is expensive. But hybrid solutions done right are more compelling and cheaper (most of the time). You want people to use your cloud? Allow them to hook up what they have now and use it in your cloud. Simple.

CCE was the attempt, Skype for Business Server probably doesn’t have the place in the hybrid cloud world that it once had, and if you’re looking for a integrated communication and collaboration tool, then Microsoft Teams is your only real solution today. Sure, there are others, but when you drill down and assess your goals, you’ll realise in most cases the competitor products are no more than PoC or small scale projects that never really take off in the direction you thought.

Direct Routing is a game changer for Microsoft Teams and hybrid voice. It is the cloud voice killer in my opinion. The future is hybrid voice. Quite simply I cannot see it being any other way.

Direct Routing allows you to connect to Microsoft Cloud using nothing more than a SIP trunk and an SBC. CCE and SfB Server no longer play any role in the hybrid voice journey for Microsoft Teams. And this is a good thing, because it opens up all kinds of opportunities.

The benefits of Direct Routing are huge:

  • I can leverage my existing investments in PSTN connectivity and see out my contracts
  • I can use it to negotiate better contracts vs calling plans or vs existing contracts
  • I can integrate to legacy PBX worlds and other voice technologies I may have on-prem with ease
  • I can use it as a way to consolidate existing PSTN connections to better increase my savings
  • I can move a user’s number between PBX and Teams or vice versa without significant disruption to the user, or admin overhead (porting numbers etc.)
  • I can preserve dialling habits of the users so they don’t have to learn new ways of dialling the same destination
  • I can arrange PSTN coverage in countries that Microsoft do not have PSTN presence in
  • I can enable a site with minimal investment and at speed
  • I can configure inter-site HA and DR
  • I can configure least cost routing
  • I can connect to perimeter devices, fax, analog etc.
  • I can maintain good voice quality because the majority of my media stays local to my LAN and I can implement QoS end to end
  • I don’t need express route
  • I can consume Direct Routing as a Service
  • I can guarantee service availability

Perhaps the most intriguing possibility is Direct Routing as a Service (DRaaS) and this really carries several nails in the cloud voice coffin. As a business my objectives are: maintain service availability, provide adequate tools for the business to function and achieve these with the minimum investment.

Why take on the responsibility between PSTN and cloud by owning your SBC and Direct Routing trunk when someone else can do this for you?

Wouldn’t it be great if your carrier can say to you, don’t worry we can provide all you need to connect to Microsoft Teams under your contract with us?

That to me is the most exciting part of the Microsoft Teams hybrid journey, the ability to be so flexible in how to use Direct Routing to suit the business needs and financial constraints is one of the best reasons to consider Microsoft Teams as your default communication platform of the future.

Personally, with Direct Routing being available, I wouldn’t consider Microsoft Cloud Voice with calling plans as a long term solution to my business at least. I think it has its place, rapid enablement if you have an acquisition, a temporary solution until something permanent comes in like Direct Routing.

But you’re about to comment on this article and say Mark, you’ve forgotten that the world is now an agile place. I haven’t forgotten.

Everything up to now has been written in the context of an organisation with a lot of investment in site infrastructure and the majority of employees work from one or more of their sites. For these organisations, Direct Routing is a no brainer, and the default approach that should be considered in most cases.

For startups and organisations transitioning to an agile working strategy, encouraging working from home, or from a shared co-worker office space who have very little in the way of on-premises staff, then cloud voice delivered 100% by Microsoft should be the solution for them. The perceived cost of the calling plans is therefore offset by the reduction in overheads of property, utilities, equipment such as desks, chairs, lockers etc. employee services e.g. canteen, cleaners, maintenance and reduction in ICT support structures. For these organisations, cloud voice albeit on a apples vs apples comparison is more expensive generally than using on-prem, comparing the investment vs having to implement all that infrastructure to support on-prem working, the organisation is still saving a shed ton of cash by investing in Cloud voice.

So perhaps I revisit my blog title and say for organisations that are inherently site based, Direct Routing is a no brainer and a potential cloud voice killer.

For organisations that work in an agile manner, i.e their workforce is predominately remote to the office, then cloud voice is the solution for them and Direct Routing is not a consideration in many cases.



Considerations for Microsoft Teams Direct Routing

Microsoft released Direct Routing to Public Preview last week (15th May 18) for Microsoft Teams. We as a Microsoft UC team seems to be incapable of choosing a decent name that clearly identifies our products without having to Bing first… It also has a very confusing acronym, DR. C’mon DR means Disaster Recovery to so many that it’s going to be hard to keep the context if we in UC start talking about DR as in Direct Routing.

Direct Routing, for those Binging what this is, basically is a SIP trunking service provided by Microsoft that allows you to connect your existing PSTN connections to Microsoft for use within Microsoft Teams as a PSTN voice route.

This is a preview service at the moment and probably not the finished product, but if history is anything to go by public preview is basically 98% of the version 1 product released to GA.

If you are considering Direct Routing for your business then there are a few things that you need to consider when evaluating whether Direct Routing is right for you.

Firstly, this service is a welcome addition to the Office 365 product family, a simplified service for the customer that is easily accessible and relatively cost efficient, without the complexity of its predecessor Cloud Connector Edition.

Cloud Connector Edition was really considered a failure by the majority of professionals out there, it was a hacked version of Skype for Business that provided an easy way for Microsoft to connect to on-premises PSTN without too much investment on their side of things, by leveraging what was already available through federation to make the connection. The idea was sound, the way in which it was offered was its downfall. It was marketed as an appliance, but the customer had to provide the hardware and the base operating system licence. The appliance required 4 virtual machines which mandated Windows Server 2012 R2 Enterprise Edition, which compared to Standard Licence was really expensive, so even though Microsoft insisted Cloud Connector Edition was free and inclusive in your Office 365 licencing SKU, the total cost of ownership was far from free.

Microsoft’s decision to focus on Teams has probably saved the hybrid voice project from a Microsoft and customer standpoint by simplifying the connectivity to the cloud. Direct Routing is a SIP trunking service, so Microsoft provide SIP endpoints in their cloud for customers to connect their on-premises SBC to with little more than the cost of a SSL certificate. It’s a massive win for Office 365 hybrid voice and this is how Skype for Business Online should have done it.

However, as with any product, there are caveats, and at the moment there are a couple of potentially large ones, especially if you’re a customer with existing investments in technology that is not on the supported list for Direct Routing. By this I mean, if you think you can connect your existing Cisco or Avaya to Direct Routing without any additional investment, you will probably find that you are going to have trouble at best, or it won’t work at all. Currently Direct Routing is supported on Ribbon (Sonus) and Audiocodes Mediant SBCs. These SBCs require the most recent firmware version, for Sonus this is Edge 7.0.2. So you will need to invest in some hardware, or use the virtual SBCs available from either vendor. I’ve no doubt that other vendors will offer the same connectivity, but as for now, these are the two certified vendors.

To connect to Direct Routing, you will need an SSL Certificate on your SBC with the common name set as the SBC public FQDN, or at least a SAN entry. You’ll also need to install the Microsoft Balitimore root certificate. The details of how to set up and the requirements are well documented on Microsoft and Vendor support sites, so I will not be reinventing the wheel in this post. Connectivity is made over the internet and at the moment I don’t believe Direct Routing is supported on Office 365 or Azure Express Route, even though the Microsoft POPs are located in Azure. Don’t quote me on this as I’ve yet to get a definitive answer from Microsoft on this, but the safe assumption is that at the moment, probably not.

This leads to the first consideration. Usually when connecting to a SIP provider you’ll want to use dedicated lines for voice to your provider. Microsoft want you to use the internet. PSTN calls are going to be using G.711 and this is not an adaptive codec like SILK, so the connection needs to be stable. You’re not going to get this over the internet. If Express Route is not supported, there is no way to guarantee this connection to Office 365, not QoS policy can be applied. Express Route would be the likely requirement to provide the dedicated, controlled and consistent connection, but even if it is supported, implementing it purely for Direct Routing would be expensive, to the point where you may as well use Microsoft Calling Plans, it’ll be cheaper. However, this may not be a big issue, Microsoft have said that Media Bypass will be supported with Direct Routing. However, for Sonus users version 7.0.2 does not support Direct Routing Media Bypass. Version 8.0 will be required for that and that’s a few weeks off yet. The jury is still out if Media Bypass is the silver bullet to the internet media issue that has been plaguing hybrid voice ever since it was first whispered, it largely depends on how multi-party and user hybrid scenarios work. For instance, a Direct Routing user with delegates with Calling Plans, can the calling plan users use Media Bypass? We will have to see.

The second consideration is what you want Direct Routing for, on-premises at least. If you’re looking to procure a cheaper alternative to Microsoft Calling Plans, then you’re probably best to go and speak directly with SIP providers such as PureIP. Thinktel in Canada are the reference and they offer Direct Routing as a Service purely for this type of reason, cost efficiency. The only reason why you’d want Direct Routing on-premises is if you want to connect existing on-premises PBXs to Microsoft Office 365 for internal extension dialing. Again, consult with the SIP providers as they may be able to “as a service” this connectivity too. The idea is to get the best connectivity at the most efficient price for the business. Should you have Direct Routing SBCs at each site? Probably not, if your on-premises PBX can utilize your WAN for cross site connectivity, then you’re probably best to evaluate if a centralized deployment is feasible. Obviously considerations on bandwidth and other networking impairments will need to be investigated before this model is chosen.

Direct Routing does provide a lot of flexibility to Microsoft Teams voice. However, there are some restrictions right now that make the decision on whether a user is a Direct Routing user, or Microsoft Calling Plan User.

Currently, Direct Routing does not support service number usage. So this means you cannot use Direct Routing for Call Queues or Organization Auto Attendant. This is not so much of an issue right now, because neither does Teams. However, at the moment the if you want users to answer calls from a Call Queue, they need to be Skype for Business Online users for voice and therefore, cannot be a Direct Routing user as well.

This leads to the next point. Even though you use Skype for Business Online PowerShell commandlets to enable Direct Routing, you cannot use Skype for Business Online client as the voice endpoint for the user. This MUST be Teams client. I think this is purely a strategy decision by Microsoft as the technology and method seems to suggest this is nothing more than a policy restriction.

When users are enabled for Direct Routing, they don’t need a Calling Plan. However, if they want to use Audio Conferencing they will need the Audio Conferencing licence. This will permit them to use the Microsoft Audio Conferencing Service like a normal cloud user today. However, if they need dial out in conferencing, they will also need to be assigned the Calling Credits licence as dial out does not use Direct Routing, but Microsoft ACP service instead.

Direct Routing only users are able to use extension dialing to on-premises PBX subject to the correct routing capability on the SBC. Users who have Calling Plans and numbers acquired in the cloud can also use Direct Routing voice routes for the same or for PSTN calls that need to egress out of a local gateway for whatever reason, e.g. least cost routing, toll bypass (kind of) type scenarios.

Direct Routing users must have a number that terminates on-premises, they cannot be assigned a number from the cloud, ported or otherwise.

Common Area Phones, and any other 3PIP phone cannot be used with Direct Routing at the moment. This is largely due to the fact that Teams does not yet support these devices. Teams native phones, should be able to use Direct Routing. This is an assumption based on the routing policies enforced by Microsoft.

I’d expect Direct Routing users to also be capable of adding Calling Plan users as Delegates and Team members for call forwarding, but I haven’t been able to test this scenario yet.

High Availability can also be supported using Microsoft POP connectivity, Voice Routes and SBC to SBC interconnection. Microsoft have POP locations in Europe, America and Asia. You can prioritise the POP used for connectivity based on your location, so you can be sure to use the most optimal POP for your location until it goes down. POP availability is monitored by SIP OPTIONS on the SBC. If this is down, then the SBC will use the next POP location.

In the user’s voice routing policy you can specify which SBCs you want the call to be routed to. These are selected using round robin, so both SBCs need to be able to route the call if requested and online. If this is not possible and you can only run in active/passive mode for your SBC connectivity, then in PowerShell you can mark the gateway as offline so that the voice routing policies are configured ready to support HA/DR (Disaster Recovery), but in BAU, they are going to use only the primary SBC. In the event of a situation, the disabled SBC can be enabled in PowerShell and the broken one disabled and all users are restored without touching their individual configuration.

SBC to SBC interconnection is a method used to control PSTN connectivity HA/DR (Disaster Recovery) – see my issue here with acronyms… If the primary SBC loses connectivity to the PSTN, Microsoft Teams isn’t going to be aware of that. To that, the SBC is still very much alive and capable of accepting calls. However, the external calls will not be routed because the PSTN connection is down. Internal calls will still work as intended. In this scenario, the SBC would terminate the call and the user would have to place the call again and hope they got an alternative SBC. To improve user experience, you’d create a failover route on the SBC so that if the PSTN connection was down on one SBC, the SBC would attempt to re-route the call to another SBC where PSTN connectivity is available. The end result to the user is that calls are uninterrupted.

I hope this is useful for anyone considering Direct Routing at the moment.


Phantom Presence Issues in Skype for Business when Peer is using Microsoft Teams

As people and organizations start to adopt Microsoft Teams for their day to day communication and leverage the new features such as guest access there are a couple of scenarios that I have come across that could potentially lead to people scratching their heads. Tis is especially so when users decide that they don’t need the Skype client.

Scenario 1 – Inter client Presence

In this scenario, I have seen one user (User A) using Skype for Business and another (User B) using just Microsoft Teams and not signed into Skype for Business client. User A is on Office 365 Tenant 1 and User B on Office 365 Tenant 2. In this scenario, User A sees the presence of User B in their Skype client as Available, or whatever presence is set within User B’s Teams client. To User A, User B looks to be using Skype for Business and is given the perception that they can send IMs or make P2P audio and video calls. User B however, does not see User A’s presence and appears Unknown. When User A sends User B an IM the message looks to have been sent as we receive no error within the chat window to tell us otherwise. However, User B does not receive the IM. Similarly User B does not get a missed message or offline message in their Exchange mailbox to say that User A had contacted them. The message just disappears into the ether.

Similarly if User A tries to place a P2P call whether it is audio or audio and video the call fails as we would expect. Again User B is not sent a missed call notification.

The problem here is that unified presence is giving a false representation to the Skype for Business user which will lead to frustration and a trouble ticket that will send the service desk right down the rabbit hole into wonderland!

Scenario 2 – Guest inter client Presence

This scenario is similar to the one before, however, in this case User A has been granted guest access to User B’s Team. User A again uses Skype for Business client only, and User B the Teams client only. In this scenario, presence is again seen by User A, and when they send an IM to User B the IM delivers to the teams client of User B! However, User B still sees no presence information for User A. User B can though reply to User A in this scenario using their Teams client and can have a one to one chat. Enriching chat with file sharing doesn’t work or add another party into the conversation. Also in this configuration, only User A can initiate the conversation.

Calling between clients seems to be possible because the call control buttons are clickable, however, they will fail from both sides (User A and User B initiated calling).

I know Microsoft are working on interop and this experience will become better as development continues and matures. For now though I wanted to call these two scenarios out to avoid hours of painless and fruitless troubleshooting an also stress the importance of running both Skype for Business and Teams clients side by side until interop has been released properly.

Plan to Move Your Skype for Business Workload to Microsoft Teams

Now that Ignite is coming to an end and all the hearsay has turned into fact, I wanted to gather my thoughts and formulate an opinion and recommendation on the impacts of what’s been announced. Microsoft’s announcement to concentrate on Microsoft Teams as the cloud offering as the unified communications platform going forward has been met with both enthusiasm and bewilderment across the IT spectrum. It seems that unified communications is now done with and enter intelligent communications that leverage the power of cloud AI and service based workloads. I joked before Ignite that the saying “Let me Skype you” will disappear to “Hey I’ll Teams you on Teams”, just doesn’t sound right. But now perhaps its more “Hey IC You!”… nevermind, i’ve never really cracked the dad joke scene..

I am not going to go into detail as to what is coming to Teams and all that, it’s been well covered in Ignite sessions and fellow blogs. I want to strip back all the hype around it and discuss the enormous challenge that Microsoft has laid out for itself and us as well. Seeing new ideas, new tech and the cloud evolve is great for cutting edge innovation that has the WOW factor, but the harsh reality of enterprises means that this innovation and in particularly the speed of it often raises more worrying questions than positive ones. Before we look at this, I am a supporter of Microsoft Teams, and I can see real benefits of what Microsoft are doing with it in the cloud. It makes sense. But it has put legacy UC into the washing machine on full spin, because the fact is that most of us aren’t quite ready for IC just yet. Although if you waited for people to be ready, then you’d never push the boundaries. However, having said that I do feel that this move to Microsoft Teams is a bit premature. Not so much the strategic decision, but more the marketing message timing has only added confusion rather than clear understandable direction. In my view, the sensible approach to the strategy would have been to continue developing Teams capabilities and releasing them without the fanfare of Ignite 2017. At a point that Teams had comparable capabilities with Skype for Business Online, it would then make sense to broadcast the messaging to the world. In my opinion the earliest that this should have happened would be probably Enterprise Connect 2018, possibly Ignite 2018.

The reason for this is that enterprises would slowly see the direction Microsoft are taking and would have time to adjust their approach with more comfort. Yes, by the time Microsoft officially announced the direction it would not be so impactful, but at least enterprises would have more context and be prepared. However, by announcing this now, I think Microsoft have potentially caused themselves more damage than success. The reason I think this is because Microsoft Teams is not at a point where customers can truly believe that it is the direction they should take. Microsoft have a monumental task of building not only back end but also a whole new front end application and service, an entire ecosystem if you will and through the customers eyes they haven’t even left the starting gate before announcing their plans.

This of course is not an entirely accurate statement to make. Microsoft have been dogfooding calling in Teams for a month or so, so behind the scenes they are further around the track that publicly visible, but nevertheless, enterprises judge an application based on what is supportable and generally available not preview, or preview preview. So today Microsoft says Teams is the future and Skype for Business Online is going away, leaves them worried because they have not seen the new kid on the block develop to a point where they feel the potential. Aside from this, we have been in a constant battle with customers over the last 2 years to convince them Cloud PBX is a suitable platform for their voice workload. It’s taken 2 years because enterprises never want to be the first ones to test a new service, especially where their communications are involved. At least 70% of my customers have said to me, “we want to go cloud, but it isn’t mature enough, it hasn’t got this feature or that and we just are uncomfortable with it because we don’t understand a lot about it, we want to see how it develops first”. Ok, you could argue that it is my job to convince them, and you’re right, but I will only recommend a solution to a customer that I know fits their requirements. Sometimes that is cloud, others on-premises and hybrid. But even if I convince them to go hybrid or trial Cloud PBX they go with some trepidation and struggle to commit fully to the cloud first model, for the simple reason is they cannot get over the maturity mental block.

By Microsoft declaring that people should look towards Teams instead of Skype for Business Online now, only serves to re-ignite (see what I did there?) the same concerns that we have battled to overcome over the last 2 years. To some degree I feel like we are starting again. Now factor in that Microsoft have not committed to an accountable roadmap for Teams development, how can businesses plan to migrate to the cloud or Teams without a solid roadmap that they can rely on? I was looking at a slide from ignite and it stated that if you’re a customer and you haven’t got Skype for Business Server or Online and are planning to go cloud, then you should look to deploy Teams. On one side it seems sensible, but the fact is Skype for Business Online today meets probably 90% of their requirements from a UC tool, while Teams meets about 30%. If you’re a customer who has finished or in the middle of a cloud UC transformation project this is a particularly worrying and confusing time. On one hand Microsoft are telling us to move to Teams, but teams lacks the basic features of UC like federation and more advanced stuff like advanced voice capability, you will question that direction!

Yes, all this great stuff is coming and soon, but we just don’t know if it will be next month, next year and where in next year, so how can you plan for it? If Microsoft follow tradition, they’ll announce a new feature is coming, then release it in preview, then 2-3 months later it will be GA. This often means when you plan for a Q release it ends up being Q+1 by the time your tenant has a version that is supportable. The Teams roadmap is broken down into two halves of the year, 1H and 2H. That’s 6 months guys, that is a huge window for error. How can I possibly rely on this? Again, I appreciate these things take time, which is why I am somewhat perplexed as to why Microsoft has chosen to announce this now as it seems like a right recipe for a false start.

We cannot fight the direction of the cloud. For those of us who have embraced cloud and the evergreen model, this should come as no surprise and you should be prepared to react to the ever changing fluidity of the agile cloud. However, regardless of whether you are cloud today or planning for cloud in the near future (0 – 12 months) you should be using the time to consider carefully your options.

For anyone considering Microsoft Cloud UC today, it is my recommendation that you ignore the messaging from Microsoft to look at Teams as your only UC/IC platform. Instead plan for leveraging the tried and tested platform that is Skype for Business Online. For the next 12 months at least it is going to offer you all the requirements you need from day 1 through to 365. Your investment will not be wasted as when features transition the process will be largely academic, rather than a migration from one system to another. Skype for Business Online Enterprise Voice capabilities fall under Cloud PBX. This is a separate component to Skype for Business Online today. Cloud PBX is being renamed to Phone System and Microsoft Teams uses Phone System for its enterprise voice capabilities. The same with Audio Conferencing. Therefore, if you invest in Microsoft calling plans and Microsoft Phone Numbers and have users assigned, nothing changes. If you have ported your numbers over to Microsoft and assigned them to users, nothing changes. If you have purchased Skype for Business Online compatible phones and meeting room devices, these will still work with Phone System and video will still work with Teams, nothing changes. Org AA,  Call Queues, and Voicemail these aren’t Skype for Business Online components, they are independent services built in Azure, nothing changes. Your investments are not wasted, they are just delivered to another client experience. Essentially it will be a matter of a policy change to tell Office 365 to use the Teams client for Chat and Audio rather than Skype for Business client. Of course, there may be subtle changes, we may need future firmware, DNS, Firewall updates to devices and networks as Skype for Business Online gets retired and nativity develops in Teams, but these are superficial maintenance changes rather than a full blown migration project.

However, you should not ignore Teams until the final moments of Skype for Business Online existence. Instead you should introduce Teams shortly after people have got used to Skype for Business Online to avoid confusing use cases. I’d recommend a 3 phase approach, releasing initially Skype for Business Online quick win modalities such as Chat, federation and conferencing. In Phase 2 introduce Teams with restricted functionality to group based collaboration while Microsoft develop and the roadmap becomes clearer. In Phase 3 look to migrate your voice workload to either Skype for Business Online or Microsoft Teams whichever makes the most sense and meets your requirements at the time. This approach buys you time while still pressing on with your cloud migration and leveraging the benefits of cloud. It also means that your users will understand Teams and how to use it, so that when you transition from Skype for Business to Teams, you don’t need to deliver a whole new training and adoption programme.

If you are considering using OPCH with cloud, then the announcements around Cloud Connector Edition probably means that you are somewhat confused as to wait or commit? My advice here is that if you need CCE today then look to purchase separate units rather than combined SBC and CCE appliances. Purchase your SBC and use CCE as a standalone server. This protects your investment moving the next gen phone system when Microsoft will support direct SIP trunks from your SBC into Teams. If you purchased appliances with SBC and CCE integrated, then you can still use these devices, just but only the SBC component. So long term the separate approach is probably going to work out the most sensible and cheapest solution in my opinion.

If you are a hybrid customer today with Skype for Business Server 2015 and Skype Online, the story for you is far more grey. It is likely that this story will not become clear until at least Ignite 2018, so for the moment you do not need to worry. Skype for Business Online is not going away any time soon, personally I cannot see it going away for at least 2-3 years. So you have time on your side here a little. However, you too should be looking to introduce your workforce to Teams. Again start with the quick wins and the easiest possible messaging around use cases e.g. persistent chat is now in Teams etc. Even On-Premises users can take advantage of Teams because Teams has no dependency on Skype for Business hybrid or Skype for Business Server.

Skype for Business 2019 vNext server announcement is a positive statement from Microsoft that they consider on-premises to be firmly catered for. They went so far to claim that 2019 is unlikely to be the last edition as well. This should on face value please a lot of customers that going to cloud is just not possible for them. However, there was certain messaging around vNext that implied a hard dependency on cloud features. vNext is a topic that us MVPs have been engaged with Microsoft on prior to Ignite and we worked with them to define what we see as progress and what is important to our customers. It appears that some of this has made it in to the early commit at Ignite, being that we saw massive value in leveraging cloud services included in your E5 licencing SKU for on-premises users, such as Azure Voicemail, Call Queues, Audio Conferencing and Org AA. However, this won’t be a hard dependency and there will be on-premises alternatives. I know many of you consider vNext to be a downgrade, but really who used a Director server these days realistically? I totally get the negativity around the drop of Standard Edition and this caught me by surprise. I know one server is supported but requires separate SQL which means the cost of a comparable 2019 deployment to 2015 Standard Edition is quite a jump with the added SQL licence.

The message here seems to point that if you only require a standard edition server, then probably cloud is the route you should take. However, I think there have been use cases that Microsoft have missed for enterprises who have deployed a Standard Edition server within an Enterprise topology for local branch connectivity and features. This also brings me to the next point in that they have also dropped the SBA role too. I need to wait to see how this story develops as they cannot afford to ignore branch survivability in vNext, they’ll need a solution to that, maybe they will allow you to deploy a mediation server with the registrar component in colo in vNext? Who knows but I am sure we will find out.

They also announced that vNext can only run of 2016 OS and SQL, no surprise since by the time this is released 2012 will be 6 years old. But the most concerning point was that there appeared to be no coexistence story with Lync 2013 or Skype for Business 2015. This is pretty worrying as I cannot see how you can migrate to vNext on a global deployment where a big bang approach is not possible. There is going to have to be some kind of interop story there, whether it is all done over federation or some kind of proxy or something else maybe. But clearly there is a mass of work to do on vNext and at this stage it hasn;t even made it off the cigarette packet yet.

It seems that vNext has been architected to promote your journey to the cloud, or to at least make it easier than it is today. The new cloud / on-prem aware portal is a sign of how to leverage hybrid cloud to maximum benefit. It will be your choice as to use it or not. Whatever happens, there are many unfinished stories, it will become clearer as time passes by. We should not be worried or come to premature conclusions but approach this with an open mind. I have no doubt by the time this latest plan around cloud and on-premises comes to pass we will have wondered what all the fuss was about.

Microsoft Teams – SIP IS NOT DEAD! It’s Just Somewhere Else!

I was scanning the Twittiverse for updates on Microsoft Ignite as there are various announcements coming out. Aside from the massive news that we all unofficially knew was the revelation that Microsoft Teams does not use SIP. Firstly, this is should not be a surprise to anyone as we can quite clearly tell that the audio, meeting and video experience in Microsoft Teams is based on Skype Consumer code, not LCS code like Skype for Business Server and Online are. When you research Skype consumer protocols and architecture, you release that it uses a proprietary signaling protocol and not SIP. So it is logical and accurate to determine that Microsoft Teams UC workloads use the same. However, this led to some tweets by people that perhaps misunderstood the message to be “Microsoft Teams doesn’t use SIP, SIP is Dead!”. This is completely inaccurate!

There will be a lot of people with Skype for Business phones and other video devices and room systems petrified at the thought of this statement and it sends completely the wrong message to them. To set the record straight, your SIP devices WILL continue to work with Microsoft Teams using SIP in the same way in which they work with Skype for Business Online today! Your investment is safe! Although, you may have to ensure that device firmware is updated at some point (but that’s usual even for Skype!).

To lay the context to this we must not forget that Microsoft Teams is an overlay application that uses components as services from Exchange, SharePoint, and Skype (not for business) together to create a collaboration experience for the end user. This means that each workload is not parent to Microsoft Teams specifically as a standalone application, but rather the Microsoft Teams end user client exposes the underlying service components to the end user through the Microsoft Teams User Experience as an “App” workload.

Microsoft Teams does not use Skype for Business Online at a component level. However, there is a new unified communications core hidden away in Office 365 that Microsoft Teams utilises for its audio, video and meeting experience. It is this core that is replacing Skype for Business Online and it is this core that interops with Skype for Business Online, rather than specifically Microsoft Teams as an application. This new core as I said before is built on Skype consumer code. This does not mean that it uses the Skype consumer datacenters, network or PSTN services. That is separate! It is just the code framework they have copied over to develop an enterprise grade audio, video and meeting service, that is exposed to the end user through Microsoft Teams. This is the reason why you will still see the Skype logo in your audio, video and meeting experience. This can be best explained in this simplified diagram.



So when we talk about Microsoft Teams does not use SIP, then at a technical level you are right on two points. The first point is that Microsoft Teams itself doesn’t require SIP, it is an end user UX App window that exposes different Apps such as Chat, Calling, Meetings etc. The second point is that the new Skype core service is based on Skype consumer code and therefore does not use SIP as it’s signaling protocol. Instead it uses Microsoft’s own signaling protocol called Microsoft Network Protocol version 24 or MNP24 for short. This protocol is wrapped inside a TLS encrypted TCP packet, which means, unless you have the private key for the Skype servers in Office 365, you ain’t gonna see it. However, what you need to understand is that this protocol is used between the Skype core and the App exposed with the Microsoft Teams client on your desktop. It does not replace SIP within the Microsoft Phone System. Another point to make is that the media codecs between the Skype app in the Teams client and the Skype core will be H.264 for video, SILK for P2P and Voice calls, and OPUS for meetings. But this will be only between the Skype core and the client the end user is using. At a higher level, the Skype core needs to interop with SIP, specifically the Microsoft Phone System and Audio Conferencing. The exact details of this we will never know. However, we can assume that v1 interop will be via some kind of transcoding and protocol conversion system, perhaps a software based SBC, or some other service. This allows Skype for Business Online to still leverage Microsoft Phone System and Audio Conferencing at the same time as the new Skype core. I can imagine that v2 interop will be more native and remove SIP between Skype core and Microsoft Phone System. This can only happen when Skype for Business Online has been retired.

Polycom, Yealink (and other vendor) phones and meeting room devices will maintain the 3PIP model and Open SIP standards as well as having a Microsoft Phone System profile. These devices will more than likely register themselves to the Microsoft Phone System and subscribe to the Unified Presence service using SIP, rather than directly into the new Skype core. I don’t see this changing too much, or being far from the truth on this as for every vendor to convert their firmware to MNP24 would take longer than new Skype core vNext would take to be developed. There could also be hardware limitations too, so i’d expect these to remain SIP devices and leverage Microsoft Phone System directly, rather than being new Skype devices per-say.

The following compacted diagram shows what I have explained at high level


In summary, SIP is not dead and you should not be concerned with this drift away from SIP as far as the desktop / web client is concerned. MNP24 has been in Skype consumer since 2014 and is a robust protocol. It allows Microsoft to develop their own components without the limitation of standards based protocols, which is good for development, but also carries risk around compatibility. It is confusing why a company that has spent the last 10 years promoting standards based protocols would pull a 180 when all other vendors are embracing standards. But I am sure that they know what they are doing…..

I guess a lot is still in the air and yet to sink in from Ignite. I am yet to form an opinion on the downgrade of Skype for Business Server 2015 to Skype for Business Server 2019. I need a few more nights to sleep on that first.

Microsoft Teams–Add A Team Guest as Office 365 Admin

Microsoft released Guest Access for Microsoft Teams last week, annoyingly whilst I was on holiday, so I got to miss out on all the early action! Anyway, I am back now and have been taking a look at the feature. The normal process to add a guest to a Team is for one of the Team Owners to invite the Guest to the Team using the Teams app or web client (wow! 4 Teams in a sentence – this is going to be hard!).

Giving the power to end users to add external parties to a Team is quite a privilege and I can’t wait for the post on ZDNET or The Register that is titled “Massive Data leak at Mega Corp Due to Rogue Employee adding a Competitor to a Teams Team in Microsoft Teams!” but anyway, I promised myself I would not be cynical anymore and look at the positive!

On a serious note, now that there is guest access, you should really plan your groups and channels to ensure that guest can only be added to Teams that hold non-sensitive data, but maybe that’s another blog post!

So back to the point of this post, what if you get end users that seem incapable of following a simple 3 step process guide to add a guest to the Team and want you the IT guru of mega corp to add them on their behalf? You can just imagine the service ticket; Title: “Please add Guest to My Team” Description: “Please cam you add the attached list of users to my Team”. When you open the JPEG screen capture containing the list of email addresses (yes its always a screen shot, never a nice easy excel sheet) and you have sent 5 emails, an IM conversation and a phone call to find out which Team they should be added to, how do you do it?

Well I guess the official way is to add yourself into the group and add them one by one. #Lame

However, I have been doing some testing and figured out that this can be done using Azure AD and Office 365 Groups.

First you need to invite the guest into your Azure AD instance using the Azure AD portal. You can do this by clicking Azure Active Directory > All Users > New guest user


Then add the email address (must be a valid Office 365 account). Include an optional message if you want and then press Invite


The user will get an email inviting them to your Azure AD


Now we need to add the user to the Teams Office 365 Group. After a lot of testing I have figured out that adding the user to the Group in Azure AD using this feature


DOES NOT work with Teams. However, if you do add them to the Group in the Office 365 Portal then it will work just fine. I am not sure why this is the case, I figure there must be some overlaying function that kicks off when the user is added via Office 365 portal that is missed when adding directly into Azure AD.

Next find the guest user’s account in Office 365 admin portal, it will be email_address.com#EXT#@yourtenant.onmicrosoft.com


Select the User and edit their Group Membership


Click on Add Membership and then select the group you wish to add them to and press save.


Once this is done, the guest will be able to access the Team via Guest Access after about 30 minutes. There is a lag doing it this way for Teams to catch up, but they will be notified in their client that they have been added, like so


If you added the user to the group using Azure AD, then when they access the Teams link they’ll authenticate with the guest tenant, but will have a blank Teams experience. What you’ll need to do is remove them using the Azure portal from the Group and re-add them to the Group in Office 365, and wait 30 mins. This is also the case if you follow the below method and the guest signs in before 30 minutes. So it isn’t fool proof by any means. Perhaps delaying the invitation email would be advised!

Performing this by using Powershell gives you some more options to customise, specifically the redirect URL for the Invitation sent and the display name of the user. One of the problems with Guest Access is by using the Teams app to invite Guests the display name of the person is set by their UPN you added in. This means that you can have several “Jane” and “John” users and you have no way to figure out which Jane or John you are conversing with.

By inviting them into Teams using Azure AD PowerShell allows you to customise the display name as you add, rather than a remediation task later on.

By default, the standard invitation will redirect the guest to their Azure apps portal, which will be blank. We want to customise the redirect url to go to the Teams Team the Guest has been added to. We can do this by copying the Teams link and using it in the PowerShell command as follows:

New-AzureADMSInvitation -InvitedUserDisplayName "Mark Vale (GUEST)" -InvitedUserEmailAddress "mark.vale@domain.com" -SendInvitationMessage $true -InviteRedirectUrl "https://teams.microsoft.com/l/team/19%3acf952980e3cc49de882743d1f0f4d721%40thread.skype/conversations?tenantId=<tenant-id>" -InvitedUserType member

Next we need to add the user to the Office 365 Group. As the group is mail enabled, we cannot use the MSOL commands to manage it, we need to connect to Exchange Online PowerShell to do that. For the links you’ll need to add the user account as its displayed as the UPN e.g. mark.vale_domain.com#ext#@myfluffy.onmicrosoft.com which signifies it’s an external account.

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential (Get-Credential) -Authentication Basic –AllowRedirection
Import-PsSession $Session
Add-UnifiedGroupLinks -Identity "Skype&TeamsProfessionals" -Links "mark.vale_domain.com#ext#@myfluffy.onmicrosoft.com" -LinkType Members

Now wait for 30 minutes for Teams to catch up.

When the Guest user signs for the first time you can see the redirection that will take place:


Although this seems to work, as I said before the recommended approach is to use the Teams app to grant guest access. However, it may be useful to you in some circumstances, especially bulk enablement.

Microsoft Teams–Is Yours Setup Ready for Ignite?

There are going to be some huge announcements at Microsoft Ignite that you definitely do not want to miss! This is going to be by far the most exciting Ignite ever with crazy announcements on what Microsoft is delivering inside its cloud offerings. I am genuinely excited at the anticipation is killing me, its made worse because I won’t be there to physically witness it. Sure I will be watching the live stream but I will miss out on the atmosphere when announcements are made. However, in case I am called away from the stream and have to do real work I want to make sure that I at least capture what is announced for later.

I can do this using Microsoft Teams to track social reactions and also follow aggregators using RSS feeds to make sure I have the content in one place at my fingertips on any device I am able to access at the time.

Here are the feeds and social tags you should be following:

RSS Feeds

Twitter Hashtags

  • #MsIgnite
  • #MicrosoftTeams
  • #Skype4B
  • #SfB
  • #SfBO
  • etc.


What You Need to Do

First off I recommend creating a dedicated channel for this within a Team that you use for general information sharing that is not company specific. I assume that you already know how to do this (clicking the Team ellipsis and clicking Add Channel).

Then you want to create yourself some connectors


Scroll down until you find the RSS connector


Press configure

Add a name for the RSS feed e.g. UC Now or Ignite Blog. Then paste the above RSS feed in and choose the frequency you want to poll the feed. For ignite, I recommend the fastest time frame possible.


Rinse and repeat for Each feed


Now you’ll want to watch Twitter for those quick information releases and huge headlines

Again in Connectors scroll down until you find the twitter connector (You’ll need a twitter account)


Now you will want to add a new twitter account to the connector, you can do this by clicking on the add new twitter account. Once you have authenticated with Twitter then you’re able to select the account to use.

Next track the announcements using specific hashtags you want to follow, for me they’re UC specific, but these can be your preferred tech. Add a list of twitter accounts you may want to follow and then change the frequency to deliver as they are tweeted for ultimate updates


Now in case your Teams client is minimized, you want to be notified when things start to happen, so you want to follow this channel


Now you probably want to change your notification settings so you don’t get mail bombed by updates if your client is minimized, so change your notification settings for followed channels from banner and email, to banner


So get your Teams set up ready for the big event!

Prevent Web Client Access to Microsoft Teams

There maybe situations where you want to allow access to Microsoft Teams using the desktop or mobile app only. In the Teams services control settings within the Office 365 portal, you have some varied settings, but nothing that can enforce app only sign in and use. Thinking about adoption and encouraging use within the business, you may want to make your communications simpler, avoiding confusion over whether to use the web client or the desktop app. From experience, being over accessible when first launch often causes a reflex action by the end users. This is because people are comfortable with routines. Disrupt their routine, no matter how trivial unbalances them significantly and their instant reaction is to perform a Fred Flintstone emergency stop!

The art of introducing a new way of working and a new application is to start slowly and ease them into it. It’s all to easy to blow their minds with all the possibilities of what the app can do, but that just outputs a negative adoption result. With this in mind, perhaps you want to launch Microsoft Teams in your business, but want them to use the apps instead of the web client or both for consistency in functionality and training?

Before you go into level 900 technical investigations about how to proxy block https://teams.microsoft.com but still allow the app to sign in and use these URLs there is a simple and easy way to block sign in from the web.

Open Office 365 Admin Portal and then launch Azure AD. Then choose Enterprise Applications from the menu



From the Enterprise Applications menu, select All Applications


From the filter choose Microsoft Applications with state Any and press Apply


Scroll down until you find Microsoft Teams Web Client and then click on it


Now from the Teams Web Client Menu, select Properties


Change the setting for Enabled for User Sign in from YES to NO and press Save


Wait a few minutes for replication and when you try and login to Teams using https://teams.microsoft.com you are blocked


A bit of an unpleasant error message, but in the additional technical information you see the reason


However, I am still able to login to the Microsoft Teams App without any trouble



%d bloggers like this: