How a little space can cause so many issues.

When a user attempts to login to they use DNS and SRV records to lookup their home server.  They start by making three parallel requests for:

_sipinternaltls._tcp.domain.com

_sipinternal._tcp.domain.com

_sip._tls.domain.com

The first two are defined in your internal DNS with the last one being published externally.  The clients use these SRV records to lookup the service (published via A record) of where to automatically login.  I was working on a client recently, where no matter what I did I could not get automatic login to work externally.  To complicate matters, I did not have access to the DNS tools (as it was hosted) so I had to work with was what I saw on the client.  When I would do an NSLookup, I would see exactly what I expected to see.  The A record being returned and I could resolve the A record, however, the Lync client would continue to throw an error that it could not resolve the server name.

So I did traces on the server, just to verify, and indeed the client would not even attempt to connect to the edge server.  If I manually configured the client, it would work exactly as expected.  This is where the local log files and snooper come into play.  If you have not yet installed Snooper on your local machine, you should.  Just like the server log files, your client SIP Stack logs can be parsed by Snooper and provide you with valuable information.

So steps one was to enable client side logging.  This can be done either at the client (Gear Box | Options | General) or via the set-csclientpolicy powershell for the company.  Here you can see my settings enabled via policy.

Second item was to reproduce the issue.  Once done, you will have a log file named Communicator-uccapi-0.uccapilog.  This can be found at:

c:users<username>tracing

So the client does exactly as expected.  It fails to find the internal names and moves onto the external names, which it finds correctly.  But notice the resolution (sip.domain.com ).  Anything look strange about that reply?  A space after the .com?  It couldn’t be, but it was.  When the SRV record was created they accidentally added a space at the name.  Didn’t think it was possible but after they re-entered the name removing the space, login problems were solved.

Goes to show you how important understanding the login process is and knowing how to read the logs.

Enjoy.

Leave a Reply

Your email address will not be published. Required fields are marked *