Any pool will provide redirect functionality out of the box for both internal and external users. Now to understand how you should allow internal users to connect to pools, you must first understand how to allow Communicator 2007 clients to logon automatically (manual mode is possible but I will talk about Automatic). You can read about how to configure Automatic Logon here. It essentially consists of creating one of two records:
* _sipinternaltls._tcp.
* _sipinternal._tcp.
Both of these SRV records would point to an A record which matches a Common Name (CN) or a Subject Alternative Name (SAN) on the certificate of your Front End Server.
You may want to load balance these DNS requests across multiple pools, but unfortunately, this won’t work. But why not? Can’t we create 2 SRV records with the same weight so they get load balanced across multiple pools? Well, no. The communicator client was not coded to take 2 SRV records with the same weight and allow for the use of Round Robin. Because of this, you are only allowed to have one SRV point to a dedicated pool. If this pool ever goes down, you can change where the SRV record is pointed. The client will begin to utilize the new DNS changes and therefore use the new Pool once the Minimum TTL has passed for that DNS record and the client will re-query DNS and find the new Pool to log on to.
You may recall a screen below when configuring your pool:
If you take a look at the deployment guide, it states the following:
If this server or pool will also be used to authenticate and redirect requests for automatic sign-in, then select the Use this server or pool to authenticate and redirect automatic client logon requests check box. When you configure automatic client logon, you must designate one (and only one) Enterprise pool or Standard Edition Server to authenticate and redirect client sign-in requests.
As you can see, only one Pool should be designated to authenticate and redirect client-sign in requests. This is a bit misleading. It doesn’t really mean that if you are deploying multiple pools you must only place a checkmark in that box for a single pool. All it really means is that you should only have one SRV record pointed to a Pool at any given time. In other words, in your entire environment, you should have only one SRV record for automatic logon total.
The reality of that checkmark is that it doesn’t make any modifications to OCS and regardless if you place a checkmark in the option discussed above, your Pools will be able to redirect users. All it does is enable some additional screens during Setup to allow you to make additional and optional configuration modifications to your Pool; none of which are detrimental to your OCS install. This is what I verified with the PSS escalation engineer I dealt with recently for a different issue.
Personally, for every Pool you configure, I would go ahead and place a checkmark in that box. You will then be able to see all the options during Setup that you otherwise would not see.
Now because of all the above functionality with all Pools having the native functionality to redirect users, why would you want to use a Director? A Director is simply a Pool that has no users. It’s not even required to disable the other roles on the server but is rather an optional configuration step.
One benefit of having a Director is by having your SRV record point to this one Director or Pool of Directors. If you have a large environment, by not having a Director, you are having one of your Pools be hammered with client requests which can significantly reduce the performance of your Pool which are housing users. So by having your SRV record point to a Director, you are reducing the performance hit on your other Pool by allowing your Director to absorb client logon requests which will then be redirected to your pool.
Another item to be aware of, is that for external users, when traffic comes from an Access Edge Server, the header information includes information about the connecting client. Because of this, when external traffic gets sent from an Access Edge to the next-hop Pool or Director, that Pool or Director will authenticate the user and proxy SIP traffic to the correct Pool rather than re-directing the client. This is why I stated that the Resource Kit states that external users do not get re-directed (which is true), but you do not need a Director. Having a Director in a large environment will allow this proxying to be done on a Director which will reduce the peformance hit on your next-hop Server or Pool by allowing your Director to absorb the performance hit from proxying this SIP traffic.
Another benefit to having a Director is if the server gets DOS attacked, only the Director gets taken offline and not one of the Pools which are housing users.
I would recommend housing your Director on a server that is located close to where the majority of your users are located. So if the 75% of your users are located in North America and 25% are located in Europe, and you have one pool for North America and one Pool for Europe, I would create a Director in North America. The Director Role can be deployed on a Standard Edition Server or an Enterprise Edition Server; although Enterprise Edition will most likely be overkill.
find
out more on MCSE
Training, MCSE
Certification, MCSE
2003 Training, MCSE 2003
Certification
