Microsoft Lync Server
Header

Una de las cosas que debemos tener en cuentra cuanto desplegamos cualquier servicio al cual nos conectaremos vía internet, es claramente el ancho de banda que debemos contratar o disponer para no tener una mala experiencia del servicio. Cuando implementamos VoIP, una de las cosas más importante es tener en cuenta es la conectividad hacia nuestro ITSP y si disponemos de las redes remotas, pues el ancho de banda entre ellas. Existen muchos escenarios de implementación de un sistema de voz, pero en la mayoría de las ocasiones por la simplicidad de gestión se utiliza un sistema centralizado para que todos  los usuarios se conecten a la sede central para utilizar el sistema de voz. El problema llega cuando tenemos sedes en distintos paises/contienentes, puesto que debemos atravesar más nodos de los esperado para conectarnos de un extremo a otro.  Es posible también, que vuestro cliente o empresa esté localizado en países en donde no tengamos muy claro que tipo de conectividad tendremos entre la sede central y la sede remota, pero podemos tratar de tener una pequeña estimación del retardo entre ellas utilizando algunas herramientas disponibles en el mercado. Muchas de estas herramientas son simplementes páginas webs desde las cuales podemos realizar ciertos test de velocidad, pero la mayoría son simplemente test entre la conexión desde la cual lanzas el test y un sitio único, pero con http://www.speedtest.net podemos lanzar distintos test de velocidad entre la conexión desde la cual inicias el test y del punto de destino sobre el cual queremos "calcular" el tiempo de respuesta entre ambos extremos:

Test_de_Velocidad_Entre_Distancias_Considerables_4-1.png
 
Además, esta herramienta web nos permite tener un registro de los test realizados, por lo que nos será muy útil para tomar ciertas decisiones en nuestros proyectos. Por ejemplo el escenario que vamos a implementar, si un entorno centralizado o distribuido por falta de ancho de banda entre la sedes. Esto dependerá de varios factores también:
  • Número de sedes
  • Número de usuarios por sede
  • Llamadas de Voz entre sedes
  • Videoconferencias entre sedes
  • Llamadas de Voz externas
  • Llamadas de Voz externas a países fuera del ámbito local de cada sede
  • etc..

Con todo estos datos  (y algunos más que faltarían), poderíamos tener algunas decisiones críticas para el proyecto como elegir distintos ITSP locales de cada país para garantizar una buena conectividad entre la sede remota y el ITSP para que el TRUNK SIP tenga una conectividad aceptable y no se nos "caigan" las llamadas, etc.. No quiero profundizar en este tema porque tendríamos para muchos artículos, simplemente que es más que recomendable siempre tratar de revisar el ancho de banda disponible entre sedes, sobre todo cuando están en distintos paises o continentes por la cantidad de nodos que atraviesan aumentando así el retardo en las comunicaciones entre ambas sedes. Como os comentaba, con la herramienta de http://www.speedtest.net, sin llegar a ser 100% fiable, sí que nos dará una idea clara de lo que nos podemos encontrar. Para realizar el test únicamente debéis acceder a la página web de OOKLA (http://www.speedtest.net ) y realizar el test seleccionando el nodo de destino en el país que queráis y que esté disponible en el mapa y pulsáis en COMENZAR PRUEBA

 

Test_de_Velocidad_Entre_Distancias_Considerables_5.png
 
La primera pruebas es un PING para verificar el tiempo de respuesta entre ambos extremos, y posteriormente se proceso el test de bajada y subida respectivamente:

 

Test PING

Test_de_Velocidad_Entre_Distancias_Considerables_6.png

Test Descarga

Test_de_Velocidad_Entre_Distancias_Considerables_1.png

Test Carga

Test_de_Velocidad_Entre_Distancias_Considerables_2.png

Una vez que se ha completado el test, nos muestra lo resultados, que además podemos compartir en Facebook o Twitter con nuestros seguidores o amigos

Test_de_Velocidad_Entre_Distancias_Considerables_3.png
Si queremos tener un histórico de nuestros test, debemos registrarnos (gratuito y en menos de 1 minuto lo tienes hecho), podemos tener los resultados de nuestros tests:

