I recently performed a Lync Server 2013 migration whereby the customer would phase users over to the new front end pool over a reasonably long period of time. This particular customer had a high dependency on mobile devices, so there operation during the coexistence phase was required no matter what front end pool the user resided upon. From my own research I have generally found that mobile device support when in coexistence is reasonably poorly documented and TechNet social posts seem to confirm this also. My particular issue was related to either Lync 2010 or Lync 2013 mobile applications not functioning when a user was moved from the Lync Server 2010 pool to the Lync Server 2013 pool. In a slightly different approach to most of my other blog entries, here is a summary of the environment where the problem occurred.
Experienced Issue
When moving a user from the Lync Server 2010 front end pool to Lync Server 2013 front end pool, the user was unable to sign into the Lync 2010/2013 mobile applications internally or externally. The following setup had been implemented:
1. Lync Server 2010 and Lync Server 2013 are in a coexistence state.
2. The reverse proxy (Forefront TMG 2010) is configured to send web services traffic to the Lync Server 2010 front end.
3. The Lync Server 2013 pool has the same external web services FQDN as the Lync Server 2010 pool.
After some investigation into this issue, I found this interesting paragraph in Doug Deitterick’s blog:
“When in co-existence with Lync Server 2010, your Lync autodiscover URLs can still resolve to a Lync Server 2010 Front End Server or Director. The Lync autodiscover service will be return the correct external web services FQDN for your user based on your homed pool. The media traffic from the Lync 2013 mobile client can also use a Lync Server 2010 Edge Server.”
This explained my problem was web services orientated and my issue was occurring because my Lync Server 2o13 front end pools web services FQDN was the same as my Lync Server 2010 front end pools web services FQDN and therefore causing mobile application login failures for users who had been migrated.
Issue Resolution
To resolve the aforementioned issue, I had to ensure that mobile application requests for Lync Server 2013 users were directed to the Lync Server 2013 front end. In order to ensure this I performed the following.
1. Changed the Web Services URL for the Lync Server 2013 front end to webservices2013.domain.com in the Topology Builder and published the changes.
2. Regenerated the Consolidated Edge Server certificate, that also contained my web services URL, to include the new webservices2013.domain.com entry. Additionally a global DNS record for webservices2013.domain.com was created, pointing to the same IP address as the Lync Server 2010 web services address.
3. Imported the new SSL certificate as detailed in step 2, onto the customers Forefront TMG 2010 server and created a new reverse proxy rule that had a only a single public name of webservices2013.domain.com which in turn pointed to the Lync Server 2013 front end pool. The Lync Server 2010 proxy rule was left intact with the exception of updating its SSL certificate to the one created in step 2, as the original certificate it was using had now been revoked following the regeneration.
Following these changes, when a mobile application performs a user sign in the following occurs:
Application Sign-in Request -> lyncdiscover.domain.com traffic passed to Lync Server 2010 front end -> User identified as being homed on Lync server 2013 -> Autodisover returns a web services URL of webservices2013.domain.com -> Mobile application signs in via webservices2013.domain.com
That’s it, by implementing separate web services name spaces in a migration scenario you can retain mobile application functionality when in coexistence.