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:
- What is Lync Server's Director role?
- Director server role inner workings
- Supported topologies for using the Director role
(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.
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:
- If you're deploying Edge Servers, you can deploy a Director to authenticate external users and then proxy their traffic to internal servers. When you use a Director in this manner, it relieves the Front End pool servers from the overhead of performing authentication of these users. It also helps insulate internal Front End pools from malicious traffic such as Denial of Service (DoS) attacks.
- If you deploy multiple Front End pools at a central site, you can improve performance on the Front End servers by adding a Director to that site, which alleviates the need for them to fulfill the redirect requests from clients. In this scenario, all requests go first to the Director, which then routes them to the correct Front End pool.
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.
