I was asked this from a school district in Southern California who was rolling out OCS R2 and enterprise voice for the all their faculty and staff.
The answer depends on your OCS R2 architecture and whether your access is from internal or external networks. For most schools, a single pool would apply and therefore a director would be optional depending on your external access security requirements.
Here is some information gathered from our product team to think about when considering a director:
Director traffic flow with External user access:
Director traffic flow with Internal user access:
What are the benefits of directors?
Security: In an environment with an access edge and no director, unauthenticated traffic will be sent to your production pool for authentication. The director lets you isolate that unauthenticated traffic to a server that is less critical (Director). Some schools will find this very critical even in single pool deployments. Other schools more than likely won't care.
Performance: For remote users, the director will proxy all SIP traffic. Without directors and with multiple pools, you have to pick a pool that will proxy the traffic. This could potentially have a performance impact to the users homed on that pool.
When I should I use a director server?
Environments with multiple pools and remote access: The director serves a critical role as the "next hop" inbound from the edge and proxies traffic from remote users to the appropriate pool. A director should always be used when the customer has multiple pools and remote users.
Environments with multiple pools and no remote access: The only supported solution that provides automatic configuration of Communicator involves configuring the internal DNS records to point the client to the director. Some customers will be uncomfortable requiring the use of a remote director to sign into a local pool and may prefer an unsupported solution that involves configuring DNS differently (or use manual or group policy-based configuration).
Environments with one pool and remote access: The benefit of preventing unauthenticated SIP traffic from reaching the user pool may be sufficient to justify a director.
Environments with one pool and no remote access: Even if the customer is not currently planning multiple pools, during migrations or for piloting different versions or configurations, it will be required to establish multiple pools. Start the design with no director but add it as part of the project that installs the second pool.
The director or the pool doesn't really know if the user is external or internal. All it knows is whether it is the first hop or not (based on VIA headers). The default behavior of every OCS front end (whether in a director pool or a user pool) is to redirect traffic to the correct home server if it is the first hop and proxy the traffic if it is not.
I was asked this from a school district in Southern California who was rolling out OCS R2 and enterprise
Thanxs for explaining the director server, because you dont find any option to install the Director server role in the server deployment rWizard.
Do we need to create the DNS Srv record to point to the Director server on the internal network?
External users will of course be pointing to the the access edge.
How about hardware requirements for a directory? Surely they do not need to be as beefy as the listed hardware requirements for a enterprise pool server or consolidated edge server, right?
Oops, meant "director" there, not directory.
The director role gets installed automatically on a Front End. With smaller sized deployments this is sufficient. I have only seen this role broken to a dedicated server with large scale deployemnts (20,000 users or higher).
Currently, we have a set of Directors setup in our infrastructure. Internal and external traffic works as defined. Would there be any benefit to tuning federation setting for each pool to route out to the director than to the the access edge? Right not they route directly to access edge for federation and PIC.