F5 web services configuration guidance for Lync

Microsoft guidance for configuring cookie-based persistence for hardware load-balanced Lync Web Services connections can be found here.

Hardware Load Balancer Requirements for Web Services:

·         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 means 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.

·         For Internal Web Services VIPS, set Source_addr persistence (internal port 80, 443) on the hardware load balancer. For Lync Server 2010, source_addr persistence means that multiple connections coming from a single IP address are always sent to one server to maintain session state.

·         Use TCP idle timeout of 1800 seconds.

·         On the firewall between the reverse proxy and the next hop pool’s hardware load balancer, create a rule to allow https: traffic on port 4443, from the reverse proxy to the hardware load balancer. The hardware load balancer must be configured to listen on ports 80, 443, and 4443

Cookie persistence requires SSL termination on the load balancer. Otherwise, the load balancer cannot inspect HTTP traffic to insert cookies. To enable cookie-based persistence, you need to enable client_ssl and server_ssl profiles in addition to any existing profiles which are already enabled. Since client_ssl enables decryption of packets, the certificate assigned to the client_ssl profile must match the certificate requirements for the Lync FE Pool or Single Edition FE server. Server_ssl enables re-encryption of packets before routing them to the FE pool.  (NOTE: Front End servers don’t accept unencrypted HTTP traffic.)

In addition to the client_ssl and server_ssl profiles, a OneConnect profile (or similar) must also be used to properly load balance requests for External Lync Web Services.  Using a OneConnect profile for HLB requests is explained in detail on the F5 support website here and is described below:

HTTP parsing without a OneConnect profile

If the virtual server does not reference a One Connect profile, the BIG-IP system performs load balancing for each TCP connection. Once the TCP connection is load balanced, the system sends all requests that are part of the connection to the same pool member. For example, if the virtual server does not reference a One Connect profile, and the BIG-IP system initially sends a client request to node A in pool A, the system inserts a cookie for node A. Then, within the same TCP connection, if the BIG-IP system receives a subsequent request that contains a cookie for node B in pool B, the system ignores the cookie information and incorrectly sends the request to node A instead.

HTTP parsing using a OneConnect profile

Using a OneConnect type of profile solves the problem. If the virtual server references a OneConnect profile, the BIG-IP system can perform load balancing for each request within the TCP connection. That is, when an

HTTP client sends multiple requests within a single connection; the BIG-IPsystem is able to process each HTTP request individually. The BIG-IP system sends the HTTP requests to different destination servers if necessary.

For example, if the virtual server references a OneConnect profile and the client request is initially sent to node A in pool A, the BIG-IP system inserts a cookie for node A. Then, within the same TCP connection, if the BIG-IP system receives a subsequent request that contains a cookie for node B in pool B, the system uses that cookie information and correctly sends the request to node B.

Note: The latest Lync Server 2010 configuration guide from F5 does not include the steps for configuring a OneConnect profile for load balancing requests for External Lync Web Services.  You can find a copy of this configuration guide here. 

Using this configuration, Application sharing will fail and you may see failures like these in the Edge event log:

Additionally, Edge A/V sessions will not work using the currently documented F5 Edge A/V settings:

 We had to configure SNAT on the Edge A/V VIPs in order to get them functional.

One other note: If you are not using the reverse proxy role, F5 documentation does not show the FE pool VIP needing port 80. If you do not allow port 80 HTTP to the FE pool VIP, then lync phone devices will not be able to download their root certificates!!!

Reference:

http://technet.microsoft.com/en-us/library/gg398478.aspx

http://support.f5.com/kb/en-us/solutions/public/7000/200/sol7208.html

http://www.f5.com/pdf/deployment-guides/f5-lync-dg.pdf

UPDATE 3/15:  Document Version 1.9 has been updated to reflect corrections to the Edge Web Services VIPs. However, the Edge A/V documentation remains the same!!!