Windows Messenger Autoconfiguration with LCS and domain names SRV queries
Interesting customer issue reported in that they could connect using TLS when providing the FQDN but when using Autoconfiguration it failed to connect. Normally when a customer tells us this we know that it is NOT a certificate issue, otherwise TLS would fail when using the FQDN. We can suspect that we have incorrect SRV records or possibly the Group Policy to AllowAdditionalDNSNames has not been enabled. This policy allows the client to accept a certificate for any name greater than the DNS query we made.
It is that last statement that is key to this particular issue. First let me give two examples of what this means. If my sip-uri is Toml@microsoft.com my DNS SRV query will be _sip._tls.microsoft.com. The Group Policy is overriding the client's normal behavior of expecting a returned host and certificate for sip.microsoft.com. Essentially despite our query the client is still expecting that all queries and responses will result in directing us to a host identifying itself as sip.microsoft.com. With the group policy in place my client will accept anyoldhost.microsoft.com or even anyoldhost.grandchilda.childa.microsoft.com. In short we will ignore any data or value that is returned in excess of what we queried for. So anything more than microsoft.com we will accept but not less.
Two examples, the first showing a success like we discussed and the second showing a failure:
Case#1 -
DNS SRV query is
_sip._tls.microsoft.com
Returned result must contain microsoft.com and in fact is: Lcspool.s1.ms.microsoft.com
The returned result is "greater/longer" than the queried domain suffix
Case#2
DNS SRV query is
_sip._tls.one.microsoft.com
Returned result must contain one.microsoft.com and we fail to get that but instead
Lcspool.child.two.microsoft.com. Note that while both share microsoft.com they differ in what we would consider the "base" domain name of one.microsoft.com essentially another domain name.
The workarounds for customers in this configuration can range and I offer what I belive are the least impacting or easiest to implement to the most impacting.
- Push the server name and protocol information to the clients. This allows you to bypassing the use of autoconfiguration as a feature but achieve the functionality in which your end users do not need to know the server name.
- Document the manual settings used in Windows Messenger to connect. This puts the burden on your end user and requires that you have an infrastructure to document this type of data. This could be the data given to new hires, an email, public folder, website, etc.
- Change the domain portion of your sip-uri to eliminate the different child domain problem. As an example instead of using toml@one.microsoft.com and toml@two.microsoft.com use only one of these or collapse it to toml@microsoft.com. What you really want to do is to make sure that you strongly consider using the same SIP-URI and Email alias. With the new Federation functionality coming in LCS 2005 SP1 (you will have to pay for the public cloud connectivity with AOL/MSN/YAHOO), having the same alias will make it easier for individuals to communicate regardless of the application.
- Change your DNS heirarchy. I really would not suggest this unless you are in the beginning phases of a new rollout as you will most likely have to alter your Active Directory structure. This is really a high time and effort approach that will likely have few customers pursue as they likely invested much time in their infrastructure planning already.
Well I hope this was helpful, sorry I don't have logs for this but I believe they won't provide as much information as it is the traced logging with source code that gives details, and we can't post that info.
TomL LCS Kid
I realize this might be confusing so I hope that I have done a good job of explaining the expected behavior and also what may fail.