Test_de_Velocidad_Entre_Distancias_Considerables_7.png

Una vez registrados también podemos realizar ciertas parametrizaciones interesantes, por lo menos para desde mi punto de vista:

Test_de_Velocidad_Entre_Distancias_Considerables_8.png
Me repito, sin ser 100% fiable (porque hay muchísimas consideraciones más a tener en cuenta), creo que puede ser de ayuda ante cualquier proyecto en donde la conectividad entre sedes es algo clave. En cualquier proyecto de Voz es algo vital, así que ya sabéis, a realizar vuestros test antes de iniciar cualquier proyecto para poder tomar buenas decisiones antes de iniciarlo. Aquí os dejo también un tabla muy  interesante sobre los códecs de audio más utilizados (Lync utiliza el G.711):

Test_de_Velocidad_Entre_Distancias_Considerables_9.png

Espero que os sea de utilidad!!!

Microsoft ha liberado nuevas actualizaciones para el Cliente y Servidor de Lync 2010, aquí tenéis​ los enlaces de descarga oficiales

Update
Update
This download includes all available updates for Lync 2010.
FREE
Release Date:
4/17/2014
Update
Update
This download includes all available updates for Lync Server 2010.
FREE
Release Date:
4/17/2014
Update
Update
This download includes all available updates for Lync 2010.
FREE
Release Date:
4/17/2014

 

