Microsoft Lync Server 2010 : Director Configuration

Certificate Requirements

The Director role in Lync Server is much like any other role in that it uses certificates for communication to other servers and for client services. There are three different types of certificates a Lync Server Director requires, each with slightly different naming requirements. Typically, the same certificate will be assigned to each three functions.

• Default— The default certificate is used for MTLS communications between servers and for securing SIP signaling in client communications. The certificate contains the server name in the subject field, the pool name as a subject alternative name, and internally supported SIP domains as a subject alternative name in the sip.<SIP Domain> format.

• WebServicesInternal— The WebServicesInternal certificate is used to secure communication for internal clients to the web services. This certificate contains the internal web services that FQDN defined in the topology for the pool. This certificate is bound to the internal web services’ website in IIS.

• WebServicesExternal— The WebServicesExternal certificate is used to secure communication for external clients to the web services. This certificate contains the external web services FQDN defined in the topology for the pool. This certificate is bound to the external web services’ website in IIS.

SRV Records

An issue with the architecture of Office Communications Server 2007 and 2007 R2 was that clients used only a single DNS SRV record. If a Director was in use, the SRV record typically pointed to it to ensure users signed in to a Director first and not directly to a front end pool. On one hand, this provided the administrator with control over where users initially authenticated to, but on the flip side this represented a single point of failure. If there was an issue with the Director or pool of Directors, clients would not be able to sign in. This dilemma can be mitigated in a few ways with Lync Server; either by adding more nodes to a pool or by using multiple SRV records with different priorities.

Now, endpoints recognize multiple SRV records for automatic sign-in with different priorities. If one pool or host is unavailable, they will try the next host. This means that organizations can deploy a Director with the lowest priority SRV record, but also have the automatic sign-in backup be a front-end pool with a higher priority in case the Director pool is unavailable. There is also the potential to use two Director pools with different priorities, but this is necessary only for the most stringent of availability requirements.

Web Services FQDN Overrides

When creating a Director pool 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 generally unnecessary, but when multiple Directors are deployed, it might be necessary to change the URLs depending on load-balancing methods.

If a traditional load balancer is used for the SIP, HTTP, and HTTPS traffic, it is acceptable to use the pool FQDN suggested by the Topology Builder. This works great because all of the traffic is destined for the same virtual IP hosted by the load balancer. This kind of configuration is shown in Figure 1.

Within Lync Server, a DNS load balancing for SIP traffic option exists, but a hardware load balancer is still necessary for balancing HTTP and HTTPS traffic. This configuration means that 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 resolve to different locations; the pool name always resolves to Director pool member servers and the web services FQDN resolves to a load-balancer virtual IP. This kind of scenario is shown in Figure 2.

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 pool load balancing, so overriding the internal FQDN is required internally.

In this example, consider a reverse proxy scenario where the reverse proxy has its own form of built-in load balancing such as with Microsoft Forefront Threat Management Gateway. It can resolve the web services directly to the pool FQDN because SIP traffic is not carried through the reverse proxy. A reverse proxy sending external traffic to the Director pool that uses a load balancer internally is shown in Figure 3.

Figure 3. External and Internal Web Services Names

Web Services Ports

When configuring the internal and external web services for a Director, options exist to define the listening ports and the published ports. The differences between the two are outlined here:

• Listening ports— Ports that the IIS services bind to on the Lync Server.

• Published ports— Ports used by clients to access the services. These ports might be redirected by a load balancer, reverse proxy, or firewall to the listening port on a server.

In a default installation, the internal web services are listening and published on ports 80 and 443. However, because the external web services use a separate IIS site, they need to run on alternate ports so that they do not conflict with the internal web services. In a default scenario, the external web services run on port 8080 for HTTP and 4443 for HTTPS. Figure 4 shows how the different IIS port bindings are used for external and internal traffic.

Reverse Proxy

To support external access to the Director web services, use a reverse proxy. It is possible to allow Internet traffic directly to the external web services ports, but a reverse proxy helps to increase security by inspecting the HTTP and HTTPS traffic and filtering any malicious requests.

High Availability

Redundancy for the Director role is provided in the same way as with Front End Servers and requires adding more Directors to a pool. Also like a front-end pool, up to 10 servers can be defined in a Director pool. Load balancing is achieved through the same methods as Front End Servers by providing multiple IP addresses, which resolve to the pool name of the Directors. If one IP address is unavailable, the endpoint attempts to log in to another IP address provided for the pool in DNS.

Adding Directors to a Pool

Adding an additional Director to a pool is much like creating the initial pool. The topology must first be updated and published to reflect the change. Follow the steps described previously to import the existing topology in Topology Builder, and then use the following steps to include an additional pool member: