How to cut through the complexity of Lync 2013

With a little help and openness to telephony approaches, adopting Microsoft's communications server need not be daunting

As an IT admin, I like to think I'm pretty flexible. I like learning new things, and I'm always happy to play with new technology. But I've had a hard time with Lync, Micxrosoft's videoconferencing and telephony server.

Most of us in IT understand the networking side to our world, but the telephony side crushes us. Lync requires understanding all the big foundational Microsoft technologies (Exchange, SharePoint, System Center, Active Directory, and SQL), plus networking savvy (DNS, certificates, and firewalls) plus all the telephony concepts (trunks and routes). To bring all this together into a modern packet-based architecture is tough.

[ J. Peter Bruzzese details the top 7 new features in Lync Server 2013. | Stay abreast of key Microsoft technologies in our Technology: Microsoft newsletter. ]

It's no wonder that, when confronted with Lync, so many in IT say, "No thanks. My PBX is fine." No doubt your PBX vendors are happy about that; surely, some even foster misperceptions and uncertainty about Lync to keep IT wed to the PBX.

Despite my frustrations in trying to figure out Lync, I decided to persevere with help from Jamie Stark, Microsoft's senior technical product manager for Lync. The conversation was quite eye-opening, so I'm sharing its gist here.

For starters, I asked why Lync has a Web-based console (I'm not a fan of Web-based consoles). Stark said it derived from a decision a few years back that PowerShell was going to be integrated into everything. In that context, Microsoft could have gone with the MMC front end or had a Web-based console. The latter is a little easier to get to from any workstation, so it's more flexible for admins. And the telephony folks, who come from a non-Microsoft background, typically worked on Unix, Cisco, or other appliances that usually have Web-based consoles. One message Microsoft had to reinforce with the telephony folks is that it's software and it runs on a server -- a major shift from the appliance-style devices common in telephony where the hardware and software are intertwined.

I asked Stark about the complexity of setting up Lync, the need for consultants at times, and the fear admins harbor of, say, a fiber line being cut -- thus disabling both Internet and phone service. He responded that in the telephony world, it's not uncommon to have your PBX administration outsourced, especially in smaller companies. Plus, IT typically has to work with a third party for its telephony infrastructure. IT shouldn't feel as if it must manage all Lync internally and own its full responsibility; instead, it should be open to using outside providers, as telephony folks do.

One of the benefits to working with a third party with both a telephony background and expertise in deploying Lync is that you're more likely to get a deployment with little change to the dialing pattern. You should mirror the local calling capabilities of the existing system (same extensions and so forth) because the consistency of behavior will help people adjust.

What about this fear of a cut fiber line or a crashed Lync server that takes down critical phone service? Stark said the answer to that risk is a survivable branch appliance (SBA), available from several vendors, which can switch from VoIP calls on the network over to the public (analog) telephone network if needed. It's basically a backup circuit.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform