Web Services FQDN Overrides

When a Director pool is created in the Topology Builder, the web services FQDNs are automatically provisioned with an option to override the internal and external FQDNs. When a single Director is deployed, overriding the FQDN is unnecessary, but when multiple Directors are deployed, it might be necessary to change the URLs depending on load-balancing methods.

If a hardware load balancer is being used for the SIP, HTTP, and HTTPS traffic, it is perfectly acceptable to use the pool FQDN suggested by the Topology Builder. This works just fine because all the traffic is destined for the same virtual IP hosted by the load balancer.

As in Lync Server 2010, Lync Server 2013 has the option to use DNS load balancing for SIP traffic, but a hardware load balancer is still necessary for balancing HTTP and HTTPS traffic. This configuration means there is a split in the services, and one FQDN must resolve to the pool for SIP traffic and another FQDN is necessary for the web services traffic. These two FQDNs will resolve to different locations; the pool name will always resolve to Director pool member servers, and the web services FQDN will resolve to a load balancer virtual IP, as shown in Figure 9.5.

Figure 9.5. Using a combination of DNS and hardware load balancing for Director traffic.

The web services can also be configured differently for internal and external traffic depending on existing infrastructure. For example, an organization might use a combination of DNS load balancing and a hardware load balancer for all internal pools, so overriding the internal FQDN is required internally. The web services names will resolve to a load balancer VIP internally, and resolve to another load balancer VIP remotely through the reverse proxy.