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 2010 Pool / Lync 2013 Client Coexistence


If you are in a coexistence environment, and you have your LyncDiscover pointing at your 2013 Front End Pool, you may experience some odd behavior.

Your Lync 2013 clients that are still homed on the 2010 pool (why you would do this, I don’t know) will start pitching an error that says they cannot trust the server…


clicking on “Connect” here lets the login continue.  But the next time, this error does not reappear.  It does not reappear because the endpointconfiguration.cache file is holding your information.  However, we don’t want this error to appear at all!

Why is this happening?

Well, it happens the first time because the LyncDiscover.domain.com is the primary discover tool for the Lync 2013 client.  For a more detailed look at this new method, see this. When you click on the “Connect” the endpointconfiguration.cache (c:\\users\username\appdata\local\microsoft\office\15.0\lync\sip_username@domain.com)  file is updated with the proper information.  You can prove this by logging out the user, deleting the endpointconfiguration.cache file, then login again.  The error will reappear.  Worse, if you have a large environment with the Lync 2013 client deployed to users on a Lync 2010 pool, you may see this a lot.  Help Desk calls galore.

How to fix this?

This is happening because the LyncDiscover service is pointing the user at the Lync 2013 pool.  And then that server is doing an AD lookup, discovering that the user is homed on a 2010 pool, and telling the client to talk to that server – at which point the pool name and the cert used by the client for the initial login no longer matches – hence the error.

To fix this, you need to keep your LyncDiscover DNS pointing at the Lync 2010 pool.  Alternatively, if you never deployed Lync 2010 Mobility (where LyncDiscover comes from in Lync 2010) and you don’t plan on using Lync 2013 Mobility, then you can simply not define LyncDiscover at all.  Personally, I do not like this second option – I would go out of my way to deploy the Lync 2010 Mobility just to get the entire suite deployed, and start using LyncDiscover; after all, Mobility is now part of Lync natively, and the 2013 client is looking for this service.


No comments:

CMS install fails SfB 2015 Jan 2019 CU

Details: We are upgrading/migrating from Lync 2010 to SfB 2015 (not 2019)( cannot do three levels at once). New host servers are 2016 Standa...