When you are deploying a single Standard Edition Server or Enterprise pool, your topology remains simple. However, to handle a large number of users or users who are geographically dispersed, deploying multiple Standard Edition Servers or Enterprise pools might be necessary. In such situations, it is best to deploy a Director or array of Directors. The Director server role directs client traffic to the correct home server. Before explaining why it is important to deploy this role, some background information is necessary.
When users sign in to Office Communications Server, Office Communicator performs a DNS Service Record Locator (SRV) query to locate an Office Communications Server (Access Edge Server, Director, Standard Edition Server, or Enterprise pool) that is authoritative of the user’s SIP domain, which is the right portion of the user’s sign-in address. The client contacts the Internet Protocol (IP) address returned from the DNS query and attempts to sign in to this server. If this server is the user’s home server, the server signs in the user. If not, this server redirects or proxies the connection to the user’s home server or pool.
This will always be the case if your organization has only a single home server or pool. However, if you have deployed multiple Standard Edition Servers and Enterprise pools within your organization, which Standard Edition Servers and Enterprise pools do you advertise for this SRV record in DNS? Maybe you publish the fully qualified domain name (FQDN) of all your Standard Edition Servers and Enterprise pools. In that case, the DNS SRV query might or might not return the user’s home server when Office Communicator queries DNS. If the DNS query returns the FQDN of a server that is not the user’s home server, this server must redirect the client to the user’s home server. This makes the initial sign-in traffic nondeterministic because clients signing in are not guaranteed to reach the user’s home server in the first hop.
This nondeterministic configuration has several effects. First, each home server and pool must account for the performance load created from redirecting client requests attempting to sign in users not homed on that server or pool. In the worst-case scenario, every home server and pool must handle the load of redirecting sign-in traffic for all users in your organization. Second, if the DNS query returned directs the client to a server that is unavailable, the sign-in experience will be affected because the client must wait for the network timeout to expire before attempting to connect to another server.
To avoid home servers from having to redirect client traffic to the correct home server, you can elect to advertise a single Standard Edition Server or Enterprise pool in DNS for this SRV record. This server can be solely in charge of directing Office Communicator clients to their user’s correct home server when signing in. This, in effect, specializes the role of a Standard Edition Server or Enterprise pool to that of a Director redirecting client traffic to the correct home server. Therefore, the server role name, Director, was designated. Although the Director can serve as a home server by assigning users to it, it is not recommended to assign users to a Director.
It is recommended to deploy a Director role when your organization hosts multiple Standard Edition Servers or Enterprise pools. The Director role forces the sign-in traffic into a deterministic path. Instead of publishing the FQDN of the Standard Edition Servers and Enterprise pools in DNS, the DNS SRV publishes the FQDN of the Director or bank of Directors. When Office Communicator attempts to sign in the user, its DNS SRV query returns the FQDN of the Director. The Director knows how to locate the user’s home server and redirects the client to that server. The Director’s role is to redirect internal clients to the correct Standard Edition Server or Enterprise pool where the user is homed on, as shown in Figure 3-5. This configuration allows Standard Edition Servers and Enterprise pools to handle SIP traffic only for their users.
The process illustrated in Figure 3-5 is as follows:
The UR synchronizes user information with Active Directory domain controllers.
Communicator performs a DNS SRV query.
The DNS returns the FQDN of the Director.
Communicator connects to the Director.
The Director redirects Communicator to the user’s home server or pool.
Communicator signs in to the user’s home server or pool.
In addition to helping route traffic for internal deployments, a Director plays an important role for external topologies. When configuring federation, public IM connectivity, or remote access, deploying a Director as the Access Edge Server’s next hop is required when remote access for users is needed. By using a Director or bank of Directors, the only IP address and port number that need to be opened on the internal firewall is access to the Director on port 5061 for SIP traffic.
By restricting the Access Edge Server to reach only the Director, you can limit access to your internal network if the Access Edge Server is ever compromised. None of the internal Standard Edition Servers and Enterprise pools are directly accessible by the Access Edge Server.
The Director provides the following benefits:
Authenticates remote users. The Director prevents unauthorized users from entering the internal network.
Proxy remote user connections to the correct Standard Edition Server or Enterprise pool. This is necessary because remote user connections cannot be redirected.
Denial of Service (DoS) mitigation. Verifies the intended recipient of a message is a valid user. This protects internal servers from processing invalid messages from a public IM connectivity or federated partner.
For outgoing connections to the Access Edge Server, the Standard Edition Servers and Enterprise pools route traffic destined for external users (that is, federated contacts, public IM connectivity contacts, and remote users) to the Director. The Director then proxies the connection to the Access Edge Server. This is shown in Figure 3-6.
