The Resource Kit states that external users cannot be re-directed to their correct pool without the use of a Director. This is partially untrue. Directors are always optional in any circumstance even if you have multiple pools with external access. After talking with Tom Laciano over at LCSKid as well as a PSS escalation engineer, I think I have a pretty good understanding of the Director Role and how Pools redirect and proxy users and figured I would share with you as I have seen several posts where people have been confused about when it’s needed.
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.<domain> – for internal TLS connections
- _sipinternal._tcp. <domain> – for internal TCP connections (performed only if TCP is allowed)
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.
Harry says
The remaining question –
2. Now comes Edge server. Again all the external users will go to the primary edge server and then it will route them to the homed FE server. I also know that primary edge server will only be used for SIP traffic and for media traffic only local edge servers will be used. It makes life little easy and strong case to have an edge server per site. While doing some reasearch i found this article : http://infrastructurehelp.wordpress.com/2010/11/0… which talks about edge server resilency. Does it also means that having 3 SRV record for each edge server, it will make sure that external traffic will only go through the local edge server(both SIP and Media traffic).
Harry says
I am working on a design for lync server 2010 for past few days and need your help. it is single forest and multiple child domains scenario (consider Contoso.com, ab.contoso.com, xy.contoso.com, pq.contoso.com). with single SIP domain. Domains are at different geography and connected by wan. Since the requirement is that the local traffic remains local, we have gone for 3 pools per child domain. we have 1 director per site and 1 edge server per site.
1. Does having 3 directors, each per pool, will serve the purpose. Since, we are using automatic client logon, every user will go to that director only for which we have registered the SRV record in the DNS. Rest 2 directors will remain reduntant. Please confirm if it is true. Or is there any way i can make users connect only the local director server. Will those 2 directors be used in any way.
Joker says
Thank you Elan! I have been looking into Directors for an OCS design I have been working on. We have 3500 users – 1400 at HQ and the rest across 10 remote sites. Initially there will be one pool and Edge services at the HQ but later there will be additional pools at the remote offices. Of course Microsoft recommends we use Directors in my scenario for performance and security reasons. However, this would require we install 4 more physical servers – 2 at HQ and 2 at our standby DR site. We don't mind increasing the spec of our HQ pool to handle proxying and this is far more cost-effective for us to do so. Also, we have provided little protection against DoS attacks for other internet-facing services, so it doesn't make sense for us to do so for OCS – it is a risk we are willing to take. However, I wanted to make sure that in a DR scenario we can manually fail over to our standby OCS estate at our DR site and have that pool redirect/proxy clients as necessary. I was worried this was not posible due to the text "you must designate one (and only one) Enterprise pool or Standard Edition Server" above. However, you have now answered that question for me. Thank you again Elan!
Elan Shudnow says
My assumption is that the record is written to SQL so if you run your Configure your Server wizard again, it pulls all previously entered data which would include the checkmark. That’s probably why that value is most likely written into the dbo.MSFT_SIPPoolExtData table.
Either way though, all pools can autologon and redirect. All the SRV is doing is redirecting the client so any pool would have to alow for autologon. And you really can point the SRV to any pool you want since all pools can allow for redirection.
Mika Seitsonen says
First, thanks a lot for your informative and valuable postings on OCS issues!
I dug a bit deeper into the checkmark issue on client logon settings screen. If you leave the checkbox unchecked, the following is displayed on the summary screen text (before actually performing configuration): “This server or pool is a director for client automatic logon: False”. Consecutively, it does not write an instance of MSFT_SIPPoolExtData. If you check the checkbox, you will see SIP Domains for Automatic Logon screen in the wizard and the message displayed on summary changes to “This server or pool is a director for client automatic logon: True” and an instance of MSFT_SIPPoolExtData object is created. In the following example, I had uc.test as the server domain and uc.com as an additional SIP domain. I checked both for automatic logon and then ran a WMI script with the following output:
Backend: (local)\rtc
InstanceID: {E90477B5-FCDE-4E6E-A97E-D3A74F93A547}
Name: SIPDomainsForClientAutoLogon
Value: uc.test;uc.com
With SQL Server Management Studio Express, I also learnt that this setting is written as a record on dbo.MSFT_SIPPoolExtData table of rtcconfig database.
I’d be rather surprised if this setting didn’t have any effect on autologons. As you write later in your article, wouldn’t checking this checkmark modify the behaviour of the pool/standard edition server from simply redirecting to acting as a Director i.e. authenticating and proxying?
Elan Shudnow says
When you use multiple SIP domains, the OCS certificate wizard will automatically put the SAN name in the certificate SAN field as sip.sipdomain1.com,, sip.sipdomain2.com, etc…. And yes, if you have a Load Balancer, you just take the certificate you have on one server, export it, and import it onto the other Front End Server.
I think you are a bit confused with what I was saying. I wasn’t saying if you have multiple pools, you would place the name of the other pool in the SAN name. I was stating that if your single pool is hosting multiple SIP domains, the OCS certificate wizard will see this and automatically place the other SIP domains in the SAN field for that given pool. You then go into the DNS zone for that specific SIP domain that will be performing automatic logons and create the automatic logon SRV record and you can point it to the sip.domain.com SIP domain.
So if you have a poolname of pool.domain.com and will be doing automatic logons for pool.domain.com but will also have a SIP domain for domain2.com, the cert wizard will automatically put sip.domain2.com in the SAN field. You can then go into the domain.com zone and create an SRV record that points to pool.domain.com. You can then go into the DNS zone for domain2.com and put an SRV record that points to sip.domain2.com.
hmarlor says
You are incorrect on this point:
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.
Front End server do not need SAN fields on their certs. The SRV record points the client to the correct pool name. Even if you have a Load Balancer, you create one cert and then export/import that cert with the FGDN of the Load Balancer.