A quick modification to this post is that the analysis is accurate and this is current behavior. Bug/By Design are just semantics but we don't build the DNS query for a single label suffix for the SIP-URI. At this time, the solution is to not use Automatic Configuration or alter the SIP-URI to have a non single label domain suffix. Banknorte experienced this in the lab so there is no customer request to have this fixed at this time.
Banknorte reported problems with Windows Messenger when configured for Automatic Configuration connecting to LCS 2003.
Active Directory domain names are single label meaning there are no DNS suffixes - microsoft versus microsoft.com as an example. Continuing with this their SIP-URIs follow this same model. Single label DNS names are not a good thing to hear when you pick up the phone. It is one of those situations in which we can do a lot to get things working, but it is a highly unrecommended configuration to use. Just query the knowledge base to get a few articles (http://support.microsoft.com/search/default.aspx?qu=single+label+dns+active+directory)
The actual client error being received was: An HTTPS or TCP connection could not be made. Please wait for your network administrator to correct this problem, and try again later.
Current Theory from testing:
Thinking I could solve this quickly with a Live Meeting, I was able to make some changes regarding DNS Zones and SRV records but could not resolve the problem. At this point I obtained the RTCDLL log and network capture from the customer to review offline and then to consider my local repro. The one thing I found is that the network capture showed only 1 DNS query for SIP.<domain>, no queries for _sip._tcp.<domain> or _sip.tls.<domain>. The second thing I noticed is that the response for SIP.<domain> was accurate for the server IP with port 5060 but the client attempted a connection to 5061 which was not enabled.
The RTCDLL log is most often used to view the SIP communications from the client to the server, however with this problem, we never connect to the server so no SIP data will be in the log. This means parsing through and trying to discern what this other "gibberish" is. I will come back to this after talking about my repro as it took a comparison of the two logs to really discern anything.
I wanted to avoid building a domain using single label DNS so on a whim I started by simply creating a user with a single label alias - test1@nolabel Keep in mind to support Automatic Configuration the DNS query is built from the domain suffix of that alias so I had to add a DNS zone for Nolabel and create the _sip._tcp.nolabel SRV record and the SIP.nolabel HOST record.
I was able to reproduce the problem reported by the customer. If I populated an IP or FQDN in Messenger I would be prompted for credentials and then connect, switch to automatic configuration and it failed. So I took network captures and RTCDLL logs for a successful automatic sign-in with my administrator account and network captures and RTCDLL logs for the failure. As a note - Exit the Messenger client, enable logging and then sign-in. When that was complete, sign-out, change the properties for the user and EXIT Windows Messenger. Then I was able to rename the RTCDLL log for the account and success/fail. Starting the client again I get the other client behavior and then exit and rename RTCDLL. A bit of extra clicking and stopping starting but I end up with a very concise log with only the behavior I want.
So the RTCDLL log section I am currently focusing on and trying to get more information? The snippets below:
In the failing log:
CDNSSrvLookupRequest::update - errcode=80ee0066, result=nolabel, index=0
CDNSSrvLookupRequest::update - errcode=80ee0066, result=nolabel, index=1
CDNSSrvLookupRequest::update - errcode=80ee0066, result=nolabel, index=2
The same section in the successful log:
CDNSSrvLookupRequest::update - errcode=80ee0066, result=lcsroot.local, index=0
CDNSSrvLookupRequest::update - errcode=0, result=tomllcs1.lcsroot.local:5060, index=1
The reason I waited to share the log with you is that the first time I reviewed the failing log, that section didn't jump out to me as a problem because nolabel really didn't stand out (despite the fact I chose the name). What happened is when I saw the same section in my success and then saw my FQDN which forced me to look at the request - CDNSSrvLookup - DING DING - exactly what we are failing with.
So with today's problem and this information you could have done all this yourself, the challenge is to now focus on the code and determine if this is a bug, special case, by design, what? Well it may be a while as we have the holidays so for now - NO SINGLE LABEL NAMES :)
I trust you had a Merry Christmas, and wish you a Happy New Year,
TomL LCS Kid
I was chasing up an issue with moving users from one server to another in LCS for a migration to LCS...
PingBack from http://randy.eurovideosite.com/problemswithwindowsmessenger.html