Skype for Business Reviews

Disclaimer: the new version of Lync Server 2013, Skype for Business (SfB) Server 2015, has been released a few weeks ago. Licensing model is the same you had for Lync Server, with companies paying only Front End servers (i.e. the ones hosting user accounts and the core services for your infrastructure).  SfB contains some new features, including support for Back End availability based on AlwaysOn groups. I will write a dedicated post asap.     

The costs related to Microsoft Lync are something that I have talked about more than once but this is the first time I try to summarize information in a single document. I will limit my reflections to on-premises organizations, because as I am writing, Lync Online has no serious support for Enterprise Voice (i.e. VOIP) and this makes the Cloud version of Lync less flexible (and somewhat less interesting) than the more traditional, corporate deployment.

Your House, Your Rules

A starting point for all cost-related considerations is to understand which kind of service we need. Lync Server 2013 supports solutions ranging from a single, all-in-one box (with a mandatory Office Web Apps server required to share PowerPoint presentations) to hundreds of servers geographically dispersed. Let us list some parameters.

1. Number of Users

The first parameter you have to establish is the number of users that will require Lync services. Lync 2013 Standard Edition (S.E.), the aforementioned single box, is tested to support up to 5,000 users. Obviously, before you reach the 4,999th Lync enabled account, it could be a good idea to add a second Front End (the server that delivers core services to the users) or consider a Lync Enterprise Edition (E.E.) solution (more details on the two editions of Lync Server 2013 are explained in the next paragraph)

2. Required Availability

Second parameter will be the required level of availability. If we deem service continuity as required for any of the Lync features (especially if we are going to use Lync as our VOIP system), it should be in a high availability deployment. Lync pools support a feature called Pool Pairing, if we have at least a couple of Lync 2013 S.E. Front End servers in our infrastructure.

It is not an H.A. solution, but adds resiliency to the solution and it grants some degree of survivability to the voice users. In a paired pool, using a series of scripts, we are also able to fail-over and fail-back Lync users, restoring full functionality for them. A highly available solution requires the E.E. of Lync Server 2013.

Although there is no difference in the cost of licenses between S.E and E.E., to use Enterprise Edition you must have at least pool of three Front Ends connected to a separate SQL Server database (whereas S.E. uses a collocated SQL Server express at no additional cost).

A dedicated SQL infrastructure would also require a continuity solution, like clustering or mirroring. A well-known rule of thumb is if we need to provide high availability, then we need to remove any potential Single Point of Failure in the design.

Small, remote offices might also require (at least) voice survivability. For such a scenario, we have a dedicated implementation of Lync Server 2013, the Survivable Branch Appliances (SBA); these are less expensive than a full-blown Lync front-end server.

Note: SQL licensing for Lync Server 2013 has been deep dived in a good post from fellow MVP Thomas Poett in his blog Lync Server 2013: Lync Backend SQL Server Licensing http://lyncuc.blogspot.it/2014/01/lync-server-2013-lync-backend-sql.html

Availability requirements have an impact also on point 3 and 5 of this list.

3. Additional Servers

Lync requires some additional servers that have no additional cost from the Lync server licensing point of view but that add costs to acquire the base Operating System, hardware and so on.

• At least a Lync 2013 Edge server and a reverse proxy are required to make our services available to users outside our corporate network
• The only Lync role that requires a Lync server license is the Front End. All other additional roles like Mediation, Director and the aforementioned Edge are not subject to additional Lync server licensing
• At least an Office Web Apps server is required (as I said before) if PowerPoint sharing is required
• If we have high-availability requirements, the aforementioned services should be redundant through an edge pool, a highly-available reverse proxy and an Office Web Apps farm
• Lync integrate with Exchange Unified Messaging (UM) for services like voice mail. Exchange will have its own requirements and costs, but we have to keep them in mind if we require UM-related services
• A Lync 2013 E.E. pool requires a dedicated load balancer to balance certain type of traffic from the pool. This may be provided in the form of a physical or virtual appliance. Remembering SPoF, load balancer should also require an additional standby device for resiliency.

Note: Every Lync, Office Web Apps, SQL database and reverse proxy (if you are going to use a solution based on Windows Server) will require a license for the Operating System. You could use virtualization rights (Licensing for Virtual Environments https://www.microsoft.com/licensing/about-licensing/virtualization.aspx ) to keep costs down, but this aspect is to be included in the list

4. Client Licenses

For the following point, I will quote my free e-book Microsoft Lync Server 2013: Basic Administration (http://gallery.technet.microsoft.com/office/Lync-Server-2013-Basic-0a86824d )

Lync requires a CAL (Client Access License) for each user or machine that logs on to the server. CALs are of three types and each one is entitled to the use of a part of the features. Access to premium functionality is determined by adoption of the Standard CAL and then you have to add supplemental CALS, an Enterprise CAL and, for some additional features, a third license called Plus CAL (you may think to Enterprise CAL and Plus CAL as supplemental to the Standard CAL).

• Standard CAL: offers IM (Instant Messaging) and Presence, as well as PC-PC audio and video communication
• Enterprise CAL: the user can use multi-party Lync meetings (including Gallery View, a feature allowing up to five active video streams to be displayed at once)
• Plus CAL: enables enterprise voice capabilities

5. Infrastructure costs

There are a couple of entries in the bill of materials not directly related to Lync, but that we have to consider anyway:

• If we are going to use Lync Server 2013 as our telephony infrastructure, we will require access to the public telephony system. There are a lot of offers and solutions from hundreds of providers worldwide, so an exact cost estimation is tough to outline here. Granting high availability will raise the costs here too, adding mandatory backup lines in case of a failure on our provider’s side
• Lync Server 2013 has a high level of security by default and requires digital certificates to function. While our internal infrastructure can work with a corporate Certification Authority (C.A.), if we plan to make our Lync services available to Internet users (and to federate them with external Unified Communication systems) we have to use commercial certificates from a well-known, third party C.A. The cost here is not something to underestimate, because digital certificates will have to be SAN with many alternative names inside. In addition, the more SIP domains we will manage with our Lync deployment, the more names we will need in the certificates, and certificate fees are likely to ramp-up further.

Summarizing

Now, as it is easy to understand from the previous list, there is no right answer to the starting question. I will try to focus a few points:

1.High Availability will raise the costs, as usual

2.Using Lync Enterprise Voice will add license and infrastructure costs (as well as making H.A. almost mandatory)

3.The number of users and their level of access to Lync’s features will impact budget both for the deployment sizing and for the needed client licenses

4.The bulk part of the expenditure items related to a Lync deployment are not related to Lync server licensing, but to the other voices we have seen

Alessio Giombini contributed to this review. 

How has it helped my organization?

What is most valuable?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How is customer service and technical support?

How was the initial setup?

What other advice do I have?

High availability is something that companies do not take for granted, they take it as given (especially when we talk about telephony). While Lync 2010 did a good work on this critical aspect there were still some weak points on the architecture when there was the need for a really continuous service. For example the mechanism behind the “backup registrar” implementation was really a limit and, for the Enterprise Front End deployments, the need for a clustered SQL server Back End was a restriction and did not match with the requirements related (also) to some kind of disaster recovery plan.  

Front End Pairing and new rules on licensing

Lync 2013 makes a step forward, building on what was valid in the previous logics and using whole new solutions were they are necessary. The first huge improvement is related to the so called “Front End pairing”. I have created a presentation about this solution some time ago (http://bit.ly/XKCBzd) anyway what you need to know is that now your Standard Edition Front Ends (or your Enterprise Edition pools) can be tied and you are able to failover and failback users completely from one Front End to the other one with a simple Shell command. Some limits apply (pairing is supported only on similar Front Ends, so Enterprise Edition and Standard Edition mixes are not supported) but the result is really what you wish you had some years ago. The licensing has changed accordingly so that now there is no difference in the costs of a Standard or Enterprise edition of Lync. Obviously we are not talking about a “free lunch” because an Enterprise Edition deployment has a suggested minimum of three servers and you have to add the cost of at least one SQL server license to the amount. Talking about the Lync databases, we have another hot topic

Back End mirroring

The Lync Back End server (basically a SQL database hosting some of the Lync configurations and data) is really less important than it was in the past (and that’s why we are able to pair the Front Ends) but it is still mandatory for an Enterprise configuration of Lync. The high availability for Lync 2013 Back End supports:

• SQL database mirroring 
• SQL database clustering (starting with the August 2013 update

Mirroring is interesting because it allows for geographically dispersed deployments and requiring no shared storage between the different SQL “nodes”.

There is no support fo SQL AlwaysOn, at the moment.

Pools

As I said, solutions used in Lync 2010 that were effective have been used also in Lync 2013. This is the case of the Lync roles “pools” that are still used to grant the availability of features such as Lync Edge, Mediation and Director (the last one being now more optional than ever). However something has changed also in Lync pools implementation. Monitoring and Archiving are no longer independent roles but are collocated with the Front Ends, so you do not need to create dedicated pools. Persistent Chat Server (a new role, interesting in scenarios where you need to create persistent “rooms” for users IM conversations) must be pooled too if you want to grant its continuous accessibility.

Mediation Server Supporting Multiple Trunk and Inter-Trunk Routing

This last topic is not strictly related to the high availability but the aforementioned features (multiple trunks and inter-trunk routing) add a series of possibilities when planning an Enterprise Voice solution and the additional elasticity can be turned in a resiliency instrument. For example multiple trunks can be defined between a Mediation Server and a voice gateway or multiple Mediation Servers can route calls to the same gateway. Applying the right voice routing policies you will be able to create a series of solutions to use existing connections to the PSTN network or SIP trunks for continuity. Inter-Trunk routing enables the interconnection of two or more IP-PBX systems and this could be used as a way to add voice resiliency too.

Drawing a conclusion

The new features and possibilities we have seen here have a deep impact on the design of a Lync solution and on the perception of Lync as an enterprise ready solution. With the right design (and investment) every piece of the deployment can be made highly available and affordable, with a logic that is no more bound to a single site but can include also branch offices, disaster recovery sites and Cloud features too (hybrid deployments are part of the game now). You can stay assured that people will look with a growing interest to Lync now that the aforementioned possibilities are no longer only in the wish list. 

What is most valuable?

How has it helped my organization?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

How are customer service and technical support?

Which solution did I use previously and why did I switch?

How was the initial setup?

What's my experience with pricing, setup cost, and licensing?

What other advice do I have?

What is most valuable?

How has it helped my organization?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and technical support?

Which solution did I use previously and why did I switch?

How was the initial setup?

What's my experience with pricing, setup cost, and licensing?

Which other solutions did I evaluate?

What other advice do I have?

What is most valuable?

How has it helped my organization?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How is customer service and technical support?

How was the initial setup?

What's my experience with pricing, setup cost, and licensing?

What other advice do I have?

Enterprise voice in the cloud

I've used Skype Business (name change from Lync) in two companies. In one of them I was introduced to it as, "problematic." Now, having used it for months, multiple times a day for video, voice and chat, I never had a problem with it. 

Voice calls - great quality if it was with someone in the same building or half way across the globe. No fuzzing or dropping. 

Video calls - same. Great quality. No big drain on the computer so I could do other things. Again, good quality for the same building or globally. 

Chat - what to say here apart from, it worked. Chat is a nice feature if you want to keep a history of messages. 

(source: Skype.com)

Meetings - we managed to get +10 people, all from various locations, on different systems, using varying bandwidths, some connecting via Skype/Skype for business/mobiles, landlines. Only 1 person had a problem and that was due to their AD FS set up. We had video, audio, and chat. We transferred files. Some of us switched to muted mics just to listen.... 

Some people have had sign on issues but I think that may be more to do with internal set up because my experience hasn't included this. 

Security and features that I used/like: 

Skype For Business traffic is encrypted using TLS

You get archiving of messages

P2P file transfers

IM and conferencing 

HD 1080p available depending on plan

Ability to have a presenter for training or to chair meetings

You can record content

Meetings can be scheduled via Outlook

The thing I want from any app is this: it needs to deliver. For me, Skype Business did. Does it take a bit of work to integrate into systems? Well, I've yet to meet a bit of kit with more than three features that doesn't. Is it worth it? I believe so. Skype for business is convenient. It's one of those things that's there, you use it, you forget about it - we're all happy. (or, at least, I was)

Intro and Scenario

Some months ago, Microsoft added to its Office 365/Skype Online offer Cloud PBX with PSTN calling (Public Switched Telephone Network is the aggregate of the world's circuit-switched telephone networks). 

Cloud PBX gives the capability to connect Skype for Business (S4B) Online users to the PSTN with no existing on-premises deployment.

Your telco, in such a scenario, could be Microsoft itself but this kind of solution involves some interesting downsides.

Microsoft should be able to offer phone numbers in many different countries that have dissimilar regulations and that will have different carriers and providers, each one trying to offer something more interesting than competitors.

The alternative to the aforementioned scenario (and a more down-to-earth solution) is having all Skype for Business workload in the Cloud with minimum footprint on-premises, just to connect S4B users to local PSTN services (using SIP or ISDN).
This is what Microsoft calls Skype for Business Cloud Connector Edition (previously, you may have heard names like MinTop or Minimal Topology).

While I will not deep dive the specifications of this solution, the implications it has must be understood from any customer that is evaluating a Cloud based VOIP system like this one

CCE Overview

CCE is a downloadable package from Microsoft.  Inside the package, you will have four virtual machines running on Hyper-V that you will have to deploy in your DMZ. 
As you can see in the following schema (from the TechNet post Plan for Skype for Business Cloud Connector Edition ( https://technet.microsoft.com/en-us/library/mt605227.aspx) CCE acts as a bridge between your local telco provider and the Microsoft Cloud.

Deploying more than a single CCE on a site will add resiliency and increase the number of supported calls.

Note that, in this kind of scenario, you have purchase PSTN conferencing from Microsoft or from audio conferencing provider (ACP) partner if you want to add dial-in conferencing.

In addition, from a security point of view, the Directory Services inside the CCE have no communication with your production Domain Controllers.

Is CCE useful for My Company?

In the TechNet post Plan your Cloud PBX solution in Skype for Business 2015 or Lync Server 2013 ( https://technet.microsoft.com/en-us/library/mt612869.aspx) Microsoft offers an interesting "block diagram” to help customers selecting the right solution.

CCE is seen as something fit for greenfield deployments, while existing Skype for Business infrastructures are suitable to work with Cloud PBX directly.

Vendors like Audiocodes are already offering support to the CCE onboard of their Gateways and Session Border Controllers (SBCs).

That is interesting because to talk with the local PSTN you usually already have the requirement for a gateway/SBC.

Therefore, CCE will probably add small or no cost to what you already had to spend anyway.

Takeaways

CCE is an interesting proposal to realize an hybrid voice deployment (Cloud services and local telco) with little effort.

Removing the Skype for Business (on-premises) deployment from the requirements to use Cloud PBX with PSTN calling simplifies the whole process of moving Enterprise Voice (VOIP) to the Cloud.

Having CCE integrated with gateways is another help in making the aforementioned Cloud adoption straightforward.