About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. 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. The opinions expressed on this blog are mine and mine alone.

2012/12/31

Lync 2010 Pool / Lync 2013 Client Coexistence

Scenario

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…

image

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.

YMMV

No comments:

test 02 Feb

this is a test it’s only a test this should be a picture