Comments on: Automatic Logons, Directors, and Client Redirections

By: Joker

Joker — Fri, 11 Dec 2009 12:39:44 +0000

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!

By: Elan Shudnow

Elan Shudnow — Mon, 08 Dec 2008 20:04:06 +0000

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.

By: Mika Seitsonen

Mika Seitsonen — Mon, 08 Dec 2008 18:04:25 +0000

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?

By: Elan Shudnow

Elan Shudnow — Fri, 17 Oct 2008 01:34:16 +0000

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.

By: hmarlor

hmarlor — Thu, 16 Oct 2008 19:14:00 +0000

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.