Optional Role
Perhaps the biggest change for the
Director in Lync Server 2013 is that Microsoft has declared it an
optional role in the Lync topology. In prior years the documentation
treated it as recommended, especially when deploying external services.
Microsoft isn’t trying to say that the Director isn’t needed anymore;
but many organizations have pushed for Lync Server 2013 to require less
overall server count in the architecture, and Microsoft has responded
to these requests by providing flexibility within the deployments based
on business needs. This same initiative can be seen with the movement
of the Archiving and Monitoring servers roles to services on the Front
End pool, and organizations can further reduce server count by deciding
not to deploy Director pools.
Why Deploy a Director?
The optional designation doesn’t mean a
Director should always be excluded from deployments—in fact, it still
makes sense to deploy Directors in many cases. Organizations should
review their own business requirements and consider the following
points before making a decision on the Director pool deployment:
• Directors provide an
additional layer of security from denial-of-service attacks at the
Edge. Unauthenticated requests will never reach a Front End pool and
affect internal users.
• Anonymous web traffic for Lync simple URLs such as meet, dialin, and admin can be terminated at the Director’s web services.
• Directors provide centralized authentication and redirection for environments with multiple pools.
• Directors simplify the external federation and remote access signaling paths.
Placement
A Director pool should generally be
placed in a location where the majority of the user base exists since
it will be the initial point of sign-in for all users. It makes sense
to place a Director in a datacenter with a Front End pool, and it’s
unnecessary to use a Director in branch office locations with small
user counts. A backup Director pool with a slightly higher SRV record
priority can be placed in a secondary datacenter. This ensures that
internal clients can still locate a Director for sign-in even if the
primary Director pool is unavailable due to a WAN or datacenter outage.
Another recommendation when planning
for placement is to use a Director in any location where an Access Edge
server role exists. This way, as unauthenticated traffic from the
Internet is passed to the internal network, the Director is just a
short hop away from the Edge server and can authenticate the traffic
quickly. If the Director were in another physical location, that
traffic from an Edge server would have to traverse a WAN connection
before even being authenticated.
In remote locations where it might make sense
to deploy an 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 used only between the Access Edge server role and the
Front End pools, unlike the media paths that flow between the endpoints
shown in Figure 4.
Figure 4. Signaling and media paths with a Director and Conferencing Edge server in an additional site.
Standard Edition Versus Enterprise Edition
For those migrating from Office
Communications Server 2007 R2, the licensing situation around Directors
and high-availability was always a confusing topic. In Office
Communications Server 2007 an administrator had the option to deploy
both Standard Edition and Enterprise Edition Directors, which caused
some confusion around deployment methods and licensing. Back then,
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. These options were
simplified with Office Communications Server 2007 R2, and the only
option for Director high-availability was a pool of Enterprise Edition
servers. This simplified the options, but the model was problematic
because a pool of Directors would create their own databases that
matched the same name as the Front End pool. To alleviate this issue,
an entirely separate SQL instance was required to separate the two.
In Lync Server 2010 this was again simplified
and Directors no longer have a Standard Edition or Enterprise Edition
designation. The deployment model now more closely resembles the array
of Standard Edition servers option from Office Communications Server
2007, in which each server has a local database instance. This solves
the duplicate database name issue and makes the deployment
significantly easier because no SQL server setup is required. Nothing
has changed from Lync Server 2010 in Lync Server 2013 as regards this
model. Directors are still deployed as a single-computer pool or a
multiple-computer pool for high-availability. The Director role also
does not require a Standard or Enterprise Edition license in Lync
Server 2013.
Back-End Database
In Lync Server 2013 each Director
stores its information in a local SQL Express 2012 database instance.
This change alleviates an issue found in previous releases in which a
Director used the same back-end database name as the one for the Front
End servers. With the Front Ends and Directors using the same database
name, it became impossible to use the same SQL server instance for both
functions, which meant that 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. Continuing to use a local database instance in Lync
Server 2013 will allow more businesses to include the Director role in
their deployments.
Back-End Database
In Lync Server 2013 each Director
stores its information in a local SQL Express 2012 database instance.
This change alleviates an issue found in previous releases in which a
Director used the same back-end database name as the one for the Front
End servers. With the Front Ends and Directors using the same database
name, it became impossible to use the same SQL server instance for both
functions, which meant that 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. Continuing to use a local database instance in Lync
Server 2013 will allow more businesses to include the Director role in
their deployments.
Collocation
The Director role cannot be
collocated with any other server role in Lync Server 2013. It must be
installed on a server with no other roles to be fully supported by
Microsoft.
