Microsoft Lync Server
Header

Cuando implementamos los Grupos de Respuesta en Lync, tenemos la posibilidad de configurar Grupos de Búsqueda o Interactivos:

  1. Lync: Grupos de Respuesta (Parte I)
  2. Lync: Grupos de Respuesta (Parte II)
  3. Lync: Grupos de Respuesta (Parte III)
  4. Lync: Grupos de Respuesta (Parte IV)
Y es muy probable que configuremos que fuera del horario laboral se desvíen las llamadas a un número de teléfono.
Error_LLamada_Externa_Grupo_Respuesta_10.png
Pero una vez que lo probamos, nos encontramos que las llamadas no se desvían y a la persona que nos llama se le cae la llamada. Por lo que ahora debemos ejectura las Lync Server 2013 Logging Tool y nos encontramos con el siguiente error:
 
ms-diagnostics: 12004;reason="The user is not authorized to call the specified number or none of the routes have a valid gateway configured"
 

Y también este otro código de error

Error_LLamada_Externa_Grupo_Respuesta_11.png

Este es un comportamiento normal, puesto que el número de teléfono asociado al desvio no pertenece a ningún usuario por lo que no podrá utilizar ninguna regla de normalización ni ruta ni nada. Por lo que no será posible desviar las llamadas a dicho número, porque no le será posible asignarle ningúna Directiva de Voz que aplicar. De aquí que lo debemos hacer es configurar una Directiva de Voz (sino la tenemos ya)  y asignársela al Grupo de Respuesta que hemos configurado. Para ello debemos aplicar una Directiva de Voz a nuestro Flujo de Trabajo, esto lo haremos mediante powershell:

Flujo de Trabajo: IPEditorial

Directiva de Voz: DV_IPEDITORIAL

Error_LLamada_Externa_Grupo_Respuesta_1.png
Ahora se aplicará la Directiva de Voz "DV_IPEDITORIAL" al Grupo de Respuesta, por lo que si volvemos a probarlo veremos como se aplica correctamente. Ahora vemos que llamada se establece y vemos como se aplica la directiva de voz con sus Rutas (con su gateway correspondiente) y Usos de RTC:

Error_LLamada_Externa_Grupo_Respuesta_7.png
Ahora ya podemos desviar las llamadas a cualquier número de teléfono, puesto que la directiva de Voz que se le aplica será DV_IPEDITORIAL.

Esto es válido para cualquier escenario con un Grupo de Respuesta con desvíos de llamadas a números de teléfonos, pero yo lo he centrado en un entorno híbrido en donde tenemos Lync Server 2013 y un Gateway de Cisco UC540 con dos líneas BRI. Los usuarios utlizan Lync 2013 como cliente, se ha configurado un Trunk SIP (Lync Server: Direct SIP, Trunk SIP e Inter-Trunk Routing) entre Lync y el UC540 de Cisco. Además ambos sistemas están conectados entre sí (Trunk SIP) mediante una VPN IPSec Site-to-Site (Lync Server: Recomendaciones para Securizar un Trunk SIP o Direct SIP), y las llamadas se reciben y cursan mediante los enlaces BRI conectados al UC540. De tal forma, como vemos en log de las Lync Server 2013 Logging Tool el plan de marcado de las llamadas entrantes se corresponde con el DefaultProfile (Lync Server: Planes de Marcado y Reglas de Normalización para Llamadas Entrantes) sino tenemos un plan de marcado de grupo:

Error_LLamada_Externa_Grupo_Respuesta_12.png

Este sería el esquema de la solución en la que se  basa este artículo en cuanto al TRUNK SIP, Grupos de Respuesta y Enlaces BRI

Lync_VPN_IPSec_GR.jpg

Es un "problema" sencillo de resolver, es cuestión de analizar bien la información que obtenemos de las Lync Server 2013 Logging Tool y aplicar cierta lógica. Otra cosa será a posteriori conocer los distintos comandos y como aplicarlos, pero eso ya es cuestión de darle alguna vuelta a la documentación de MSFT: http://technet.microsoft.com/en-us/library/gg398655.aspx, http://technet.microsoft.com/es-es/library/gg398828.aspx

