Lync/Skype4B: When do we need to configure Internal Web Services Override FQDN?

The answer to this question is quite simple — we only need it if we have to split SIP traffic from HTTP/HTTPS.

We know that this answer will raise more questions, so first we should start with a little story. The Internal Web Services Override FQDN settings was introduced in Lync Server 2010. This was also the first version to support DNS Load Balancing in an Enterprise Pool.

If we just use Lync/Skype4B Clients, they are aware of DNS Load Balancing. But what about a web browser? A web browser will try only the first IP Address returned by the DNS and, if this server is down, we will get a “This page can’t be displayed”. Supposing we configure Round Robin in the DNS Server, we will eventually have a different IP Address as the first result.

The Internal Web Services Override FQDN setting only makes sense in an Enterprise Pool. In addition, we can configure it in Topology Builder > Pool Properties:

internaloverridefqdn01

However, in a Standard Pool this option is disabled:

internaloverridefqdn02

In order to configure the Internal Web Services Override FQDN in a Enterprise Pool we need to follow a few steps. As some of them can cause service disruption, we should plan these changes accordantly:

Step 1 – Enable override

In the Topology Builder, we select the Enterprise Pool that we want to change and enable:

internaloverridefqdn03

Note: This FQDN must be unique, we cannot use an existing pool FQDN or web services external FQDN.

We publish the new Topology and wait for all servers to receive the new change:

internaloverridefqdn04

Next Steps

internaloverridefqdn05

Get-CsManagementStoreReplicationStatus |ft

internaloverridefqdn06

Step 2 – Configure the Front End Servers

On each Front End that belongs to the pool we configured, we need to re-run Deployment Wizard Step 2:

internaloverridefqdn07

Request and assign certificates so as to include the new FQDN in the  SAN certificate of Front End:

internaloverridefqdn08

After restarting the Services, the Front Ends will be ready.

Step 3 – Configure Load Balancer

For this we need to follow the vendor guidelines. A complete list of supported Load Balancers is available here:

Infrastructure qualified for Microsoft Lync – Load Balancers
https://technet.microsoft.com/en-us/office/dn788945.aspx

Note: A common misconfiguration is to use port 443 to check if the server is able to handle requests, even though we should always use port 5061 to know if the server is working. Each Front End will only listen on port 5061 if the Front End Service is up and running.

Step 4 – Change the DNS Records

The final step is to make sure that the clients will use the newly configured Load Balancer. In order to achieve this, we need to create/modify the DNS Records as the examples in the following table:

FQDN Type IP/Destination
lyncwebint.gears.lab A Load Balancer IP Address assigned to the virtual service
lyncdiscoverinternal.gears.lab CNAME lyncwebint.gears.lab
meet.gears.lab CNAME lyncwebint.gears.lab
dialin.gears.lab CNAME lyncwebint.gears.lab
lyncadmin.gears.lab CNAME lyncwebint.gears.lab

Conclusion

We now have the HTTP/HTTPS configured to use the Load Balancer and the pool using DNS Load Balancing.

As a final note, we want to point out that in a full “balanced” pool the IP Address will be the Load Balancer. In this way, we don’t need to have a FQDN for SIP and another for HTTP/HTTPS.