Cerrar
InicioComunicaciones unificadasLync Server¿Qué debemos tener en cuenta si tenemos un Proxy en nuestra red cuando implementamos Lync Server?

¿Qué debemos tener en cuenta si tenemos un Proxy en nuestra red cuando implementamos Lync Server?

Cuando tenemos un proxy en nuestra red, debemos realizar una serie de configuraciones (sino lo hemos hecho ya) para no encontramos con problemas de acceso desde el cliente Lync a los distintos servicios que consume cuando iniciamos sesión (Servicios Web de los Front-END, Exchange (EWS)) (pulsar en la imagen para verla a tamaño real)

Lync_Proxy_Misma_Red.jpg
En muchas organizaciones, cuentan con herramientas de filtrado de contenido web vía Firewall con funcionalidades de Proxy (ISA Server, TMG, F5, SQUID,KERIO, WINGATE, etc…), lo que permite filtrar a que contenido que conectan los usuarios cuando navegan por internet. También en muchas organizaciones se cuenta con servidores publicados a Internet, como Exchange, SharePoint, Lync, Páginas Web, etc… a los cuales los usuarios se conectan de forma directa porque están en la misma red local o se conectan vía VPN. Hasta aquí todo perfecto (para algunos usuarios no tanto), pero si no se ha configurado de forma correcta las excepciones de tráfico que pasará por el Proxy podemos encontrarnos con varios problemas  a la hora de conectarnos con los servicios que están dentro de nuestra red y que han sido publicados a través del Reverse-Proxy. Por ejemplo, cuando iniciamos sesión en Lync si tenemos configurado un Proxy en nuestra red y el servidor de Lync está dentro de nuestra red, debemos especificar que tráfico de red no se enviará al Proxy sino no podremos conectarnos a dichos servicios. Lo más común es que cuando tratemos de iniciar sesión en Lync se nos soliciten las credenciales del proxy como vemos en la siguiente imagen:
Lync_Proxy_Misma_Red_1.png
Esto ocurre cuando el proxy solicita autenticación para que podamos tener acceso a internet y como no hemos configurado de forma adecuada que tráfico es local y cual no, nos solictará credenciales constantemente. Esto tiene fácil solución, debemos especificar que urls o dominios son internos y no utilizaremos la conexión via proxy para conectarnos a dichos servicios. Como os comentaba, esto es muy comun cuando tienes los servidores dentro de tu organización y deberíamos poder conectarnos a los mismos sin pasar por el Proxy/Firewal, etc… Voy a centrarme en el proxy de MICROSFOT (ISA SERVER, TMG) porque es de los más usado cuando implementamos servicios de Microsoft como es Exchange, SharePoint o Lync. La configuración del proxy en el puesto cliente se realiza configurando las opciones de Proxy en el IE, para ello vamos a Herramientas – Opciones – Conexiones – Configuración LAN y configuramos las distintas opciones en función de nuestra topología, pero lo más básico es introducir el nombre del Proxy y el puerto que se utiliza (por defecto el 8080):
Lync_Proxy_Misma_Red_8.png
Ahora bien, cómo podemos evitar pasar por el proxy para conectarnos a servicios web que están dentro de nuestra red? Pues básicamente desde el botón de Opciones Avanzadas y en el recuadro de Excepciones debemos especificar las URL o nombres de las URL para los Servicios Web que no queremos que pasen por el Proxy
Lync_Proxy_Misma_Red_9.png
Esto claramente se puede configurar vía GPO, para ello creamos una GPO y editamos la configuración de Internet del usuario desde Configuración de Usuario – Preferencias – Configuración del Panel de Control – Configuración de Internet – Nuevo – Internet Explorer 5,6,7,8,9,10
Lync_Proxy_Misma_Red_10.png
Y ahora nos vamos a la pestaña Conexiones – Configuración LAN – Opciones avanzadas (debemos tener habilitada la opción de usar servidor proxy …)  y en Excepciones podemos configurar las URL que queremos que no pasen por el proxy porque tenemos acceso directo a los servicios desde la LAN. Podemos hacerlo tal cual lo veis en el ejemplo, especificando el protocolo HTTPS y para todo el dominio *.ASIRLAB.COM.
Lync_Proxy_Misma_Red_11.png
De esta forma, todas las solicitudes para nuestro nombre de dominio vía HTTPS no pasarán por el Proxy, de esta forma podremos tener acceso a todos los servicios de forma directa. En el caso del cliente Lync, una vez que nos hemos iniciado sesión lo siguiente es conectarse a los servicios web del Front-END y Exchange (EWS). Si el proxy nos solicta autenticación y no nos autenticamos (por el motivo que sea), el cliente Lync no podrá utilizar distintos servicios (ABS, EWS) y nos encontraremos con varias alertas en el cliente:
Lync_Proxy_Misma_Red_4.png
No muestar varias alertas indicando que no puede recuerar/acceder a los servicios de Exchange para recuperar el histórico de las conversaciones/llamadas/etc.. y como vemos no tenemos conectado el buzón de voz de Exchange. Si durante el proceso de conexión analizamos el tráfico de red vía Wireshark podemos verificar lo que nuestro cliente Lync quiere hacer y el Proxy lo está denegando por no estar autenticado. Como vemos queremos conectarnos al servicio autodiscover  para conectarnos a los servicios de Exchange (EWS), pero el proxy ya nos ha denegado la conexión y de ahí el estado del cliente Lync
Lync_Proxy_Misma_Red_2.png
Lync_Proxy_Misma_Red_3.png
Para solventar esta situación, es que configuremos el Proxy para que tome como internas el dominio interno y el de los servicios que tenemos en nuestra red para que no trate de conectarnos a través de el. Sino podemos hacerlo directamente en el proxy (que seguro que sí), lo podemos hacer como os comentaba directamente en  las opciones del IE, Chrome, Mozilla o el navegador que tengáis. Si tenemos IE lo podemos hacer facilmente creando una GPO y aplicándola a todos los usuarios de nuestra red y tendremos el problema resuelto. Una vez resuelto este “problema”, ya tendremos a nuestro cliente Lync sin errores y con acceso a todos los servicios de forma correcta:
Lync_Proxy_Misma_Red_6.png
Esto es algo a tener claro como concepto básico cuando implementamos un Proxy, pero en algunas ocasiones he visto que alguien se ha olvidado de configurar correctamente las excepciones cuando los servidores a los que debemos acceder están también en la red local. Esto puede provocar (de hecho lo hace)  que el usuario tenga una mala experiencia y vosotros como Ingenieros de Lync tengáis problemas a la hora de realizar la implementación. Esto es algo que debemos tener en cuenta cuando solicitamos información al cliente sobre su infraestructura de red, esta información debe quedar reflejada en vuestro documento de viabilidad antes de iniciar cualquier proyecto. Está claro que el proceso de diagnóstico es sencillo y rápido, pero sino lo tenéis claro puede daros algún quebradero de cabeza.
Espero que os sea de utilidad!!!
Enable-CsUser : Spec
¿Qué registros DNS

sbuytrago@asirsl.com

NO HAY COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies