No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Is Lync Really that Complicated?

Microsoft Lync is often accused of being complicated. But in fact, Lync is no more or less complicated than comparable UC solutions. The challenge becomes taking the time to understand the various solutions sufficiently in order to conduct a fair comparison.

My colleagues Dave Michels, in his Lync Licensing: Effective Confusion article, and Matt Brunk, in his Understanding Lync article, have focused on some of the complications that may be encountered when trying to implement a Lync solution. As a counterpoint, I wanted to explore the perceived architectural complexity of Lync.

I spend a good portion of my time helping organizations assess and determine the best communication and collaboration solution according to their specific needs. Over the past year, this almost always has included comparing a more traditional voice solution from Cisco, Mitel or Avaya to Microsoft Lync.

In order to perform a fair comparison, you need to determine your critical business requirements and then look at a variety of viable solutions, and assess which best can meet these same business requirements. I have previously outlined a detailed approach you can adopt to complete this comparison process, in the article The Goldilocks Approach: 7 Steps to Get to "Just Right". The key element, if you intend to compare Lync with other solutions, is that each solution reviewed must be configured to meet the same business requirements.

If someone is trying to push a more "traditional" voice solution, it is easy to confuse the issue by repeating partial truths about the large number of physical servers a Lync solution requires. While this might drive the sales efforts, it is often not accurate nor does it serve the end customer. Often Lync solutions are said to require more servers because the Lync solution is architected to provide more functionality than the solution to which it is being compared.

A complete Lync voice solution (aka PBX-replacement) for a small office can be deployed on a single physical server. This single server (physical or virtual) would run the Lync Front-End Server role and would also run the Lync Mediation Server role. This server could then be connected to the PSTN via a SIP Trunk. Even this simple single-server Lync deployment offers more UC features than many traditional PBXs: instant messaging, presence, audio/video/web conferencing.

Best practices would dictate that adding voice mail to a Lync voice solution would require an additional physical server. This server would need to run Exchange roles and the Exchange Unified Messaging role, which provides voice mail.

If you choose to use PRI/T1 connections to provide connectivity to the PSTN, you would require a separate physical hardware gateway on which to terminate the physical PRI connections. This is not required when using SIP Trunks, although for other reasons (e.g. security or scalability) you may choose to use a gateway device even when using SIP trunking to the PSTN. Various vendors manufacture Lync-compatible gateways including AudioCodes, NET, Dialogic and others. See the Microsoft Unified Communications Open Interoperability Program website for further information. Many of these gateway devices allow you to run the Lync Mediation Server directly on the gateway, should you choose.

The Lync edge server role also is required in order to support remote users and to federate with other organizations who run Lync or OCS. Federation is a key feature that many organizations choose to implement when deploying Lync, and quite frankly one of Lync's most compelling features. Federation allows you to share IM, presence, voice, and video communications with key partners, suppliers and customers. I recently declared 2012 as "The Year of Federation" (see 28:00 time mark) and noted that recent efforts at The Lync Federation Project by Matt Landis and www.lyncdirectory.com provide an indication of the thousands of organizations worldwide who are encouraging and supporting federated communications. Best practices for security would have the Lync edge server role deployed on a separate physical server in the DMZ (the perimeter network). Note that this requirement for a separate server/device would be also be present in the case of a Cisco solution.

At enableUC, we indeed run on-premise Lync including the Front-End Server role, the edge server role (to enable federation and remote access), and the monitoring server role on one single physical server. On the same physical server we also run Active Directory and Microsoft's Threat Management Gateway (TMG) network security application.

We have chosen to run the Mediation Server on a separate physical server, although technically we could have also run it on our primary Lync server. The Mediation Server connects to the PSTN using a SIP Trunk. We use Lync softphones and Lync handsets (a combination of Polycom CX600 and Aastra 6725ip phones) in the various enableUC offices.

As we described in the article "Moving to Office 365 (Part 2): Moving Voicemail into the Cloud", at enableUC we have elected to use the Office 365 hosted version of Exchange Unified Messaging for our voice mail.

Several Microsoft Partners have further simplified Lync and Exchange solutions, and have created single-appliance devices that provide IM, voice, voicemail and conferencing capabilities in one unit, often including a simplified management interface. See www.startready.com, www.boxeduc.com and www.iluminaritech.com to explore these very interesting options. (In a future article series I hope to compare and contrast these offerings.)

Of course, many organizations that choose to deploy a full Lync UC solution do indeed deploy a larger number of servers in order provide redundancy, scalability and additional collaboration tools: video conferencing, web conferencing, audio conferencing, desktop sharing, quality of experience monitoring, archiving, etc.

A recent design project I ran for a large retailer included a total approximately 30 Lync and Exchange UM servers. Certainly this is complicated. However, you need to consider that the solution as designed provided both local high-availability and geographical redundancy for voice, voice mail, instant messaging, audio (up to 1,000 concurrent users), video and web conferencing for approximately 8,000 users all at service levels of 99.5% of better. Yes, this was a complex Lync solution, but based on experience, a comparable Cisco, Avaya or other vendor solution providing similar functionality would be equally complicated.

So, is Lync really that complicated? Well, it depends. Like other vendor solutions, a simple Lync solution can be straightforward. But like other vendor solutions, a complete, fully redundant unified communication and collaboration solution can be quite complex. What is clear, however, is that incorrect assumptions or fear of complexity should not be a reason to avoid considering Lync for your next voice solution.

Next week: Is Lync Really that Simple?

If you are thinking about deploying Lync in 2012, please join me at Enterprise Connect in Orlando on March 28th where I will be hosting a Living with Lync session discussing the experiences of those who have chosen to deploy Lync. Perhaps you can ask them "Is Lync really that complicated?"