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.