Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
Microsoft Lync Server 2010 supports both DNS load balanced and hardware load balanced solutions. While DNS load balancing can be used to distribute SIP traffic equally among the various Front End servers in a Front End pool, a hardware load balancer must be used to handle HTTP connections to Lync Web Services. Please note that a hardware load balancer is not required when a Lync Server 2010 Standard Edition or a single Lync Server 2010 Enterprise Edition Front End Server is deployed within a Lync environment.
Author: Dave Howe
Publication date: November 3, 2011
Product version: Lync Server 2010
To create a load balanced connection to Microsoft Office Communications Server 2007 or Office Microsoft Office Communications Server 2007 R2, use TCP-level affinity with a TCP idle-timeout value greater than or equal to the minimum REGISTER refresh or SIP Keep-Alive interval (typically 30 minutes).
For in-depth information on load balancer requires for Office Communications Server 2007 see:
The hardware load balancer requirements for Lync Server 2010 are different than the requirements for Office Communications Server 2007 or Office Communications Server 2007 R2, especially for connections to Lync Web Services. While source address affinity persistence is recommended for connections to Lync Web Services from internal clients, cookie-based persistence is required for connections to Lync Web Services from external clients. See Reference Architecture 3: Scaled Consolidated Edge (Hardware Load Balanced) for more information.
Many customers are unaware of the hardware load balancing requirements for Lync Server 2010 when using source address affinity persistence for Lync Web Service requests, from both internal and external clients. Although source address affinity persistence may be sufficient for many Lync Web Services requests, the new mobility features available in Lync Server 2010 CU4 will require cookie-based persistence for external connections to Lync Web Services.
When source address affinity persistence is used to load balance requests to Lync Web Services from internal clients, all requests within a TCP session are sent to the same server, based on the source IP address of a packet only. Each TCP session established with the load balancer originates from a different Lync client connected to the internal network. Because each TCP session originates from a unique IP address, the load balancer is able to equally distribute requests among the various Front End Servers of the Front End pool.
When cookie-based affinity is used to load balance requests to Lync Web Services from external clients, each packet is decrypted and inspected for the presence of an HTTP cookie, or an arbitrary piece of data that uniquely identifies a client to a given web server. If an HTTP cookie is detected by the load balancer, the packet is re-encrypted and sent to the web server that originally generated the cookie.
Cookie persistence, by definition, requires SSL termination on the load balancer (otherwise the load balancer cannot inspect HTTP traffic to insert cookies). To enable cookie-based persistence, customers need to enable client_ssl and server_ssl profiles, in addition to any existing profiles that are already enabled. Client_ssl enables decryption of packets, and as such, the certificate assigned to the client_ssl profile must match the certificate requirements for the Front End pool or Standard Edition Server. Server_ssl enables re-encryption of packets before routing them on to the Lync Pool. (Front End Servers do not accept unencrypted HTTP traffic.)
Although cookie-based affinity can successfully provide session persistence between a client and a specific web server for an extended period of time, additional configuration is required if a reverse proxy is used. If a reverse proxy is used to handle inbound requests for Lync Web Services, each TCP session originates from the same IP address–the IP address assigned to the internal interface of the reverse proxy. Because all requests are routed to the load balancer from the same IP address using a single TCP session, the load balancer must be configured to distribute the individual requests within the TCP session and not the TCP session as a whole.
The following settings should be configured on your hardware load balancer to properly load balance requests for Lync Web Services: