Three items that can cause "irreconcilable differences" between your organization and Lync.

In part 1 of this series I looked at some "relationship rules" that can help make living with Lync more rewarding: Think beyond voice, consider you are calling a person, not a device, and select the right endpoint for your different user types.

In this second part, I explore three items that can cause "irreconcilable differences" between your organization and Lync.

Network Issues
Real-time communications relies on a solid network foundation. This means ensuring your network is up to the challenge--a common area where some organizations stumble.

Many organizations initially deploy Lync primarily for instant messaging and presence. However, when you choose to make use of Lync voice, video or voice conferencing services, you may need to upgrade your network.

All voice over IP systems (VoIP) require that your network treat voice packets as "special". This is typically referred to as QoS (quality of service) or CoS (class of service). The intent is to ensure that voice packets are forwarded reliably through the network so that voice quality does not degrade. Real-time communications, such as voice and video, are much more impacted by slight delays in packet delivery, as compared to other application services such as email and instant messaging.

Older switches and routers may not support QoS and as such, in order to deploy any VoIP solution, including Lync, you may need to upgrade your network hardware. In addition, you may need to ensure that your WAN network provider is also able to prioritize traffic between your branch offices; this might require paying more for "real-time traffic prioritization".

If you are choosing to deploy Lync desktop phones, it is most convenient if these devices receive power from the network connection; however, this requires that your network switches support power over Ethernet (PoE). Supporting PoE may require you to upgrade some or all of your existing network gear.

Underestimating the Complexity of Voice
Setting up a Lync environment to provide instant messaging and presence can be a straightforward, one day, one server project. This one server can provide IM and presence services to thousands of people within an organization and also provide (internal) peer-to-peer voice and video services without too much effort.

Ironically, it is the ease with which Lync can first be installed that sometimes causes IT groups to underestimate the complexity of deploying Lync as a full UC solution.

I previously explored this dual nature in the two articles "Is Lync Really that Complicated?" and "Is Lync Really that Simple?"

As noted above, just because voice services are easy to install, this does not guarantee that your network is properly connected or engineered to deliver reliable voice services under all circumstances (i.e., when congested with other data traffic).

Allowing users to receive calls from and place calls to the PSTN requires some connection to the PSTN, whether this be a SIP trunk, PRIs or 1FLs. This will require a conversation with a telco and some familiarity with telco jargon. If you are going to use a PRI or 1FL connection, you will require a gateway hardware device; depending on resiliency requirements you may choose to make your gateway an SBA (survivable branch appliance). If you use a SIP trunk you may choose, for security reasons, to implement an SBC (session border controller).

To provide conferencing services (audio, video, web), you will need to setup the MCU (multipoint control unit) roles within Lync. These server roles have more complicated scaling restrictions and as such require more planning compared to the basic IM and presence functions.

Next Page: The importance of training and communications