El proceso de actualización del cliente es trivial como siempre, y la del servidor es siempre el mismo proceso (http://support.microsoft.com/kb/2493736). En cuanto a la versión de servidor aquí tenéis a que afecta esa actualización:

Lync_Update_CU12.png

Actualización de Standard/Enterprise edition Server 2909888 (http://support.microsoft.com/kb/2909888/)

Descripción de la actualización acumulativa de Lync Server 2010: enero de 2014
  • Actualización de Conferencing Server
    2889609

    Descripción de la actualización acumulativa de Lync Server 2010, Conferencing Server: octubre de 2013

  • Actualización para la API administrada de comunicaciones unificadas 3.0 en tiempo de ejecución
    2884620

    Descripción de la actualización acumulativa de Lync Server 2010, Unified Communications Managed API 3.0 en tiempo de ejecución: octubre de 2013

  • Actualización de componentes de servidor
    2953588

    Descripción de la actualización acumulativa de Lync Server 2010, servidor de componentes Web: abril de 2014

  • Actualización de componentes básicos
    2953590

    Descripción de la actualización acumulativa de Lync Server 2010, componentes principales: abril de 2014

  • Actualización para el servicio de archivado
    2859580

    Descripción de la actualización acumulativa de Lync Server 2010, servicio de archivado: julio de 2013

  • Actualización para el servicio de movilidad
    2847899

    Descripción de la actualización acumulativa de Lync Server 2010, servicio de movilidad: julio de 2013

  • Actualización para la API administrada de comunicaciones unificadas 3.0, la ejecución de las actividades de flujo de trabajo de Windows 64-bit
    2847897

    Descripción de la actualización acumulativa de Lync Server 2010, la ejecución de las actividades de flujo de trabajo de UCMA 3.0 Windows: julio de 2013

  • Actualización para el servidor de conferencia Web
    2708616

    Descripción de la actualización acumulativa de Lync Server 2010, servidor de conferencia Web: junio de 2012

  • Actualización para el operador de la conferencia
    2954004

    Descripción de la actualización acumulativa de Lync Server 2010, operador de conferencias: abril de 2014

  • Actualización de herramientas administrativas
    2670358

    Descripción de la actualización acumulativa de Lync Server 2010, herramientas administrativas: febrero de 2012

  • Actualización para el servicio de directivas de ancho de banda
    2650037

    Descripción de la actualización para el servicio de directivas de ancho de banda de Lync Server 2010: diciembre de 2011

  • Actualización para el servidor de mediación
    2640253

    Descripción de la actualización acumulativa de Lync Server 2010, servidor de mediación: noviembre de 2011

 

 

Una vez que hayáis instalado las actualizaciones, debéis ejecutar el siguiente cmdlet en vuestros Front-END

Install-CsDatabase -Update -ConfiguredDatabases -SqlServerFqdn <EEBE.Fqdn> -UseDefaultSqlPaths

Lync_Update_CU12_1.png

Por último ejecutamos el siguiente cmdlet y comprobamos que no tenemos problemas con la topología: Enable-CsTopology

Aquí os dejo una tabla resumen de las actualizaciones hasta la fecha (incluida la de ahora)

Version Actualización Acumulativa KB
4.0.7577.108 Enero 2011 (CU1) http://support.microsoft.com/kb/2467775
4.0.7577.137 Abril 2011 (CU2) http://support.microsoft.com/kb/2500442
4.0.7577.166 Julio 2011 (CU3) http://support.microsoft.com/kb/2571546
4.0.7577.183 Noviembre 2011 (CU4) http://support.microsoft.com/kb/2514980
4.0.7577.190 Febrero 2012 (CU5) http://support.microsoft.com/kb/2670352
4.0.7577.199 Junio 2012 (CU6) http://support.microsoft.com/kb/2701585
4.0.7577.203 Octubre 2012 (CU7) http://support.microsoft.com/kb/2737915
4.0.7577.216 Marzo 2013 (CU8) http://support.microsoft.com/kb/2791381
4.0.7577.217 Julio 2013 (CU9) http://support.microsoft.com/kb/2860700
4.0.7577.223 Octubre 2013 (CU10) http://support.microsoft.com/kb/2889610
4.0.7577.225 Enero 2014 (CU11) http://support.microsoft.com/kb/2909888
​4.0.7577.230 ​Abril 2014 http://support.microsoft.com/kb/2493736


Espero que os sea de utilidad!!!

MSFT ha actualizado el listado de direcciones IP y URL que debemos permitir en nuestros dispositivos de seguridad (Router, Firewall, Proxy, etc..)​ para que los usuarios de nuestra organización puedan utilizar Lync On-Line (pulsar en la imagen para verla a tamaño real)

IPs y URLs de Lync Online_2014-04-16.jpg
Debemos crear una regla con una combinación básica de destino y puerto/protocolo en nuestros firewall, en función del modelo que cada uno tenga tendrá que configuirarlo de una forma u otra. Pero lo que está claro es que la regla tiene que ser siempre la misma en cuanto a destinos y puertos/protocolos que os expongo a continuación:
 
IPs y URLs de Lync Online_2014-04-16-2.jpg
Aquí os dejo los valores por separado para que podáis utilizarlos copiando y pegando:
 
Direcciones IP
65.54.54.128/25
65.55.121.128/27
65.55.127.0/24
111.221.17.128/27
111.221.22.64/26
111.221.23.0/25
111.221.76.96/27
111.221.76.128/25
111.221.77.0/26
132.245.0.0/16
157.55.40.128/25
157.55.46.0/27
157.55.46.64/26
157.55.104.96/27
157.55.229.128/27
157.55.232.128/26
157.55.238.0/25
207.46.5.0/24
207.46.7.128/27
207.46.57.0/25

Lync Online URLs
*.microsoftonline.com
*.microsoftonline-p.com
*.onmicrosoft.com
*officecdn.microsoft.com
*.sharepoint.com
*.outlook.com
*.lync.com
ev-secure.verisign.com
evsecure-ocsp.verisign.com
evsecure-aia.verisign.com
evsecure-crl.verisign.com
sa.symcb.com

Protocolos/Puertos

PSOM/TLS 443 (sesiones para compartir datos de salida)
STUN/TCP 443 (sesiones para compartir audio, vídeo y aplicaciones salientes)
STUN/UDP 3478 (sesiones de audio y vídeo salientes)
TCP 5223 (Notificaciones push del cliente móvil de Lync)
RTP/UDP 50000-50019 (sesiones de audio de salida)
RTP/UDP 50020-50039 (sesiones de vídeo de salida)
TCP 50040-50059 (Uso compartido de aplicaciones y transferencia de archivos con Lync)
 
En muchas organizaciones las restricciones de Firewall son muy estrictas, de tal forma que debéis tener claro cuales son los destinos y protocolos/puertos que utilizarán los usuarios de Lync On-Line para que la gente de redes os pueda facilitar el acceso.  Imagino que no hará falta comentaros que la regla es de salida, lo que debemos hacer es permitir esos destinos/potrocolos/puertos.
 
Espero que os sea de utilidad!!!

Cuando los clientes de Lync (Móvil, Escritorio o App de Windows 8) se conectan a los servidores de Lync (Edge, Director, Front-END) para iniciar sesión debemos crear previamente una serie de registros DNS, sobre todo si queremos una configuración automática del cliente. Esto nos permitirá que en función de la dirección SIP que introduce el usuario, el cliente Lync encuentre los servidores de Lync (pulsar en la imagen para verla a tamaño real)

Resolución de Nombres Cliente Lync 2010-2013.jpg
En función de cliente de Lync que tengamos instalado, debemos tener creados diferentes registros DNS de tipo A o SRV. Si tenemos el cliente Lync 201 0 instalado, para que pueda encontrar los servidores de Lync tanto internos como externos, se deben crear los siguientes registros DNS:
 
Cliente Lync 2010 Internos:
_sipinternaltls._tcp.asirlab.com. 86400 IN SRV 0 0 5061 pool.asirlab.com (Registro SRV y el host  es el FQDN del Pool de Front-END o servidor Front-END)
lyncdiscoverinternal.asirlab.com  (Tipo A o CNAME con la IP o FQDN del Front-END , Pool o Director)
Cliente Lync 2010 Externos:
_sip._tls.asirlab.com. 86400 IN SRV 0 0 443 sip.asirlab.com (Conexiones TLS vía EDGE IP de Acceso)
lyncdiscover.asirlab.com  (Tipo A o CNAME la IP del Reverse-Proxy que publica los servicios Web de los Front-END, Pool o Director)
Si utizamos Wireshark para ver el tráfico de red desde un equipo con Lync 2010, esto es lo que podemos ver (pulsar en la imagen para verla a tamaño real): es un ejemplo simulado, de ahí que no encuentre registro DNS alguno
Resolución de Nombres Cliente Lync 2010-2013_2.jpg
Cliente Lync 2013 Internos/Externos (a excepción del cliente de la Tienda de Windows 8): El cliente Lync utilizará en este orden la búsqueda de los servidores para iniciar sesión, consultará el DNS hasta que pueda resolver algún nombre o hasta que se finalice el recorrido por cada uno de ellos sin éxito:
1.lyncdiscoverinternal.asirlab.com   Un registro A o CNAME (FQDN del Pool de Front-END o FQDN del Front-END) para el servicio Detección automática en los servicios web internos
2.lyncdiscover.asirlab.com   Registro A o CNAME (IP Pública del Reverse-Proxy) para el servicio Detección automática en los servicios web externos
3._sipinternaltls._tcp.asirlab.com   Registro SRV (FQDN del Pool de Front-END o FQDN del Front-END) para conexiones TLS internas
4._sipinternal._tcp.asirlab.com   Registro SRV (FQDN del Pool de Front-END o FQDN del Front-END) para conexiones TCP internas (solo si se permite TCP)
5._sip._tls.asirlab.com   Registro SRV (FQDN con la IP Externa del Servicio de Acceso del EDGE) para conexiones TLS externas
6.sipinternal.asirlab.com   Registro A (FQDN del Pool de Front-END o FQDN del Front-END)
7.sip.asirlab.com   Registro A (IP Externa del EDGE para los servicios de Acceso o Front-END o Director Interno)
8.sipexternal.asirlab.com   Registro A (host) para el Servidor perimetral de acceso cuando el cliente es extern
El cliente Lync de la Tienda de Windows 8  utilizará únicamente los siguientes registros (vía Reverse-Proxy):
1.lyncdiscoverinternal.asirlab.com   Un registro A o CNAME (FQDN del Pool de Front-END o FQDN del Front-END) para el servicio Detección automática en los servicios web internos
2.lyncdiscover.asirlab.com   Registro A (IP Pública del Reverse-Proxy) para el servicio Detección automática en los servicios web externos
Si utizamos Wireshark para ver el tráfico de red desde un equipo con Lync 2013, esto es lo que podemos ver (pulsar en la imagen para verla a tamaño real): es un ejemplo simulado, de ahí que no encuentre registro DNS alguno
Resolución de Nombres Cliente Lync 2010-2013_1.jpg
La configuración automática funcionará siempre y cuando el URI del SIP del usuario coincida con el nombre de dominio del grupo de servidores, en caso contrario no funcionará. Por ejemplo, si los usuarios tienen como URI el dominio asirdemo.com y el dominio de los servidores es asirlab.com, no se conectarán de forma automática, ejemplo:
_sipinternaltls._tcp.asirdemo.com. 86400 IN SRV 0 0 5061 pool.asirlab.com
Por lo que si queremos que los clientes se conecten de forma automática, tenemos las siguientes opciones de configuración:
  • GPO: Podemos configurar los clientes de Lync indicando el nombre de los servidores a conectarse, claramente no es un descubrimiento automático por lo que en este escenario no necesitamos los registros SRV
  • Zona DNS: Podemos crear una zona DNS con el nombre del dominio no predeterminado en el Active Directory y crear los registros SRV necesarios pero con el nombre asirdemo.com (según nuestro ejemplo)
Si creamos una zona DNS con el nombre de dominio asirdemo.com, deberíamos crear los siguientes registros DNS:
 _sipinternaltls._tcp.asirdemo.com. 86400 IN SRV 0 0 5061 pool.asirdemo.com Registro SRV con el host de destino con el nombre del servidor con el dominio asirdemo.com
pool.asirdemo.com Registro A con la IP del servidor
Debéis tener en cuenta que necesitaréis un certificado asignado a servidor de Front-END o Pool con el nombre asirdemo.com a mayores del dominio predeterminado.
 
Si os fijáis el cliente de Lync 2010 no necesita más que dos registro de tipo SRV (Interno y Externo) para encontrar los servidores de Lync, además de otros de tipo A o CNAME para los dispositivos móviles (lyncdiscover.asirlab.com y lyncdiscoverinternal.asirlab.com). Pero en la versión de Lync 2013, utiliza los registros DNS de Detección automática  como método preferido para descubrir todos los servicios una vez que se ha iniciado sesión.
 
Como podemos ver si queremos que los clientes de Lync se configuren de forma automática, debemos crear distintos registros DNS de Tipo SRV y A.  En este artículo solo me he centrado en los registros DNS para el descubrimiento automático de los servidores para iniciar sesión, pero debemos crear el resto de registros para que se puedan encontrar los distintos servidores y servicios de la topología (FQDN de los Pool, WAC, EWS de Exchange, etc…)
 
Como resumen comentaros, que con estos dos registros DNS de tipo SRV para el cliente de escritorio de Lync 2010 y 2013 esto registros serían suficientes para encontrar los servidores de Lync de forma automática:
 
Interno: _sipinternaltls._tcp.asirlab.com. 86400 IN SRV 0 0 5061 pool.asirlab.com (Además debemos tener los registros de tipo A correspondienes para el Pool y Front-END que tengamos)
Externo: _sip._tls.asirlab.com. 86400 IN SRV 0 0 443 sip.asirlab.com (Conexiones TLS vía IP de Acceso del EDGE)
 
Si no queremos/podemos (nada recomendable) crear registros SRV entonces debemos crear los registros de tipo A, pero siempre que sea posible debéis configurar los registros SRV. Por último os dejo un comentario de Microsoft sobre la configuración de los dispositivos móviles:
 
La configuración predeterminada dirige todo el tráfico de clientes móviles a través del sitio externo. Puede cambiar la configuración para devolver solamente la dirección URL interna, si esto se adapta más a sus necesidades. Con esta configuración, los usuarios pueden usar aplicaciones móviles de Lync en sus dispositivos móviles solo cuando están dentro de la red corporativa. Para definir esta configuración, hay que usar el cmdlet Set-CsMcxConfiguration.
 
De ahí que veáis en el esquema la conexión a los servicios Web vía Reverse-Proxy, y si analizáis el tráfico de red veréis que sorpresa cuando se "cree" que la conexión va en interno ….
 
Espero que os sea de utilidad!!!

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 solicitará 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 solicita 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!!!