Yesterday I attended the “Best Practices for Successful VoIP/UC Deployments” webinar put on by Enterprise Connect. I expected to receive some technical information that would be useful to Lync administrators. And I wasn't disappointed.
As I promised last week, here are some of the highlights I found relevant. If you want to see the whole webinar, there are slides and audio available at EnterpriseConnect.com.
Network Performance is Crucial
The issue of performance was central to the webinar. Not surprising, considering their prime considerations were bandwidth-heavy apps like VoIP and video conferencing!
There's a chart on Slide 6 that's worth the download right there. It lists out good performance metrics for five high-bandwidth services: VoIP/UC, Cloud Services, IP Storage, VDI and Video Conferencing. (I was a bit surprised that VoIP/UC was on the *low end*, but hey.) The metrics included minimum available capacity, latency, maximum loss and a few others. Useful when setting up Lync front end servers.
Next came a very Lync-relevant reminder: There are parts of any network connection that we don't control. Loss can occur in any of those parts and affect network performance. A WAN connection, router disruption, carrier latency…any of these can slow down your VoIP call.
The Problems Affecting VoIP and Unified Communications
Next up the webinar presenters (John and Matt) got more technical. They listed out common network problems affecting performance,from QoS configuration errors (something I don't think I've covered before) to an overly-busy router. Each problem was identified,and possible resolutions given.
For example, one presenter mentioned Call Admission Control as a possible cause of insufficient bandwidth. If certain users have consistent trouble with dropped calls, CAC may need adjusting of its max bandwidth for voice.
Should We Measure Performance All The Time?
I know, that's kind of a given. Measuring was a big focus of this webinar though; reminder after reminder about its importance. Especially since application servers like Lync deploy as services. Continuous measuring makes catching performance problems easier (not to mention less stressful for the admin!).
The webinar ended with discussing the PathViewCloud measurement tools from Apparent Networks. I'm not sure how useful it would be for Lync servers. But I'd be remiss if I didn't at least mention it. And this webinar was certainly detailed enough to merit good attention.
Best Practices for Lync Admins
Before that though, the presenters gave 7 best practices for remote site UC deployments. I'm posting the 4 that looked right for a Lync Server admin to employ.
1. Prioritize key services/applications first and then expand – don't bite off too much at once. (Good advice. Roll out Lync's basics first as a test. Then try the VoIP.)
3. Define the location(s) that will leverage/be impacted by the new application/service, and understand the network performance to/from these locations. (You'll need to know bandwidth requirements between remote offices if you want to configure the Survivable Branch Appliance correctly.)
4. Establish baselines of what's actually happening today, before making ANY infrastructure changes. Understand what “levers” affect delivered performance. (Good advice to follow before adding any new servers. But particularly Lync Server, given how integrated with the whole network it can be.)
7. Understand performance from both directions; your central office out to remote locations AND vice versa. (If a certain office has trouble receiving email before Lync is deployed, don't ignore it.)
Performance Tools are Good. Lync Performance Tools are Better!
Let me finish by pointing out that there IS a software-based Lync Server 2010 Performance Tool available. It doesn't test web conferencing or Group Chat, but you'll get some numbers on how well your network handles VoIP, application sharing and other services.
Do you have a performance tool designed to work with Lync? Let's hear about it. Maybe I can blog about it next week.