Several weeks ago I wrote, "Is Lync Really that Complicated?" wherein I concluded that:
1. A Lync voice solution for a small office could in fact be deployed on a single server, and
2. Lync is not any more complex than any comparable solution from other vendors.
In short, those portraying Lync as excessively complicated do so not based on facts but more likely out of misunderstanding or simply competitive "selling".
On the other hand, is Lync really that simple?
Delivering reliable real-time traffic, which includes voice and video, over a network can be complicated, especially if the network has not been designed for real-time traffic.
Lync supports a number of communication modalities, such as instant messaging and presence along with desktop sharing, which are not as sensitive to network issues. In fact, installing and using Lync for instant messaging and presence is almost always simple.
Things get a little more complicated if you want to allow users from remote locations or from different organizations to share IM and presence (called federation). But quite frankly, setting up a Lync Edge server and dealing with public certificates and firewall issues is only of moderate complexity.
Where I see customers underestimate the complexity of Lync is when it comes to reliable delivery of voice. Lync is a Voice over IP (VoIP) solution and like all VoIP solutions, whether they are from Microsoft, Cisco, Avaya, Mitel or any other VoIP provider, an appropriate network infrastructure is required.
Problems most typically arise when an Exchange Engineer or Active Directory Engineer or Sharepoint Engineer undertakes a Lync voice project. With Lync, knowing other Microsoft technologies helps, but having voice engineering experience is essential to delivering a reliable solution.
Much has been written about the pros and cons of Lync's adaptive voice and video codecs. In the beginning, back in the days of Office Communication Server (OCS, the precursor to Lync), Microsoft made it almost seem as though through the magic of the RTAudio and RTVideo codecs, any network would do. This is not the case. Microsoft has since published a number of detailed planning documents that help you ensure your network can meet the requirements for voice and video.
Reliable voice and video delivery requires that these real-time packets be treated as "special" on your network. This involves prioritizing or implementing Class of Service (CoS) on your LAN and Quality of Service (QoS) on your WAN connections. CoS and QoS are broad topics that require proper engineering and testing to ensure they have been properly implemented. Without functional, tested CoS/QoS, you cannot deliver reliable voice or video.
Sometimes in order to implement CoS/QoS, your existing switches and routers may need to be upgraded. If your network equipment is six or seven years old, some upgrades may be required. Even newer devices may pose some issues and even the newest devices will likely need to be configured (and then tested) to ensure CoS/QoS is being properly applied.
Using VoIP solutions, including Lync, with wireless networks often poses special challenges. Prioritization of packets on wireless networks is often handled differently than on wired networks; and depending on how many wireless access points you have, users moving around can be subject to interference and access point saturation (when many users are in the same area), all of which degrade voice quality. In most environments, a guaranteed level of voice quality can only be provided through a wired connection.
While you cannot fully control the experience of remote users because they are operating on an "unmanaged" network segment, perhaps at home or more likely from a Starbucks, you can set expectations appropriately with your users. This is where the adaptive nature of RTAudio truly helps to try and preserve an acceptable quality of voice in most circumstances. However, users should be warned that sometimes network issues will prevent reliable remote voice calls. The new Lync client introduced a number of user messages that try and warn users when network quality is problematic. From a remote location, a user can also quickly "Check Call Quality" ahead of a call using a simple tool built into the Lync client.
If you plan to deploy IP telephone sets with Lync, you will likely want to make use of Power over Ethernet (PoE), where the handsets derive power from the data connection (as opposed to requiring a separate AC power adaptor). Sometimes this requires you to upgrade your switching equipment to support PoE. Sometimes using PoE devices may also require you to upgrade your Uninterruptible Power Supply (UPS) units so that in an event of a power failure your phones remain working for a period of time.
Lync, like all voice solutions, requires voice engineering experience. Make sure you have these skill sets on your implementation team. If you are not already running voice over your IP network, do not assume your network can reliably deliver real-time traffic; router and switch upgrades may be required; the need for network configuration changes and testing is almost certain.
If you are thinking about deploying Lync in 2012, please join me at Enterprise Connect in Orlando on March 26th at 4:15 PM when I will be hosting a Living with Lync session sharing experiences of those who have chosen to implement Lync. We will explore what was "simple" and what was "complex" in various Lync deployments.
