Thanks to Elan Shudnow and Bob Wille who helped get to the bottom of this.
The Issue
At a client site the other day, my Lync client pitched the following error:
Now, as you might imagine, the name here does not match what my client was expecting to find. Clicking on “connect” fails with this error:
Using the “Try Another Server” allows my client to connect normally; closing the error message with the upper right corner red ‘x’ allows my client to connect normally.
What is going on here? The Lync client does a number of automatic lookups when initiating login so it can locate an appropriate server. Here we can see my client querying the local DNS to find its’ server, and we can also see the client ASKING for the address for the lyncfrontendvip that is causing this error.
The Question
What is causing this behavior? Handled correctly, this is not stopping my client from connecting (eventually); however, this is certainly unexpected. So, here is a netmon trace of my client but this time from another location (my hotel). Note the Lync client is no longer requesting the odd vipname address.
Why is this happening?
As it turns out, my client’s environment/site location is configured for Lync Phone Edition support; this means that DHCP option 120 was created and configured to deliver information necessary for allowing proper Lync Phone operations. This screen cap shows this DHCP delivery; and here is the vipname being delivered to my Lync client.
What is happening is that the DHCP, configured for Lync Phone support, is delivering (as it should) SIPServer data to the client host machine. Clearly, Lync client is hardcoded to default to the SIPServer definition address if that DNS query is valid. Hence, inside my client’s environment, my Lync client was delivered a SIPServer definition, and used it in favor of the expected _sipexternaltls._tcp.domain.com. When it attached to the defined SIPServer, it then failed to login (duh!) because my account did not exist on that system. Cancelling the dialogue or telling the client to try another server works because Lync then tries the existing returns for _sipexternaltls._tcp.domain.com.
Conclusion
Consultants who are working in a Lync Phone enabled client environment may see this Lync behavior. However, your regular users who are roaming, visiting THEIR client sites might see this also. Their solution, if they don’t figure it out for themselves will be to cancel the error dialogue. Your job will be to explain the whole mess to them. I hope this helps.
YMMV.
