About Me

My photo
TsooRad is a blog for John Weber. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


Lync is attempting to connect to:

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.


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.


Sfb 2019 July 2019 CU

Script to update sfb 2019 install to enable the new control panel contained in the SfB July 2019 CU. Add-WindowsFeature RSAT-ADDS, Web-Serve...