Espero que os sea de utilidad!!

Aquí os dejo una tabla muy interesante, en donde se nos muestra información de distintos dispositivos USB y los test realizados en función de la revisión del dispositivo

Test_Pruebas_PC_Lync_Logo.png
Version Date Published Specification
Revision A July 2009 Provided under NDA only
Revision B November 2009 Provided under NDA only
Revision C April 2010 Provided under NDA only
Revision D October 2010 LyncLogoRevD.zip
Revision E April 2011 LyncLogoRevE.zip
Revision F October 2011 LyncLogoRevF.zip
Revision G August 2012 LyncLogoRevG.zip
LyncLogoRevG_H264Encoding.zip

 

Dentro de cada fichero de las especificaciones de las distintas revisiones, tenemos varios documentos con los resultados de las distintas pruebas.Test_Pruebas_PC_Lync_1.png

Además, de un fichero de Excel con los distintos test realizados, que además nosotros podemos utilizar y completar en función de los test caseros que hagamos de nuestros dispositivos

Test_Pruebas_PC_Lync_2.png

Test_Pruebas_PC_Lync_3.png

Test_Pruebas_PC_Lync_4.png

Estas cosas demuestran que los dispositivos pasan exhaustivos test antes de llegar a nosotros, pero si encima tenemos esta información para mi los hace más valioso

Espero que os sea de utilidad!

 

 

MSFT ha publicado una actualización del documento eDiscovery Flow Across SharePoint, Exchange, Lync, and File Shares:

 

eDiscoveryArchitecture_22_07_2013.jpg

Aquí os dejo los enlaces de descarga:

 

Espero que os sea de utilidad!!!

A estas alturas no creo que nadie que utilice Lync Server no tenga claro que para poder configurar la federación, debemos permitir hacia la IP de Acceso del EDGE el puerto 5061 en TCP. En su momento había publicado distintos artículos de cómo configurar un EDGE:

Lync_Edge_Federación_Firewall_Cisco_14.png
Ahora que tenemos claro que el puerto utilizado para la federación es el 5061 en TCP, vamos a ver cómo podemos configurar nuestro Firewall Cisco ASA 5510 para permitir las comunicaciones hacia nuestro EDGE si hemos implementado el EDGE detrás de NAT. Su configuración es muy sencilla, pero voy a tratar de describir los pasos que debemos dar para configurarlo. Vamos a configurarlo mediante ASDM para facilitar su configuración a los técnicos que no estén acostumbrados a manejarlo a diario.  Yo he utilizado un Cisco ASA 5510 con las siguientes características:
 
Lync_Edge_Federación_Firewall_Cisco_13.png
Pues comentado esto, abrimos nuestro ASDM, vamos a Access Rules y en la interface WAN (Level 0) pulsamos con el botón secundario del ratón y pulsamos en Add Access Rule. Lo que haremos aquí básicamente es configurar una ACL para permitir o no la conexión al puerto 5061 en nuestra interface WAN de entrada, pero aquí no "abrimos" el puerto aún.
 
