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:

  • For internal Web Services virtual IPs (VIPs), set source_addr persistence (internal port 80, 443) on the hardware load balancer. For Lync Server 2010, source_addr persistence indicates that multiple connections coming from a single IP address are always sent to one server to maintain session state.
  • For external Web Services virtual IPs (VIPs), set cookie-based persistence on a per port basis for external ports 4443, 8080 on the hardware load balancer. For Lync Server 2010, cookie-based persistence indicates that multiple connections from a single client are always sent to one server to maintain session state. To configure cookie-based persistence, the load balancer must decrypt and re-encrypt SSL traffic. Therefore, any certificate assigned to the external web service FQDN must also be assigned the 4443 VIP of the hard load balancer.
    • Cookies must not be set to HTTP only.
    • Cookies must not be configured with an expiration time.
    • Cookies must be configured to filter on ‘MS WSMAN’.
    • Cookies must be set in every HTTP response for which the incoming HTTP request did not have a cookie, regardless of whether a previous HTTP response on that same TCP connection had already obtained a cookie. If the Load Balancer optimizes cookie insert to only occur once per TCP connection, that optimization MUST NOT be used.
  • If a reverse proxy is used, set the Forward host header to True in the reverse proxy publishing rule for port 4443. This will ensure that the original URL is forwarded to the target web server.

Lync Server Resources

We Want to Hear from You