In Microsoft Office Communications Server (OCS) 2007 R2 and earlier, the only supported load balancing solution is a hardware load balancer. Fortunately, Microsoft introduced DNS load balancing in Lync Server 2010.

DNS load balancing in Lync Server 2013 hasn't changed much from that in Lync Server 2010. I'll answer three questions commonly asked about the Lync DNS load balancing solution found in these two versions:

  • What is Lync DNS load balancing?
  • How does it work?
  • What are the caveats?

What Is Lync DNS Load Balancing?

Lync DNS load balancing balances the network traffic that's unique to Lync Server, such as Session Initiation Protocol (SIP) traffic and media traffic. With this out-of-the box solution, administrators can quickly ensure some resiliency for their Lync enterprise pools. However, all HTTP and HTTP Secure (HTTPS) traffic still needs to be balanced by a supported hardware- or software-based solution. Lync DNS load balancing is supported for Front End pools, Edge pools, Director pools, and stand-alone Mediation pools.

How Does Lync DNS Load Balancing Work?

Before I explain how Lync load balancing works, I want to first dispel a myth about it. Lync DNS load balancing is not the traditional round-robin DNS, with which most administrators are familiar.

The best way to show the difference between the two types of load balancing is with an example. Suppose that you have two Lync 2013 Front End Servers, each with their own respective IP address. The first Front End Server has an IP address of The second Front End Server has an IP address of

In the round-robin DNS approach, a Lync client would get back only one IP address when it's requesting to sign in. For instance, suppose that three Lync clients sent sign-in requests. The first client would receive the IP address of, the second client would get back, and the third client would receive

Lync Server's way of handling DNS load balancing follows a different pattern. For starters, you need to configure a pool for DNS load balancing. Each Front End Server in the pool must have a Fully Qualified Domain Name (FQDN). The pool must also have a FQDN (e.g.,, which resolves to the physical IP addresses of the servers in the pool. Finally, the pool's Web Services needs a separate FQDN (e.g.,, which resolves to the virtual IP (VIP) address of the pool. Figure 1 shows a sample pool.

Pool Configured to Use Lync DNS Load Balancing

Table 1 shows the IP addresses for that pool.

Table 1: Lync DNS Load Balancing Table for the Pool in Figure 1


IP Addresses

In the Lync DNS load balancing approach, each Lync client gets back the IP addresses of all the Front End Servers when it's requesting to sign in. So, in this example, each client gets back the IP addresses of and The client would then try one of the IP addresses. If that connection fails, it would try the other IP address.

What Are the Caveats of Lync DNS Load Balancing?

Before implementing Lync DNS load balancing, you need to be aware of the following caveats:

  • Legacy clients and servers (in a federated scenario) work to a limited degree in a pool set up for DNS load balancing. They're able to connect to the first server that responds to the DNS query. However, if the first server that responds isn't available, the client or server won't be able to route to the additional IP addresses that are available.
  • If you've integrated Lync Server and Microsoft Exchange Server for the purposes of providing Enterprise Voice and unified messaging (UM) capabilities, you need to be running Exchange Server 2010 SP1 or later to leverage Lync DNS load balancing.
  • The internal and external interfaces of an Edge pool must use the same type of load balancing. They can't be mismatched. For example, you can't have one using DNS load balancing and the other using hardware-based load balancing.

A Good Start

Using the Lync DNS load balancing solution is pretty appealing, as it's ready to use right out of the box. It's a good solution to meet the immediate need of providing resiliency for Front End Servers. However, you can't totally escape from using a hardware- or software-based load balancing solution if you need to provide resiliency for HTTP and HTTPS traffic.