1. Certificate Requirements
The Director role in Lync Server 2013 is much
like any other role in that it uses certificates both for communication
to other servers and for client services. There are three types of
certificates a Lync Server 2013 Director requires, each with slightly
different naming requirements. All three purposes and required names
are usually combined on a single certificate, but can be broken out
separately if required. These are the three types:
• Default—The default
certificate is used for MTLS communications between servers, and for
securing SIP signaling in client communications. The certificate should
contain the pool name in the subject field, each Director’s name as a
subject alternative name, and any 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 should contain
the internal web services FQDN defined in the topology for the pool and
any simple URLs such as dialin, meet, lyncdiscover, and admin. This certificate is bound to the internal web services website in IIS.
• WebServicesExternal—The
WebServicesInternal certificate is used to secure communication for
internal clients to the web services. This certificate should contain
the external web services FQDN defined in the topology for the pool and
any simple URLs such as dialin, meet, lyncdiscover, and admin. This certificate is bound to the external web services website in IIS.
2. SRV Records
The main point of a Director pool from an
internal perspective is that it serves as the central point of sign-in
and authentication in a deployment. After a Director is installed,
clients will not automatically use it, so the SRV records for each SIP
domain must be changed to point to the Director pool instead of a Front
End pool. After the SRV records have been updated, any new client
sign-ins will locate the Director, attempt sign-in, and ultimately be
redirected to their primary registrar.
An issue with the
architecture of Office Communications Server 2007 was that only a
single DNS SRV record was used by clients. If a Director was in use,
the SRV record would typically point to it to ensure that 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
would initially authenticate 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, no clients would ever be able to sign in. This
dilemma was mitigated since Office Communications Server 2007 R2
supported the use of multiple weighted SRV records, although the
feature wasn’t actually documented until Lync Server 2010.
As in Lync Server 2010, Lync Server 2013
endpoints will now recognize multiple SRV records for automatic sign-in
with different priorities, and if one pool or host is unavailable, they
will move on and try the next host. This means 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
option to use two Director pools with differing priorities, but using
two Director pools in a single location would be necessary for only the
most stringent of availability requirements. A more typical use-case
would be to have two separate Director pools separated by major
geographical boundaries.
Note
When resolving SRV records in DNS, clients
will prefer the record with the lowest numerical priority and highest
numerical weight. The terminology is a bit deceiving so be sure to
always place a Director pool as the lowest priority to ensure that it
is used before any other pool with a higher priority.
3. 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 1.
Figure 1. 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.
