As part of my day to day working with Lync Server 2013 & Lync server 2010, People frequently ask me the question do I really need a Hardware Load Balancer for Lync server? And my answer is “YES You Do” The next question then is “Microsoft say you can use DNS Load balancing for Lync server”. Then I say it’s true you can use DNSLB for your SIP traffic however for your HTTP/HTTPS you still need Hardware Load Balancer. The next question is why can’t I Load Balance HTTP/HTTPS using DNSLB?

HTTP and HTTPS are session-state–oriented protocols. This means that if a client starts a conversation with one Lync director or frontend server, that client needs to continue to talk with Lync Server only to complete the entire request. With DNS load balancing, there is no sticky-session state that can be set. As a result, there is no way to ensure that a session is going to be continued on Lync Server.

What does this mean “session-state–oriented protocols?”

Session is a kind of dialogue or a conversation between two or more communicating devices, say Lync client and Lync server. A session is set up or established at a certain point in time, and then torn down at some later point. An established communication session mostly involve more than one message in each direction. Stateful meaning that at least one of the communicating parts needs to save information about the session history in order to be able to communicate.

Imagine you are signed using Lync Mobile client and we are using DNS Load Balancer for three Lync front-end servers. You search a contact this now new request and hits another Lync server since DNSLB doesn’t maintain your state for https/https, this new Lync server doesn’t have your state information so you might be prompted to sign in. You sign have found the contact and you add him. After a while you start IM session and DNSLB send the traffic to the third Lync Server again this server doesn’t have your state information again you have to setup the session again. This approximately would be the end user experience for all functionality in Lync that use Http/Https protocol. Hence you do need a Hardware Load balancer for HTTP/HTTPS traffic in Lync Server.

HLB addresses this session problem by caching the client-server state information; when the next request comes in from Client, the HLB refers it back to same Lync Server Hence, for Web-based traffic, DNS load balancing is not a solution

Some of the advantages of using Hardware Load Balancer are as follows:

  • Quicker Automatic Failure of Client connection
  • Support for all type of Lync Server federation scenarios
  • Support for all Public IM providers (PIC)
  • Support a wide range of VOICE gateways and IPBX

The bottom line is that if you have Lync Server Enterprise edition deployment with high availability in mind a Hardware Load Balancer is a must. The added advantage is that most of time you can also use this Hardware Load Balancer as reverse proxy as well (though not advisable from a network security stand point) however it can be done for medium or small scale deployment.