Lync Server 2013: Director Role Options

When most of us hear the word Director relating to Microsoft Lync Server, we begin to cringe and think about all the heated discussions that have occurred in the past, or for some, the present. Lync Server 2013 has cleared up some of the uneasiness surrounding the server role that many would call the most confusing of all Lync Server roles because of the uncertainty of whether to deploy or not deploy. With Lync Server 2013, Microsoft has eased its stance on the Director role by stating that it's now optional instead of a requirement. I'll address three areas in this article:

(To learn about the Persistent Chat Server, see "Lync Server 2013 Persistent Chat.")

The Director Role

The Director role is a server that authenticates user requests, but it doesn't home any user accounts. The Director isn't a new role to Lync Server 2013; the functionality was introduced back in the days of Microsoft Live Communications Server (LCS) 2005, which is many versions of Lync ago.

The Director role gives administrators the ability to point users to a server where users aren't homed (not intentionally, that is) and let the Director redirect the user request to the appropriate Front End server. The Director plays an important role in informing clients where their primary and backup registrars are located from a pool standpoint.

Director Inner Workings

Lync 2013 Front End servers have the same registrar service and functionality as the Director. When users register against a registrar that isn't their primary registrar (Front End server), a 301 Redirect is returned to the users' client; the error message includes the user's primary and backup registrar along with the appropriate Lync Front End server to fulfill the registration request.

When the Lync client is configured for automatic configuration, and the user begins to sign in, a DNS request for an SRV record, _sipinternaltls._tcp..com, is rendered. In a scenario where the Fully Qualified Domain Name (FQDN) of the Director is returned by the internal DNS, the client contacts the Director and begins the sign in process.

The Director retrieves information from Active Directory (AD) to determine on which pool each user is homed. The Director can also determine a user's home pool from the local RTCLocal database that resides on the local Director server and redirect the client to the correct pool. The Director points the client to the user's home pool where the client then attempts the sign in request again, this time using the correct server.

Supported Topologies

Keeping in mind that this role isn't necessarily required with Lync Server 2013, organizations can deploy the Director in the following Microsoft-supported scenarios:

Final Thoughts

The Director isn't providing any special functionality. If the Director goes down, all pools would become inaccessible when the clients queried DNS for the SRV record until an administrator makes a manual internal DNS change that points users to a Front End pool to handle the sign-in request from Lync clients. Microsoft has made the Director functionality relevant for organizations that have specific security requirements, such as allowing all external users to register to a specific internal server instead of the Front End servers. But in the end, it's good to know that this server role is merely optional and not needed for most Lync Server 2013 deployments.