Microsoft Lync Server 2010 : Director Overview

When a client signs in to a Director, he is first authenticated and then informed which pool to register. Directors are beneficial for deployments where multiple pools exist because they provide a single point of authentication for the endpoints. When external access is used, a Director serves as the next hop server between Edge Servers and the Front End pools.

Dedicated Role

The Director role in Lync Server has changed slightly and is much more specialized than in the previous releases of Communications Server. In prior versions, users installed the Director role the same way as a Front End Server followed by a series of manual steps to deactivate most of the Front End Services. These steps were well documented, but it was up to the administrator to follow them correctly. It was impossible to prevent administrators or help desk users from homing new user accounts on a Director pool because they appeared just like any other front-end pool choice when enabling user accounts.

Now, in Lync Server, the Director is a dedicated role separate from a Front End Server. It can be installed like any other role and does not require manual deactivation steps. This separation not only improves the ease of deploying a Director, but increases the security and stability of the role by not installing unnecessary components and leaving deactivation to the administrator.

Benefits of a Director

When multiple front-end pools are deployed, an administrator must decide which pool, or pools, the SRV records required for automatic client sign-in will point to. Without a Director, the pool selected with the lowest SRV record priority becomes the central point of authentication for all users. Users not homed to this pool are authenticated and provided with the name of the pool where their account is hosted. Then the endpoints register to their home pool instead of the pool used for automatic client sign-in. This is usually how a Director performs. Without a dedicated Director, a pool is tasked with handling authentication and Director duties for all other pools in the deployment.

The benefit of a dedicated Director from an internal perspective is that initial authentication requests are offloaded from Front End Servers. In many environments, offloading authentication requests can be negligible. In deployments near capacity of the hardware, this enables the Front End Servers to focus on other core services such as messaging, conferencing, and voice.

Internal Endpoint Sign-In Process

There is no logic in an endpoint to indicate it is initially connecting to a Director and not a Front End Server. This means that the same DNS records, authentication methods, and signaling are used from the endpoint’s perspective. The Director first authenticates the user and then provides the name of the pool that the endpoint should register to instead of which point the client will attempt another sign-in to the pool the Director provided. The sign-in process looks like the following:

After a Director authenticates an endpoint and provides the name of the correct front end pool, it removes itself from the communication path. An endpoint communicates with its own front end pool after receiving the information. Figure 1 demonstrates how a Director authenticates internal users and then removes itself from the communication path.

External Access

Another strong benefit of using a Director is its capability to serve as a barrier between internal pools and external traffic. To understand the benefit, note that Edge Servers do not authenticate external user requests across the Internet and merely pass traffic to an internal server to handle authentication. Without a Director, external traffic authenticates by a Front End pool, or, in other words, anonymous Internet traffic is allowed to communicate with an internal domain member server.

Instead of allowing authentication requests from an Edge Server to pass directly to a Front End pool, a Director can be placed between a communication path to authenticate users before external traffic reaches a Front End Server. In situations where multiple internal pools exist and all leverage a single Edge Server pool, a Director also points user requests to the correct pool or next hop. Unlike the internal scenario, a Director used as a next hop stays in the communication path at all times, which ensures the protection of internal pools. Figure 2 shows how a Director sits in the communication path from remote users to a Front-End pool.

Denial of Service

A compelling reason to deploy a Director is that it provides some isolation for Front End pools from the Edge Servers and Internet. If there was a denial of service attack against the Edge Servers, only the Edge Servers and Director would be affected. This separation enables the front-end pools to continue operating as normal without being affected by the attack. If a Director was not deployed as the next hop from an Edge Server, an attack could potentially impact a front-end pool and cause a much larger disruption to user services.

Placement

A Director pool should be located where the majority of the user base exists because it is the initial point of sign-in for all users. It makes sense to place a Director in a datacenter with a Front End pool, but it’s unnecessary to use a Director in branch offices with small user counts.

Another recommendation when planning for placement is to use a Director in any location where an Access Edge Server role exists. As unauthenticated traffic from the Internet passes to the internal network, the Director is a short hop away from the Edge Server and can authenticate the traffic quickly. If the Director is in another location, traffic from an Edge Server has to traverse a WAN connection before being authenticated.

Note

In remote locations where it makes sense to deploy a Web Conferencing and A/V Edge Server to support local media paths, it isn’t necessary to deploy a Director. This is because the signaling traffic a Director sees is only used between the Access Edge Server role and front end pools, unlike media paths that flow directly between endpoints. Figure 3 shows how a Director in one site still serves a remote user in another site for signaling traffic.

Figure 3. Signaling and Media Paths with a Director and Conferencing Edge Server in Additional Site

Standard Edition Versus Enterprise Edition

In previous versions of Office Communications Server, an administrator had the option to deploy both Standard Edition and Enterprise Edition Directors, which caused some confusion around deployment methods and licensing. In Office Communications Server 2007, multiple Directors could be deployed either as an array of multiple Standard Edition Front Ends, or as a pool of multiple Enterprise Edition servers with a dedicated back-end SQL server database. Office Communications Server 2007 R2 simplified these options, and the only option for Director high availability was a pool of Enterprise Edition servers. This model was problematic because a pool of Directors created its own databases, which matched the name as the front end pool. To alleviate this issue, a separate SQL instance was required to separate the two.

In Lync Server, this is simplified so that Directors no longer have a Standard Edition or Enterprise Edition designation. The deployment model closely resembles the array of Standard Edition Servers option, which was removed from Office Communications Server 2007 R2, where each server has a local database instance. This solves the duplicate database name issue and makes the deployment significantly easier because SQL server sets are not required. The Director role also does not require a Standard or Enterprise Edition license in Lync Server 2010.

Back End Database

In Lync Server, each Director stores its information in a local SQL Server 2008 Express database instance. This change alleviates an issue found in previous releases where a Director used the same back-end database name as the Front End Servers. When the Front Ends and Directors used the same database name, it became impossible to use the same SQL Server instance for both functions, which meant a new SQL Server or SQL instance had to be provisioned exclusively for the Director pool. The other downside was that a Director has a relatively low usage of the SQL Server, so providing an exclusive server or instance was generally considered a waste of resources. The change to a local database instance in Lync Server enables more businesses to include the Director role in their deployments.

Web Services

In Lync Server, the Director role is capable of providing a subset of Front End web services to the endpoints. A primary use for this scenario is the Client Version filter used to check the version of software endpoints sign-in with and potentially block older or unwanted versions from successfully connecting. In some cases, the filter is used to provide the client with a link to a web page or automatically provide an update for the software.

The device update service is another web service that can be deployed on a Director. When the DNS records for client updates points to a Director, the phone endpoints can download firmware updates from there instead of a Front End Server. Depending on the workload of Front End Servers in the environment, it might be beneficial to use a Director for these functions.