• Article

Why Deploy a Director?

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

What is the use and value of the Director role? To be clear, the Director role doesn’t exist. You won’t find this server role in the Communications Server 2007 and 2007 R2 Setup. A Director is simply a Standard Edition Server or Enterprise pool that has NO users homed on it. This article will help you understand the value of a Director and help you decide if you want to use one in your organization.

Author: Rui Maximo

Publication date: January 2010

Product version: Office Communications Server 2007

Clearing Up the Confusion

There has been some confusion about the use and value of the Director role. To be clear, the Director role doesn’t exist. You won’t find this server role in the Communications Server 2007 and 2007 R2 Setup. So then what exactly is a Director? A Director is simply a Standard Edition Server or Enterprise pool that has NO users homed on it.

The follow up question that immediately comes to mind is, "What value does an empty Standard Edition Server or Enterprise pool (that is to say, Director) offer?" By empty, I mean no users are assigned to it. This question is the subject of this article.

After you understand the value a Director can offer, you’ll be able to decide whether to deploy a Director in your organization. If you decide to deploy a Director, the first link in the Additional Information section later in this article provides in-depth details about the deployment aspects of a Director. Deployment considerations will not be covered here.

A Director behaves differently depending on whether the user is connecting internally or externally.  Therefore, it’s best to describe the Director’s value proposition in terms of those two scenarios.

Internal Users Connecting to Communications Server

From the perspective of the end-user, if the user is internal, the client, when signing in the user, needs to locate the user’s home pool. If the client is configured manually using the FQDN of the user’s home pool, a Director is not necessary, and you can skip this entire discussion.

If the client, Office Communicator, is configured for automatic configuration, it will issue a DNS query for the SRV record, _sipinternaltls._tcp.<domain>.com. If the internal DNS server is configured to return the FQDN of the Director, the client will contact the Director and attempt to sign in. Because the Director pulls information from Active Directory directory services to determine on which pool each user is homed, the Director can determine the user’s home pool from its local database and redirect the client to the correct pool. In this scenario, the Director behaves very much like a DNS server. It points the client to the user’s home pool and disconnects. The client then attempts the sign-in request again, this time using the correct server. The result is a double authentication: once by the Director and again by the user’s home server.

A key point is that the Director gets out of the communication path between the client and the user’s home pool. It’s a good thing that the Director doesn’t remain in the communication path between the client and the user’s home pool because otherwise the Director becomes a bottleneck. If the Director went down, all pools would become inaccessible when the clients queried DNS for the SRV record.

Up to now, I’ve described how the Director functions. So back to the original question, "What value does a Director provide in this scenario?" The Director offloads the task of directing client sign-in to the appropriate home pool where the user is signed in. If a Director wasn’t deployed in a multi-pool Communications Server environment, the burden of redirecting client sign-in requests to the correct pool would have to fall to one of the existing pools because every pool provides the same functionality as a Director. So, why dedicate a pool to just redirecting users to their home pool when any pool with users homed on it can perform this function? The only justification for doing this is that this improves the pool’s performance, particularly during "rush hour" times of the day when a large majority of the user population signs in to Communications Server such as in the morning when employees arrive at the office. Such impact could affect the overall performance of the pool. Users homed on this pool could experience slower response and dropped connections. However, this is only a problem if the pool is operating at near capacity. Realistically, most IT organizations overprovision servers to avoid this problem.

In the majority of cases, deploying a Director for internal use only is unnecessary. The value proposition of the Director really comes in the scenario for external users.

External Users Connecting to Office Communications Server

If the user is external, the user’s client signs in through the Edge Server. The Edge Server’s next hop should be the Director assuming a Director is deployed. The Director, not the Edge Server, validates the user’s credentials and authenticates the user before forwarding the SIP connection to the user’s home pool. Unlike the internal user scenario, the Director remains in the communication path between the client and the user’s home pool as well as the Edge Server. Because the Director has a trusted connection (MTLS) to the user’s home pool, the user’s home pool trusts the Director to have properly authenticated the user, and therefore does not re-authenticate the user. Because the Director proxies the client’s connection to the user’s home pool, there is no double authentication.

The Director in this scenario behaves differently than in the internal user scenario. The Director offloads the task of authenticating the user and proxying the request to the correct pool. The Director serves as a buffer against attacks originating from the Internet. If a DoS attack was mounted, the Edge Server and Director would be under fire; however, the internal pools would be isolated and protected from such attacks.

Additional Information

To learn more, check out the following articles:

Office Communications Server Resources