Lync_Edge_Federación_Firewall_Cisco_1.png
Debemos especificiar la IP de Origen, Destino y Servicio.
Lync_Edge_Federación_Firewall_Cisco_2.png
Por defecto, el Cisco ASA no tiene como protocolo predefinido el puerto 5061 (solo tiene SIP en TCP y UDP)
Lync_Edge_Federación_Firewall_Cisco_3.png
Para poder crear nuestro propio servicio pulsamos en Add y TCP Service Group…
Lync_Edge_Federación_Firewall_Cisco_4.png
Escribiemos el nombre del Grupo, Descripción (opcional), seleccionamos Create new member, escribimos el número de puerto (5061) y pulsamos en ADD
Lync_Edge_Federación_Firewall_Cisco_5.png
Una vez que hemos pulsado en Add podemos pulsar en OK para completar la creación del servicio
Lync_Edge_Federación_Firewall_Cisco_6.png
Ahora que lo tenemos creado, lo podemos buscar y agregarlo para aplicarlo a la ACL
Lync_Edge_Federación_Firewall_Cisco_7.png
Pulsamos en OK  para finalizar la configuración de la ACL. Si queremos filtrar la conexión al servicio, podemos establecer la opción de source con la IP de origen. Sino la tenemos creada como un objeto, pulsamos en los tres puntos de la derecha y creamos el nuevo objeto (equipo) con la IP correspondiente (similar a la creación del servicio)
Lync_Edge_Federación_Firewall_Cisco_8.png
La primera parte la hemos completado, ya tenemos nuestra ACL configurada
Lync_Edge_Federación_Firewall_Cisco_9.png
Por último vamos a configurar el Port Forwarding (redirección de puertos), para ello pulsamos en NAT Rules y luego en Add Static NAT Rules… sobre la interface privada (Level 100) que se corresponde con el gateway de los equipos que se conectan a Internet mediante este dispositivo
Lync_Edge_Federación_Firewall_Cisco_10.png
Aquí debemos prestar algo de atención para que nos funcione a la primera, no tiene nada en especial para los que estamos acostumbrados a trabajar con estos dispositivos pero para el resto es posible que sí. En la primera parte (Original) debemos elegir la interface Interna (LAN en mi caso) y en source escribimos la dirección IP del servidor al cual queremos enviar las peticiones recibidas desde Internet al puerto 5061. En nuestro caso debemos especificar la IP de acceso del EDGE. En la opción Translated debemos seleccionar la interface WAN (Level 0) en mi caso se llamad Internet, pero como nuestro Firewall puede tener más de una IP Pública nos permite elegir si queremos especificar la IP Pública por lo que esperamos que nos llegue las conexiones al puerto 5061 o bien sino tenemos más que una IP Pública en el Firewall podemos elegir User Interface IP Addres. Lo último que debemos especificar es el número de puerto del servicio y habilitando la casilla de PAT, en ambas casillas (Original Port y Traslated Port) escribimos el número de puerto. En caso de que quisiéramos que la petición nos llegase por el puerto 5061 y la enviásemos a otro puerto diferente si tendríamos que colocar diferentes puertos. OJO, para este servicio lo vamos a dejar tal cual lo veis en la imagen:
Lync_Edge_Federación_Firewall_Cisco_11.png
Para finalizar pulsamos en Apply y ya tenemos publicado nuestro servicio de federaciones a nivel de configuración de dispositivos de seguridad
Lync_Edge_Federación_Firewall_Cisco_12.png
 
El procedimiento para otros dispositivos de seguridad será similar, parecido o no, pero lo que si debemos tener claro es que el puerto que debemos tener accesible desde internet es el 5061 en TCP.

Espero que os sea de utilidad!!

Algo que debemos tener en cuenta cuando implementamos Lync, es conocer la topología de red de nuestro cliente. En muchas ocasiones nos encontramos con Firewalls, IDS, IPS, VLAN, IPSec, etc…, por lo que debemos realizar algunos cambios para ajustarlo para obtener el mejor rendimiento de Lync. Lo más común es modificar las reglas de publicación de puertos de los Firewalls, ACLs en los Switchs L3 para permitir la comunicación entres VLANs, etc… pero que ocurre si tenemos implementado IPSec? Es probable que en el momento de asociar los puertos de medios, tengamos problemas con el tiempo de negociación de IPSec y por tanto las llamadas no se establezcan o problemas similares. Para evitar este más que probable comportamiento, debemos habilitar las siguientes excepciones del tráfico de IPSec:

Excepciones_IPSec_Para_Lync_1.png
Por supuesto esto también dependerá del hardware que utilicemos para implementar IPSec (Firewalls, Routers, etc…), si por el contrario utilizamos las Directivas de seguridad IP en Equipo Local debemos modificar la regla correspondiente puesto que además esto de por sí tiene un impacto importante en las comunicaciones del servidor/equipo.
Excepciones_IPSec_Para_Lync_2.png

Espero que os sea de utilidad!!!