Linkedin - Profile

viernes, 26 de abril de 2013

Lync 2013 Mobile “error” en cliente Android

Hola a todos explicare mi experiencia con respecto a un issue que ha sido reportado y publicado posteriormente por Microsoft, espero que les sea de ayuda en sus futuras implementaciones de Lync 2013.

Escenario: Tenemos una infraestructura local de Lync Server 2013 sin acceso al exterior y sin conectividad a internet para los servicios de movilidad, meet, dialin (proxy inverso) y/o edge server.  Los servicios de movilidad para Lync 2013 han sido activados y se dispone de una Wifi corporativa para que los teléfonos Smartphone de Android con el cliente Lync 2013 puedan acceder desde el móvil para interactuar con la plataforma.

Anexo Visio:

Lync Server 2010 V1.1

Problema (issue): Al intentar iniciar sesión desde el cliente Lync 2013 Mobile conectado a la Wifi corporativa el cliente da un error y no se puede iniciar sesión. (Anexo Imagen)

Screenshot_2013-04-25-16-28-37

Sin embargo al instalar el cliente Lync 2010 Mobile la sesión se inicia sin ningún problema.

Diagnostico: Viendo el problema y teniendo en cuenta que efectivamente no se trataba de un error común procedí a realizar un snooper de la infraestructura específicamente en el servidor de FrontEnd, se logro comprobar que haciendo login con el cliente Lync Mobile 2013 no llegaban sesiones de intento de login al FrontEnd sin embargo con el cliente Lync Mobile 2010 si habían sesiones de login (inicio de sesión) .

Anexo imágenes de OcsLogger Tools. puedes descargarlo aquí:

http://www.microsoft.com/en-us/download/details.aspx?id=35453

image

 

image

Solución: Procedí entonces a escribir un correo electrónico a la comunidad MVP de Lync y en pocas horas tuve una respuesta del MVP Elan Shudnow quien me dio las siguientes soluciones (en inglés):

I’ve run into this exact problem with the Lync 2013 Mobile clients not working on corporate wifi but Lync 2010 Mobile clients did work. In fact, I helped someone fix this exact problem yesterday.

Short Answer:

Make sure the external web services FQDN located in Internal DNS points to a device that is doing port redirection to 4443.

Longer Answer:

In External DNS, the externalwebfqdn.domain.com would point to the Public IP of the Reverse Proxy.

In Internal DNS, the proper method would be to point externalwebfqdn.domain.com to the Public IP of the Reverse Proxy and hairpin the traffic.  This would ensure that regardless if the mobile client is on corporate WIFI or Internet, they always end up connecting to the same Public IP and therefore, when the mobile client switches between cellular and wifi, there's a seamless transition.  Some companies would deviate from this practice.  These companies would take this FQDN and point it to the Front End or internal HLB that doesn’t do port redirection so MCX (Lync 2010 Mobility) would end up hitting the Internal Web Site on the Front End.  I’ve seen this work with Lync 2010 clients just fine but there obviously would be no seamless transition for users when switching between cellular network and wifi due to the IPs of the external web services being changed. 

So even though the Lync 2010 mobile client seems to work in the model where the external web services FQDN in the Internal DNS points to an internal facing device that has no port redirection (again, no seamless transition for clients), it appears the Lync 2013 mobile clients (UCWA) are not so forgiving and the external web services FQDN located in Internal DNS needs to point to something that bridges the ports to 4443 properly so it hits the Front End’s External Website on 4443 just like it would happen for Internet Users.

Recap/Summary:

I would ensure that the external web services FQDN located in Internet DNS is properly pointing to a device that is doing port redirection so that mobile traffic from the mobile clients on the corporate WIFI ends up hitting the Front End on the External Web Site on 4443.  And preferably, for a seamless transition, point both records (in Internet DNS and Internal DNS) to the same Public IP and hairpin for reasons I mention earlier.

Elan

http://www.shudnow.net/2012/03/12/using-lync-2010-mobility-on-your-corporate-wifi-networks/

En pocas palabras se trata de la manera con que el cliente Lync Mobile 2013 se valida y simplemente el busca primero la URL Externa y luego va a la URL Interna, en mi caso yo tenia diferente la URL Externa y la URL Interna porque estaba previendo en una segunda fase implementar el Edge y el Proxy Inverso con TMG. En nuestro caso la solución pasa por cambiar el nombre del dominio externo por el interno en el Topology Builder de Lync 2013, luego republicar la topología y lanzar desde el Lync Managment Shell el comando Powershell Enable-CsComputer –Verbose para que tome los cambios. Anexo imágenes:

ANTES:

image

DESPUES:

image

COMANDO POWERSHELL DE LYNC:

image

YA CON ESTO EL PROBLEMA FUE RESUELTO Y LOS CLIENTES LYNC 2013 MOBILE DE ANDROID HICIERON LOGIN (INICIO DE SESION) EN LA NUEVA INFRAESTRUCUTRA DE LYNC 2013.

Luego de esto nos contacto Susan Bradley y Premal Ghandi de Microsoft para publicar este Issue y actualizar la información en el TechNet Libray de Microsoft el cual pueden detallar en el siguiente enlace:

http://technet.microsoft.com/en-us/library/hh690030%28v=ocs.15%29.aspx

image

Agradeciendo la ayuda y colaboración del MVP Elan Shudnow. http://www.shudnow.net

Peter Diaz

MVP-MCT-MAP 2012/2013

No hay comentarios: