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.

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?

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.

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.