The Right Mindset for Deploying Skype for Business
When executives analyze the organizational benefits of deploying Skype for Business to their user base, they often only think of the endgame and overlook the key points that ensure a successful deployment. Teams that properly plan out a healthy deployment receive key benefits:
- Drives User Adoption
- Promotes a positive user experience
- Maintains user trust
- Return on Investment back into the business
Organizations that only see the endgame and rush to the finish without proper execution are subject to:
- Poor user adoption
- Shift in operational cadence
- Loss in user trust
- Decrease in business value
It’s difficult to put a value on the confidence end users have in their toolsets, but we’ve seen organizations invest significant funds into Skype for Business, but ignore the key adoption and transition best practices, causing their entire user base to lose faith in the solution. When properly deployed, users are confident that Skype for Business will operate reliably and their calls will be high quality with minimal call drops. They leverage each feature the solution is capable of and feel that the solution is mission critical to performing their daily tasks.
During the planning phase of a Skype for Business deployment, there are four key areas of focus that organizations cannot overlook to ensure the best end user experience:
We could dive deep into any of these four areas, but I’m going to focus on the Call Quality Methodology today. The primary way for ensuring end users have high confidence in the solution is by ensuring they receive high call quality from the beginning and quickly resolving any issues that do arise. With real-time communication, there are many links in the chain that can cause issues, so having defined paths for measuring quality and remediating issues is paramount. Microsoft has developed three “roads” for organizations to take when managing Skype for Business:
The Server Plant Road
Segment 1 of the Server Plant Road addresses the actual servers in the Lync/Skype for Business implementation. Gather Key Health Indicators (KHI) data regarding both the server itself and its role in the implementation, and analyze the result. If action is warranted, correct any problems found. More detail on this topic is presented in this article about Key Health Indicators in Lync Server 2013 that accompanies the KHI poster.
The next segment addresses media streams between the AV MCU server and mediation server. Begin by determining your targets for poor stream thresholds. Poor streams are usually PacketLossRate > .01 or PacketLossRateMax > .05. Another desirable target is PoorStreamsRatio < 2%. Next, use detailed queries to find AVMCU and Mediation server pairs with poor streams, investigate the cause of poor streams, look at network equipment in the poor stream paths, remediate poor streams, and define optimal or “gold” configuration for network equipment. To maintain your achievement, implement processes and tools to manage configuration drift and to report new problem areas.
Next, examine the media streams between the Mediation server and the Public Switched Telephone Network (PSTN) gateway. Begin by determining your targets for poor stream thresholds. Poor streams are usually PacketLossRate > .01 or PacketLossRateMax > .05. Another desirable target is PoorStreamsRatio < 2%. Next, use detailed queries to find Mediation server and gateway pairs with poor streams, investigate the cause of poor streams, look at network equipment in the poor stream paths, remediate poor streams, and define optimal or “gold” configuration for network equipment. To maintain your achievement, implement processes and tools to manage configuration drift and to report new problem areas.
Finally, examine the health metrics for your PSTN gateway. Identify the statistics that show health and define targets against them. No specific guidance is provided here as many possible gateways can be used. Once targets are established, remediate as needed to achieve the target; in the process you will likely define a “gold” or optimal configuration for the gateway. To maintain your achievement, implement processes and tools to manage configuration drift and to report new problem areas. Be aware that firmware and software updates may alter your configuration or lead you to change the definition of the “gold” configuration, so approach these activities with care.
The Last Mile Road
Of the two ways clients connect to the network, wired is expected to deliver the highest quality and correspondingly this must be your initial focus for last mile issues. Use the CQM Wired query (LastMile_0_Wired) and the Poor Streams ratio data it provides. We suggest defining a target PoorStreamsRatio < 5% for sites with > 300 streams). To achieve your targets, remediate subnets ordered from worst to best, and implement QoS.
After you optimize the quality of your wired connections, improving wireless quality becomes easier because the wireless infrastructure sits atop the wired core at each location. Poor wireless streams in a site with good wired quality must be attributed to the specific wireless components. The CQM Wireless query (LastMile_1_Wireless) operates on a date range and will return all internal wireless streams in your environment from Lync clients to or from either conferencing servers or mediation servers. We suggest defining a target PoorStreamsRatio < 5% for sites with > 300 streams). To achieve your targets, remediate subnets ordered from worst to best, and implement QoS.
The End Points Road
Begin inquiries into the End Points Road with the headsets and other devices known to produce acceptable quality when used with Lync. We suggest a target AvgSendListen MOS > 3.6 for implementations with over 100 streams.) Achieve the target by identifying problematic devices and fix or replace them.
Next, examine the device or PC processing the audio for end user calls. A suggested target quality metric is an AudioMicGlitchRate <= 1. As you identify optimal system configurations for the user systems, define a “golden” PC configuration including driver versions.
Now examine the network path an audio stream takes from a Lync endpoint system, which can cause poor audio quality. If audio travels over a VPN connection,b you might see latency issues. If an internal Lync client cannot establish a direct media stream to another internal Lync client for a two-party or peer-to-peer call, it will fall back to a path that relays through a Lync Edge server, again leading to latency issues as well as increased potential for loss and jitter. We suggest you define a quality metric of 0% Media over VPN. As you remediate to achieve the target you set, identify problem subnets and investigate firewall rules, packet shapers, and other relevant network equipment configuration.
IP Packets can use either Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). TCP is optimal for data streams. UDP is connectionless and is more efficient for media since TCP recovery mechanisms cannot address loss in real time media. Lync always prefers UDP, but will revert to TCP if a UDP session cannot be established. Media sessions over TCP will exhibit poorer quality than over UDP. We recommend a quality definition of 0% connections over TCP. As you remediate to achieve the target you set, identify problem subnets and investigate firewall rules, packet shapers, and other relevant network equipment configuration.
The poster for Skype for Business Call Quality Methodology can be downloaded here, and if you would like to discuss how to resolve issues within your current Lync/Skype for Business environment, please reach out to us at info@pei.com, and we would be happy to assist.
Additional Materials for Further Reference:
Skype for Business Call Quality Methodology
https://www.youtube.com/watch?v=D_qFEYBUIV8&index=2&list=PLH5ElbTc1hWTsunfXvNVnDFCJCCzrL3R9
Martin Feehan, Director of Client Relations, PEI
