Microsoft Lync Server
Header

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 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!!!

 

En muchas ocasiones debemos habilitar a los usuarios en Lync desde PoweShell (Enable-CsUser -Identity "username" -RegistrarPool "fqdn_pool_fe" -SipAdressType "tipo" -SipDomain "dominio_sip"), y es posible que bajo alguna circunstancia nos encontremos con el siguiente problema …
Enable-CsUser_El_dominio_SIP_especificado_SipDomain_válido_1.png

 

Este problema viene dado porque queremos construir la dirección SIP del Usuario mediante su dirección de e-mail (-SipAddressType EmailAddress) y es diferente al dominio SIP con el que lo queremos registrar. Para solucionar este problema, debemos contruir la dirección SIP del usuario mediante su nombre de cuenta (-SipAddressType SAMAccountName).

 

Enable-CsUser_El_dominio_SIP_especificado_SipDomain_válido_2.png
 
Esta situación se puede dar con mucha facilidad (lo suyo sería que el dominio SIP fuese el mismo que el del dominio de correo), y como se supone que no podemos cambiar el dominio SIP de nuestro Lync tenemos que habilitar la cuenta del usuario en base a su nombre de usuario. Esto mismo podríamos hacerlo vía GUI y tendríamos que elegir la opción de creación del URI de SIP  con alguna de las opciones marcadas en verde. Si elegimos la opción de SAMAccountName nunca tendremos problema con el nombre de dominio SIP, porque se creará siempre en función de lo que pongamos en la opción -SipDomain y no entrará en conflictos con el nombre de la cuenta SAM, puesto que solo hace referencia al prefijo de la cuenta de usuario

 

Enable-CsUser_El_dominio_SIP_especificado_SipDomain_válido_3.PNG

Si el dominio SIP fuese el mismo que el dominio de la cuenta de correo claramente no tendríamos este problema. En este caso resolver el problema es sencillo, pero si queremos que la dirección de correo contenga el mismo dominio que la dirección SIP de Lync debemos añadir dominios SIP adicionales. Yo personalmente creo que es lo más conveniente, para que el usuario pueda ser identificado vía su dirección SIP/E-MAIL con el mismo formato.

Espero que os sea de utilidad!!!

 

Nueva actualización del cliente Lync 2013 disponible para su descarga
Update_KB_KBKB2880474_1.png
Update
Update
Microsoft has released an update for Microsoft Lync 2013 64-Bit Edition. This update provides the latest fixes to Microsoft Lync 2013 64-Bit Edition. Additionally, this update contains stability and performance improvements.
FREE
Release Date:
4/8/2014
Update
Update
Microsoft has released an update for Microsoft Lync 2013 32-Bit Edition. This update provides the latest fixes to Microsoft Lync 2013 32-Bit Edition. Additionally, this update contains stability and performance improvements.
FREE
Release Date:
4/8/2014
Update
Update
This download contains an update for Lync for Mac 2011
FREE
Release Date:
4/9/2014
 
Notas: Microsoft lanzó una actualización para Microsoft Lync 2013 Edición de 64 bits. Esta actualización proporciona las revisiones más recientes para Microsoft Lync 2013 Edición de 64 bits. Además, contiene mejoras de estabilidad y rendimiento. 
 

This cumulative update resolves the following issues:

  • 2941631

    Cannot drag a distribution group to change position in your contact list in Lync 2013

  • 2941639

    Call forwarding to the Response Group fails in Lync 2013

  • 2941640

    Desktop sharing session stops in Lync 2013 when all screen data is updated

  • 2941643

    Caller cannot close the window of a transferred call in Lync 2013

  • 2941654

    Update sorts and searches contacts by Furigana in Lync 2013

  • 2941658

    CTRL+TAB does not work when you switch between conversation windows in Lync 2013

  • 2941682

    Instant message appears using incorrect text format when the DisableRTFIM setting is enabled in Lync 2013

  • 2941659

    Callee's name and detailed information is missing from the conversation history of a Lync 2013 outgoing call

  • 2941636

    Search fails in Lync 2013 when non-Latin characters are used in a different case from the AD DS attributes

  • 2941635

    Can’t sign in to Lync 2013 when Office 365 account UPN differs from domain account UPN

  • 2954951

    Slow screen update in application sharing or desktop sharing session in Lync 2013

  • 2955577

    Lync 2013 takes a long time to sign in after reconnect to the network

  • 2955579

    Lync 2013 displays un-encoded texts in a toast notification or an instant message sent to another messaging client

  • 2955580

    Update adds a button to show details about limited functionalities when Lync 2013 connects to a backup pool

 

He visto con el tiempo que la mayoría de los problemas que existen con los servicios del EDGE​, es la "conectividad interna". Con esto me refiero a que los usuarios internos no pueden establecer sesiones de A/V con usuarios externos. En este artículo no hablaré de la configuración exacta de un EDGE en sus interfaces Internas, simplemente os volveré a poner los mismos artículos ya había puesto en su momento, pero …. (pulsar en la imagen para verla a tamaño real)

Conectividad_Edge_Local_VPN.jpg
 
Aquí os dejo los artículos que había escrito en su momento de cómo configurar nuestro EDGE:

El esquema que os muestro no tiene relación con los artículos, simplemente os lo he puesto que veáis que si solo tenemos un EDGE (o varios) pero el resto de sedes (Locales o VPN) se conectan al exterior claramente mediante este servidor, todos los usuarios internos deben poder conectarse al EDGE vía su interface interna. Esto no quiere decir que tenga que estar en la misma subred, porque los escenarios de red son muy distintos en función de nuestra topología de red. Pero si quieres que los usuarios internos tengan comunicación con los usuarios externos (Conferencias, Federados, etc..) debemos ser capaces de comunicarnos con el EDGE en la interface declarada como interna. Y el FQDN configurado en la topología, debe claramente se resuelto por los clientes con la IP interna del EDGE, porque sin esto tampoco nos podríamos conectar.

Una vez que todo esto lo tenemos bien configurado, debemos ser conscientes de los certificados que necesitamos, aquí os dejo varios articulos que considero que debéis leer para tratar de entender los requisitos a nivel de certificados:

Como os comento, espero que este articulo recordatorio os brinde algo de luz a algunos técnicos que tienen problemas con sus EDGE. Os repito que el esquema que os expongo en este artículo simplemente os muestra que si tenéis conectividad entre todos los hosts (implicados) y el EDGE no tendréis problemas para comunicaros con vuestros usuarios externos – federados, etc…  Por lo que debéis ser capaces de ofrecer conectividad entre los equipos de la red y el EDGE. Como en el EDGE no tenemos una puerta de enlace configurada (y así debe ser), debéis crear las rutas estáticas necesarias para llegar a las distintas redes. Pensar que podemos tener el EDGE en dos DMZ, una para la red externa (obligatorio a nivel seguridad) y otro a nivel de red interna (recomendado para hacer filtrado de puertos con más facilidad y además de segregar la red interna del EDGE con la red intena de la compañia).

Si alguien tiene alguna duda o quiere comentar su topología para que pueda analizarla si tiene algún problema, aquí os dejo mi correo: sbuitrago@asirsl.com. Es una pena ver instalaciones de Lync si "éxito" porque el EDGE no funciona como debe por un mal diseño o configuración. He visto clientes con mala impresión sobre Lync porque alguien no había configurado de forma correcta el EDGE, tenemos que saber como configurarlo de forma correcta y posicionar a Lync como un producto fiable , robusto y adaptable a cualquier organización que desee implementar una solución de "Comunicaciones Unificadas"

Espero sea de  utilidad!!