Virtualizing Microsoft Lync (Part 1)
In past versions of Microsoft Lync (OCS 2007 and OCS 2007 R2), virtualization of the different workloads really hasn’t been supported by Microsoft. With Microsoft Lync, Microsoft put a lot of emphasis into making sure that Lync and the associated workloads could be implemented into a virtual environment. With that in mind, let’s take a look at some of the best practice recommendations for running Microsoft Lync 2010 in a virtualized environment.
Supported Workloads and Functionality
First, let’s take a look at what can be virtualized. With OCS 2007 R2 you could only virtualized workloads that did not include media processing. Therefore, most services within OCS 2007 R2 could not be virtualized. With Microsoft Lync 2010, all workloads can now be virtualized. Furthermore, virtualized Lync can be considered for all size deployments – from small, single server deployments to large multi-site, multi-server deployments.
Lync Server enables these workloads for virtualization:
• Instant Messaging (IM)
• IM conferencing
• Presence
• Enterprise Voice (PSTN)
• Audio Conferencing
• Video Conferencing
• Web Conferencing
• Application Sharing
• Remote Access, Federation (Edge Server)
• Response Group service
As for supported functionality, here is a list of the server roles and the features that have been tested and are supported by Microsoft:
Note: The Survivable Branch Office Appliance is NOT supported but the Survivable Branch Office Server is supported.
Hypervisors and Guest OS
Now that we have a good understanding of what can be virtualized, we need to know on what platforms Lync can be virtualized. Lync has been validated with two major hypervisor platforms – Windows 2008 R2 Hyper-V and VMware ESX 4.0 and above. Other hypervisors may work with Lync – especially if they have been validated through the Windows Server Virtualization Validation program – but Windows 2008 R2 Hyper-V and VMware ESX 4.0 and above are the only two platforms that have been validated. As for the guest operating system, the only approved OS is Windows 2008 R2.
A couple of fine points to consider with the hypervisors. First, Microsoft Lync cannot be virtualized on the Windows 2008 Hyper-V. Although Hyper-V is an available role with Windows 2008 it is not supported for use with Microsoft Lync. Second, if you are using Windows 2008 R2 Hyper-V, check out Microsoft Knowledge Base article 981836, “Network connection is lost on a Windows Server 2003-based Hyper-V VM” at https://go.microsoft.com/fwlink/?LinkId=201212).
Virtual Server Host Configuration
In order to provide the best possible performance for Lync in a virtual environment, the host server should be built on server class hardware. The recommended base hardware meet or exceed the following specifications:
General Considerations
Mixed environments are not supported by Microsoft. This means you cannot mix virtual servers and physical servers within the same pool. Remember though that a pool is defined as a Lync server pool with more than two servers including the following server roles: Enterprise Edition front end server, Director, Mediation server, A/V Conferencing server, and Edge server. Therefore if you plan your deployment appropriately you can have physical and virtual servers but you may have more than one pool of servers. Another caveat to this is the location of your SQL server. You could have all Lync workloads in a virtual environment and have a physical SQL server as the backend. This is a supported approach by Microsoft.
It is also important when planning your virtualized Lync deployment to consider high availability as well as the spread of your virtual Lync workloads. Virtualization is not a replacement for high availability. Quick, live, or vMotion migrations have not been validated by Microsoft and therefore are not supported. Furthermore, migration of workloads during active Lync sessions will result in dropped connections.
In order to achieve the best possible high availability in a virtualized setup, implement a pool of Lync server components as well as a clustered SQL Server backend server. Also, spread similar workloads between the active virtual server hosts to achieve the best performance and load balancing.
Jacob Eker, PEI
