Microsoft Lync Server
Header

El primer escenario que vamos a ver es el más simple, un escenario típico para empresas de menos de 50 usuarios. Se dispone de pocos recursos para poder disponer de una infraestructura recomendaba, pero que igualmente si contamos con los componentes básicos podemos desplegar nuestra topología de Lync con todos los servicios. A continuación os comento la infraestructura con la que contamos según el esquema de red que se muestra en la imagen (pulsar en el esquema para verlo a tamaño original):

  • 1 Controlador de dominio
  • 1 Exchange Server 2013
  • 1 Front-END de Lync Server 2013
  • 1 Edge de Lync Server 2013
  • 1 Reverse-Proxy IIS ARR 2.5
  • 1 Router
  • 1 Switch
  • 1 Punto de Acceso Inalámbrico
  • 1 Conexión a Internet y una dirección IP IPública
  • 1 Subred IP 192.168.0.0 /24 para los equipos de la red
  • 1 Subred IP 172.26.0.0 / 29 para las interfaces WAN del EDGE y Reverse-Proxy

Topologías Lync 2013_1.jpg
Como os comentaba al principio nos centraremos únicamente en la parte de red y los servicios que queremos publicar hacia internet, de tal forma que podamos disponer de todos los servicios operativos desde dentro y fuera de la empresa. Como solo tenemos una dirección IP Pública lo que tenemos que hacer es adaptar nuestra configuración pública de Lync a este entorno, para ello en su momento había publicado un artículo de como podéis publicar los servicios Web de Lync y los del EDGE con una sola IP Pública, aquí os lo dejo para que podáis ver como sería: Cómo publicar todos los servicios de Lync, Exchange y WAC únicamente con una IP Pública Pero para realizar esta configuración debemos tener también unos mínimos en cuanto al hardware a utilizar, básicamente a nivel de Router/Firewall. Como es una empresa con menos de 50 equipos, solo tenemos una subred (192.168.0.0 /24) y no tenemos ninguna VLAN  configurada, por lo que es una red básica a nivel de enrutamiento. Ademmás, el Router o Firewall que tengamos tiene habilitado el protocolo NAT para que el resto de equipos de la empresa puedan conectarse a internet a través de el. Hasta aquí todo normal, pero ahora viene lo "complicado" en este entorno, sabemos que el EDGE requiere una configuración específica en cuanto a las direcciones IP que tendrá y que interfaces tiene. El rol del EDGE dispone de una interfaces de red interna y otra externa, y debe tener un rango de direcciones IP diferentes en cada interface. Además, solo puede tener un default gateway y será en la interface externa y además tiene que poder comunicarse con los equipos de la red vía interface interna. Dicho esto, ya nos hemos dado cuenta de el router debe tener la posibilidad de configurar en sus interface interna más de una subred IP, para que los equipos de la red se puedan conectar a Internet vía la subred 192.168.0.0/24 y el EDGE pueda hacerlo por otro rango diferente (yo he puesto que sería una subred 172.26.0.0/29). Como no tenemos posibilidad de crear una DMZ a nivel hardware lo haremos (salvando todas las distancias posible) vía subred. El router deberá soportar NAT en las dos subredes y tomárlas como internas, sino no sería posible esta configuración. De esta a nivel lógico los equipos en la subred 192.168.0.0/24 se podrían conectar a Internet y los de la subre 172.26.0.0/29 también tendrían esa posibilidad. En los routers que nos presta el ISP para darnos acceso a internet suelen tener varios puertos para conectarlo a nuestro swithc local y que así todo los equipos de la red puedan conectarse a internet a través suyo, pero esos puertos son tal cual puertos de switch y no son L3 para poder configurar diferentes subredes IP a nivel de interface. De esta forma, el router tendrá una interface virtual asignada a cualquier interface física de los puertos que tiene disponibles, de tal forma cuando lo conectemos a la red local vía switch nos podemos conectar a cualquiera de las IPs de cada subred cambiando únicamente la subred IP de nuestro PC. No es lo recomendable, pero es la única forma que tenemos de poder simular una DMZ y que el EDGE pueda tener dos interfaces con distintas subredes IP y tenga acceso a internet por una IP diferente a la subred local en donde se encuentran todos los equipos de la red. Explicarlo es un poco lioso, pero la idea es que un router que no tiene soporte de L3 en las interfaces LAN, que no tiene posibilidad de crear VLAN para separar el tráfico entre interfaces, etc.. pueda dar servicio a diferentes subredes IP para que podamos configurar los servicios del EDGE y también el Reverse-Proxy que también tiene dos interfaces que necesitan direccionamiento IP diferente. Aquí os muestro el direccionamiento que podríamos tener en nuestros equipos:

Topologías Lync 2013_Esquema_1_1.jpg

El esquema de conexión sería algo similar a este, conexiones físicas entre el router y los servidores EDGE y Reverse-Proxy y entre el router y el switch de la red local

Topologías Lync 2013_Esquema_1_2.jpg

El route tendría que conectarse por un lado al switch de la empresa para dar servicio a la subred IP 192.168.0.0/24 que es donde están los servidores y estaciones de trabajo, de tal forma que los equipos tienen acceso a Internet. Y por otro lado si es posible dos interfaces de red deberían conectarse directamente a los servidores EDGE y Reverse-Proxy en su interface externa, de esta forma los dos servidores comentados tendrían acceso a Internet igualmente por el mismo router pero con una subred local diferente a la de la red de la empresa. Esto es así, porque necesitamos configurar subredes diferentes en cada interface de red de los dos servidores que vamos a publicar directamente a internet. Y como además, necesitan tener acceso a la red local en donde están los servidores para publicar también sus servicios, por esto tenemos que conectarlo por otra interface al switch de la empresa y que tenemos configurada la subred 192.168.0.0/24. Lo que estamos haciendo no es más que dividir la red en dos subredes y configurar los equipos en un u otra subred en función de nuestro esquema de direccionamiento IP. El rango de IPs podéis poner los que queráis, mientras podáis tener rangos diferentes cada uno que elija los que quiera. Pero siempre es recomendable que para la subred IP que utilizaremos para las interfaces externas tanto del EDGE como del Reverse-Proxy que la subred IP sea lo más pequeña posible, de tal forma que evitaremos (con las herramientas que contamos es lo que hay) tener muchos host en esa subred y que algún usuario pueda cambiarse de subred IP y salir a internet de forma libre si por alguna de las subredes configuradas hemos dejado libre acceso. En este caso la subred de las interfaces externas está limitada a 6 host (/29). Del tal forma que en nuestro caso utilizaremos 3, una para el router, otra para el Reverse-Proxy y 1 para el EDGE. Por lo que quedaría bien ajustado, sobrando tres direcciones IP minimizando el riesgo.

Antes de dar por finalizada la configuración de las distintas subredes IP, deberíamos configurar en el router (si lo soporta) que no permite conexiones entre los equipos de las distintas subredes. Esto es vital para mantener la seguridad entre los distintos equipos de las diferentes subredes, está claro que sino es posible tenemo más alternativas  vía GPO (reglas de firewall locales), pero no es lo más recomendable. Una vez finalizada esta configuración, ya podríamos publicar los distintos servicios de Lync, Exchange, Office Web App mediante el reverse-proxy y EDGE. Para ello se tendrían que configurar las siguientes redirecciones de puertos en el router:

Topologías Lync 2013_Esquema_1_3.jpg

Recordaros que aquí la dificultad estaba en que solo tenemos una dirección IP y no podemos redireccionar un mismo puerto utilizando la misma combinación de misma IP Pública. De tal forma que tenemos que cambiar los puertos estandar de los servicios de Lync para poder publicar los servicios web por el puerto 443, puesto que este puerto es vital para los servicios Web de Lync y Exchange. Además, no podemos cambiarlo porque por ejemplo en el cliente Lync móvil no podemos especificarle el puerto de conexión, por lo que tiene que ir por defecto (HTTPS 443), pero no así los de Lync por lo que los podemos cambiar sin "problema" alguno (Cómo publicar todos los servicios de Lync, Exchange y WAC únicamente con una IP Pública)

Topologías Lync 2013_Esquema_1_4.jpg

En vez de utilizar varias IPS y nombres para los servicios, se utilizará el mismo nombre sip.dominio.com (la imagen es de otro artículo) y se utilizarán puertos diferentes al 443. EL 5061 que se utiliza para las federaciones se utilizará también para que los  usuarios puedan iniciar sesión desde Internet, y el resto de puertos se cambia sin problema pero revisad que no ocupéis un puerto que ya está utilizándos en el sistema operativo del servidor. Con esto cambios, debéis revisar el registro DNS de Tipo SRV creado para la autoconfiguración del cliente, porque el puerto para el acceso no es el 443 sino el 5061:

_sip._tls.dominio.com       SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   = sip.dominio.com

Con las federaciones no tendréis problema con el registro DNS de Tipo SRV, lo dejáis tal cual se crea por defecto porque se utiliza el puerto 5061

_sipfederationtls._tcp.dominio.com       SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   = sip.dominio.com

Como os comentaba el único puerto que no debéis modificar es el 443 para los servicios web, de ahí que se reservarse para redireccionar las peticiones que lleguen al router a ese puerto a la interface externa del Reverse-Proxy.  Por último comentaros, que como el EDGE ya tiene una interface con una dirección IP de la subred LAN (192.168.0.0/24) no necesitáis crear rutas estáticas, que visto alguna configuración así no tiene sentido, está en la misma subred IP y la interface interface tiene el cable de red conectado la switch de la empresa es más que suficiente.

Comentaros que en el Reverse-Proxy no es obligatorio tener dos interfaces  de red con dos subredes IP, funcionaría igualmente si configuráis la subred IP de la LAN (eso si, sino no llegaría a conectarse con los servidores internos) y no tiene porque estar en el dominio para publicar los servicios que utilizar Lync (Servicios Web de los Front-END, EWS de Exchange y Office Web App).

Resumiendo, cuando tenemos los recursos limitados un esquema similar a este hará que os funcionen todos los servicios perfectamente. Crear dos subredes, asignar direcciones IP diferentes a los servidores van a publiar los distintos servicios de la empresa (Reverse-Proxy y EDGE) y redireccionar posteriormente los puertos en el router que tengamos. Si el router no tiene la posibilidad de tener dos IPs privadas, tendríamos que buscar alternativas, que las tenemos. Se podría configurar un servidor para implementar NAT a nivel de Window Server, la interface pública en ese NAT tendría una dirección IP del mismo rango que el router y los equipos de la red tendrían que cambiar a otra subred IP. Esa misma subred IP se tiene que configurar en el segunda tarjeta de red del servidor que hemos configurado con NATA, para que su interface interna pertenezca a la misma subred y pueda conectarse con los equiipos de la LAN (Windows Server 2012, Instalación y Configuración de NAT). De tal forma que la puerta de enlace los equipos de la red seria la interface LAN de ese servidor, y el servidor se encargaría de conectarnos a internet vía la interface externa configurada.

El resto de servicios como DNS, DHCP, etc.. de los distintos servidores no tienen porque modificarse, simplemente que están en la subred IP de la LAN y poco más. El DHCP entregará direccionamiento IP a los equipos, los parámetros importante son DNS (Servidor DNS de la red, lo normal es que sea el controlador de dominio) y el Gateway (tiene que ser la IP privada del router, que para eso hemos configurado dos IPs en el router, una de cada subred). Los servidores de nuestra organización también tienen que tener como puerta de enlace el router que tenemos para darnos conectividad con internet, lo mismo que lo anterior, para eso hemos configurado dos Ips en el router. Una IP para dar servicios a la red local y la otra para las interfaces externas del EDGE y Reverse-Proxy.

Como véis es cuestión de darle algunas vueltas, pero nada complicado si tenemos el hardware adecuado. Hoy en día cualquier router tiene la posibilidad de configurar más de una IP local, etc…  Luego el resto de configuraciones vienen dadas ya por cada producto, pero lo importante es que tengamos claro que con un router, una IP Pública únicamente podemos ofrecer todos  publicar todos los servicios para lync sin problema.

Espero que os sea de utilidad y en breve publicaré el segundo esquema de red: LYNC ON-PREMISES | INFRAESTRUCTURA DE RED | 2 IP Públicas | 1 Subred IP Interna

Pulsar en la imagen y veréis un video espectacular en donde se muestra la potencia de Lync y como puede ayudar a nuesta formaciónAula_Virtual_Lync.JPG

El video está subtitulado en varios idiomas: Portugués, Español, Chino, Frances, Alemán, Italiano, Japonés, Hindi …

En su momento había publicado un artículo de como configurar un entorno de Alta Disponibilidad utilizando la replicación de las BBDD de Lync (Lync Server 2013: Configuración de Alta Disponibilidad (SQL Server Mirroring))​, pero lo había configurado sin un failover automático. En esta ocasión vamos a configurar un tercer servidor de SQL Server que hará de testigo, que permitirá disponer de un sistema de failover automático en caso de que el servidor de SQL declarado como "principal" esté caido o desconectado.  Este sería el esquema básico de sistema de mirroring con un testigo:

Lync_HA_SQL_Testigo.jpg
Como os había comentado en el artículo anterior (Lync Server 2013: Configuración de Alta Disponibilidad (SQL Server Mirroring)), si hemos configurado nuestras BBDD de Lync con mirroring, tenemos un sistema de alta disponibilidad pero no un failover automático. En el caso de que el servidor principal de SQL Server no se encuentre disponible, tenemos que ejecutar el siguiente cmdlet para establecer como servidor activo el segundo servidor:
 
Invoke-CsDatabaseFailover -DatabaseType <Application | Archiving | Monitoring | User | Provision | CentralAdmin | Lyss | Registrar | Edge | PersistentChat | PersistentChatCompliance | CentralMgmt> -NewPrincipal <Primary | Mirror> -PoolFqdn <Fqdn> [-Confirm [<SwitchParameter>]] [-ExcludeDatabaseList <String[]>] [-Force <SwitchParameter>] [-LocalStore <SwitchParameter>] [-Report <String>] [-WhatIf [<SwitchParameter>]]
 
Antes de ejecutar los siguientes cmdlets, debemos ejecutar Get-CsService –CentralManagement que nos devolverá que servidor está como principal y como reflejado:
Publicar_Topología_Error_Testigo_1.png
De esta forma podremos comprobar que servidor tiene que rol en este momento, entonces en función del estado de los servidores podremos ejecutar los siguiente cmdlets en función de la necesidad de cada escenario y en cada momento concreto. Veamos estos dos ejemplos:
 
Ejemplo 1: cuando queremos que el servidor de base de datos activo sea el reflejado (SRV-SQL01)
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType User –NewPrincipal mirror
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType App –NewPrincipal mirror
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType CentralMgmt –NewPrincipal mirror
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType Monitoring –NewPrincipal mirror
Ejemplo 1: cuando queremos que el servidor de base de datos activo sea el principal (SRV-SQL00)
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType User –NewPrincipal primary
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType App –NewPrincipal primary
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType CentralMgmt –NewPrincipal primary
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType Monitoring –NewPrincipal primary
Este proceso manual, tendrá un tiempo objetivo de recueración (RTO) de 5 min, pero el usuario no tendrá una experiencia completa hasta pasados unos 30 minutos. Durante este tiempo los usuarios estarán conectados pero no podrá utilizar ciertos servicios, como por ejemplo agregar usuarios, etc…. estarán en modo de resistencia (la traducción se las trae …). Ahora bien, esto lo podemos solventar y tener un sistema de failover automático y que los usuarios no tengan corte alguno. Para ello, debemos implementar un tercer servidor que nos haga de "testigo", básicamente sabrá que servidor está como primario y reflejado y los intercambiará en función de su disponibilidad. Esto nos permitirá que los usuarios no se vean afectados por la no disponibilidad de uno de los servidores y además la conmutación sea transparente también para el administrador. La configuración del mirroring tenía los siguientes requisitos en cuanto a las versiones de SQL Server se refiere: 
  • Lync Server Enterprise
  • Dos Servidores de SQL Server con la misma versión de SQL (Versión 2008 R2 o superior)
  • Una excepción de Firewall de Windows (o el que tengáis) para el puerto 5022 en TCP IN/OUT (utilizado por el mirroring)
  • Una carpeta compartida para el proceso de volcado iniciado de la base de datos desde el SQL Primario al receptor de la copia o secundario, esta carpeta compartida se puede borrar una vez que se haya completado la publicación
  • Establecer los permisos sobre la carpeta compartida, de tal forma que los usuarios asignados a los servicios de ambos SQL Server tengan acceso a la carpeta compartida con lectura/escritura

Pero si queremos añadir un tercer servidor que realice las funciones de testigo, no tiene porque tener la misma versión de SQL Server y además puede ser un SQL Server EXPRESS. Esto desde luego ayuda mucho a abaratar los costes de una solución de alta disponibilidad como esta. Una vez comentado esto, veamos como podemos configurarlo puesto que podemos realizar su configuración en mismo momento que configuramos el mirroring o a posteriori. En nuestro caso, como ya tenemos el mirroring de las BBDD de Lync completado (*), vamos a ver como implementarlo a posteriori. 

(*) Nota: Si queremos configurar un testigo y ya tenemos el morroring configurado, debemos primero deshacer el mirroring con el siguiente cmdlet primero y luego desde el generador de topologías

Uninstall-CsMirrorDatabase -SqlServerFqdn <SQLServer FQDN> [-SqlInstanceName <SQLServer instance name>] -DatabaseType <Application | Archiving | CentralMgmt | Monitoring | User | BIStaging | PersistentChat | PersistentChatCompliance> [-DropExistingDatabasesOnMirror] [-Verbose]

Con el modificador -DropExistingDatabasesOnMirror eliminará las BBDD del servidor reflejado, pero esto no siempre funciona bien  por lo que es posible que tengáis que eliminarlas de forma manual.

Como ya tenemos las BBDD en Mirroring, lo que haremos ahora será instalar un SQL Server 2012 en su versión EXPRESS para configurarlo como testigo. Para ello debemos descarganos los binarios necesarios (Download SQL Server 2012 Express with SP1) e iniciar su instalación:

Publicar_Topología_Error_Testigo_11.png

 

Publicar_Topología_Error_Testigo_12.png
Publicar_Topología_Error_Testigo_13.png
Publicar_Topología_Error_Testigo_14.png
Publicar_Topología_Error_Testigo_15.png

 

 

Si queremos podemos crear una instancia dedicada, pero no es obligatorio, si queréis podéis elegir la instancia predeterminadaPublicar_Topología_Error_Testigo_17.png
Publicar_Topología_Error_Testigo_20.png
Publicar_Topología_Error_Testigo_23.png
Publicar_Topología_Error_Testigo_24.png
Publicar_Topología_Error_Testigo_25.png
Publicar_Topología_Error_Testigo_26.png

 

Ahora que hemos finalizado la instalación podemos iniciar el Microsoft SQL Server Management Studio y vemos la instancia LYNC que hemos creado previamentePublicar_Topología_Error_Testigo_33.png

Ahora lo que debemos hacer es permitir las conexiones remotas, que por defecto en las versiones EXPRESS viene deshabilitado por defecto. Si queréis verificarlo, podéis iniciar el Microsoft SQL Server Management Studio desde otro servidor y tratar de conectaros a la instancia que hayáis configurado y veréis que no tenéis acceso:

 

Publicar_Topología_Error_Testigo_32.png
 
Para poder habilitar las conexiones remotas debemos configurarlo desde el Administrador de configuración de SQL Server
Publicar_Topología_Error_Testigo_27.png

 

Una vez dentro, nos vemos a la instancia de Lync que hemos creado anteriormente en el proceso de instalación dentro de la opción Configuración de red de SQL Server y habilitamos las Canalizaciones con nombre y TCP/IP

 

Publicar_Topología_Error_Testigo_28.png
Pulsamos con el botón secundario del ratón en cada uno de los protocolos y pulsamos en Habilitar
Publicar_Topología_Error_Testigo_29.png
 
Para que los cambios se hagan efectivos, debemos reiniciar los servicios del SQL Server EXPRESS una vez que hayamos habiiltado ambos protocolos
Publicar_Topología_Error_Testigo_30.png
El reinicio de los servicios podemos hacerlo directamente desde esta misma consola desde la opción de Servicio de SQL Server

 

Publicar_Topología_Error_Testigo_31.png

Por último, vamos a habilitar el servicio de SQL Server Browser y lo haremos desde las propiedades del servicio, cambiando el Modo de Inicio de Deshabilitado a Automático

 

Publicar_Topología_Error_Testigo_35.png
 
Iniciamos el servicio y una vez que el SQL Server y el Browser estén en ejecució y el modo de inicio en automático, ya podemos continuar con el resto de configuraciones de Lync

 

 

Publicar_Topología_Error_Testigo_34.png
Como sabéis, el testio uitlizará el puerto 7022 en TCP para conectarse con los servidores de SQL que tienen las BBDD en Mirroring, por lo que debemos crear una excepción en el firewall local  (o dispositivo de seguridad que fuese necesario). Esta configuración sería más recomendado hacerla por GPO, pero como es un LAB lo haremos de forma manual creando una excepción del puerto 7022 en TCP en el Firewall Local del servidor de SQL Server EXPRESS que hará de testigo para los servidores de BBDD de Lync:

 

Publicar_Topología_Error_Testigo_4.png

Publicar_Topología_Error_Testigo_5.png

Publicar_Topología_Error_Testigo_6.png

 

Como mi servidor que hará de testigo está unido al mismo dominio que el resto de servidores, solo habilito esta excepción para la red de dominio
Publicar_Topología_Error_Testigo_7.png

 

Publicar_Topología_Error_Testigo_8.png

Y una vez que hemos complido los requisitos necesarios, abrimos el Generador de Topologías de Lync Server, editamos nuestro pool de servidores Front-END y habilitamos la casilla Usar el testigo de creación de reflejo de SQL Server para habilitar la conmutación tras fallo automático

Publicar_Topología_Error_Testigo_2.png

Si previamente no hemos configurado ningún testigo, debemos pulsar en Nuevo y cubrimos los siguientes datos para dar de alta un testigo

Publicar_Topología_Error_Testigo_3.png

Una vez que hemos creado nuestro testigo, pulsamos en Aceptar y publicamos nuestra topología, con esto ya tenemos nuestros servidores de SQL Server con sus BBDD en Mirroring y el SQL Server EXPRESS como testigo. Para ello nos vamos al servidor BBDD principal y nos vamos a las propiedades de una de las BBDD reflejadas y vemos que ya tenemos el testigo configurado y preparado para establecer el servidor de SQL activo cuando sea necesario:

 

Publicar_Topología_Error_Testigo_43.png

 

Ahora cuando uno de los dos servidores SQL no esté disponible por la razón que sea, el testigo cambiará a principal en el mirroring el servidor que esté activo. Si queremos hacer una simulación solo debemos parar el servicio de SQL Server del servidor principal y veremos como  el servidor reflejado será el principal y el principal el reflejado. Esta configuración nos permitirá tener en Alta Disponibilidad con recuperación automática nuestros servidores de Back-END.
 
De todas formas, como os comentaba al inicio si queréis hacer el failover manual tenemos los siguientes cmdets:
 
Ejemplo 1: cuando queremos que el servidor de base de datos activo sea el reflejado (SRV-SQL01)
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType User –NewPrincipal mirror
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType App –NewPrincipal mirror
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType CentralMgmt –NewPrincipal mirror
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType Monitoring –NewPrincipal mirror
Ejemplo 1: cuando queremos que el servidor de base de datos activo sea el principal (SRV-SQL00)
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType User –NewPrincipal primary
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType App –NewPrincipal primary
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType CentralMgmt –NewPrincipal primary
  • Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType Monitoring –NewPrincipal primary
Como esto podemos configurar quien es el servidor principal y quien el reflejado por cada BBDD.

Espero que os sea de utilidad!!!

Es posible que nos hayamos encontrado situaciones en donde tengamos varias sedes conectadas por VPN y en la sede central tengamos nuestra implementación de Lync y a los usuarios de las distintas sedes remotas se les instala el cliente Lync para que puedan  realizar llamadas de Voz IP, Conferencias, etc.. Hasta aquí todo normal, pero el problema viene cuando las sedes están en distintos países o continentes, y todas las llamadas de voz IP se cursan mediante el cliente Lync. Esto es así porque hemos querido tener una única implementación central de Lync y allí configurar todos los servicios (El ROI en las Comunicaciones Unificadas), esto nos beneficia en muchas cosas pero el problema que tenemos es que estamos penalizando mucho el ancho de banda del enlace de VPN hasta la sede central. Puesto que el tráfico RTP se cursa desde el Mediation Server por dos externos, el del TRUNK SIP y el cliente Lync. Por un lado la llamada se establece con nuestro ISTP para que finalice la llamada su destino y el Mediation Server enlace al cliente Lync y ese TRUNK SIP. De aquí que siempre estamos consumiendo el ancho de banda de la VPN, y cuantas más llamadas simultáneas más problemas tendremos. El esquema sería más o menos el siguiente (pulsar en la imagen para visualizarla a tamaño completo):

Lync ByMediaPass-1.jpg

El esquema lo que trata de representar son dos sedes conectadas, en una tenemos nuestra topología de Lync y en la otra tenemos usuarios de Lync. Las sedes se han conectado mediante VPN, pero únicamente por razones de seguridad porque los usuarios están en el dominio que está en la sede principal y además tenemos varios servicios como OWA o SharePoint que los usuarios utilizan. Esto es solo lo expongo como dato, ahora mismo no sería relevante para lo que quiero comentar. Únicamente es para justificar la configuración de la VPN, porque sino alguien podría pensar que no sería necesaria la VPN porque para esto tenemos el EDGE y está en lo cierto, pero aquí vamos a ver el ejemplo con una VPN para que sea más representativo. Lo dicho, tal y como está la configuración que hemos desplegado el problema que tiene es que todo el tráfico se cursa por la VPN, aunque sean llamadas locales en nuestro propio país. Este compartimiento es el correcto, porque la configuración del TRUNK SIP la tiene el Lync y las llamadas las sacamos desde el Mediation Server y el desde el TRUNK SIP con el ITSP. Luego el ITSP podría enviar la llamada vía otro TRUNK SIP para abartar todavia más su coste, etc.. pero eso ya sería responsabilidad del ITSP. Pero nosotros eso no nos afectataría, pero si el resto del tráfico hasta que llega el TRUNK SIP entre el Mediation Server y el ITSP, porque una llamada «local» pasa por la VPN, el ITSP y el destino final (con x saltos si fuese necesario) y esto para cada llamada. ¿Qué podemos hacer si queremos optimizar las comunicaciones? Pues aquí podemos configurar un Gateway de Voz en la sede remota o en cada sede remota y habilitar la Omisión de Medios  entre el Mediation Server y el Gateway. Sino habilitamos la Omisión de Medios, cuando un usuario de Lync realiza una llamada de voz tanto la señalización como el tráfico de media pasa por el Mediation Server:

Lync ByMediaPass-2.jpg
Pero si habilitamos la Omisión de Medios, el tráfico de señalización si pasa por el Mediation Server pero el tráfico de media (RTP) no, por lo que se cursaría directamente entre el cliente de Lync y el Gateway:

Lync ByMediaPass-3.jpg

Como tendríamos un Gateway en las oficinas remotas, lo que ocurríria es que el tráfico de media se quedaría en local contra el Gateway, por lo que tendríamos un ahorro importante de ancho de banda en las sedes remotas y en la principal. Además, de garantizar mejor calidad en la llamada puesto que eso si, la llamada la cursaría el gateway que es el que tendría configurado el TRUNK SIP con el ITSP. De esta forma, las llamadas locales se cursarían a través del gateway. No tenéis que por tener un TRUNK SIP con un ITSP, si tel gateway tiene soporte para tarjetas BRI, PRI o analógicas las llamadas cursais por la tecnología que queráis. Para que esto funcione, debemos tener una VPN configurado (de ahí la necesidad de tener la VPN configurada)  para tener securidado el TRUNK SIP que también tenemos que tener entre el Gateway y el Mediation Server. Pensad que cuando un usuario de Lync quiere  realizar una llamada de Voz pasará por el Mediation Server y en funciuón de las reglas de las rutas de RTC asociadas a la directiva de Voz se enviará la llamada al troncal configurado. De esta forma, deberíamos configurar los usos de RTC adecuados para que las llamadas de cada sede salgan por la propia sede pero solo con un gateway y evitaríamos así también el tener que implementar un Sitio de Sucursal, etc…. Pero lo más importante sería el ahorro de ancho de banda, porque el tráfico de media claramente es el más «pesado» y dejaríamos la VPN únicamente para el tráfico indispensable porque todo el tráfico  RTP para las llamadas pasaría por el Gateway. Claramente, para que funcione esta configuración, el Gateway debe soportar esta configuración. Ahora, una vez comentado toda la teoría, veamos como es habilita la omisión de medios.
Para configurar la Omisión de Medios, debemos realizar varias configuraciones y empezaremos desde el Panel de Control de Lync – Enrutamiento de Voz – Configuración de Tronco y editamos el Tronco (Gateway) por el cual queremos enviar las llamadas con Omisión de Medios. Ahora debemos marcar la casilla Habiltar Omisión de Medios, en Nivel de compatibilidad de cifrado elegimos No compatible (a menos que lo sea, pero es raro tener algún gateway compatible, yo en mi caso utilzo Cisco) y guardamos la configuración
Lync ByMediaPass-4.jpg
Esta y otras configuraciones en el troncal las podemos hacer vía PowerShell: New-CsTrunkConfiguration -Identity Service:xxxxx  -EnableBypass $True -RTCPActiveCalls $False –RTCPCallsOnHold –RTPMode
Ahora nos vamos a la sección de Configuración de Red – Global y editamos la configuración que tenemos que marcar Habilitar omisión de medios y en mi caso elegiré Omitir siempre.
Lync ByMediaPass-5.jpg
Por último y ya mediante PowerShell debemos especificar que no se use SRTP para los gateway que no son compatibles (el mío no lo es) y para ello tenemos el siguiente cmdlet: Set-CsMediaconfiguration –Identity global –Encryptionlevel SupportEncryption
Lync ByMediaPass-10.jpg
Si queremos verificar que el cambio se ha realizado correctamente, lo vemos vía otro cmdlet: Get-CsMediaConfiguration
Lync ByMediaPass-11.jpg
Con esto ya tendríamos habilitado la Omisión de Medios en Lync, y para que veáis la diferencia os voy mostrar dos capturas de WiresHark una sin la Omisión de Medios habilitada y otra con la Omísión de Medios habilitada. Para ello os comento lo siguiente, mi equipo y el Gateway (Cisco) está en la subred 192.168.100.0/24, esto representaría una sede remota y el Lync Server está en la subred 192.168.250.0/24:
  • Sin Omisión de Medios habiltado: Todo el tráfico RTP se destina hacia el Mediation Server (192.168.250.83) (captura 1) y no se envía nada al Gateway (192.168.100.50) (captura 2)
Lync ByMediaPass-6.jpg
Lync ByMediaPass-7.jpg
  • Con la Omisión de Medios habiltado: Todo el tráfico RTP se destina hacia el Gateway (192.168.100.50) (captura 1)
Lync ByMediaPass-9.jpg
Así el tráfico RTP se queda en mi red local y no atraviesa una y otra vez la VPN, menor congestión del enlace y mejor experiencia de usuario. Además, con esto reducimos la latencia, jitter, etc.. que viene dado por la falta de conectividad o el uso o mal uso del mismo. No he comentado al principio algo importante, que entre distintos continentes las conexión suelen tener una retardo latencia muy elevada dependiente de las líneas que tengamos contratadas, lo que hace que de por sí esto sea un problema.  Los beneficios de la utilización de Omisión de Medios son claros:
  • Mejora la calidad de la llamada al reducir la latencia
  • La traducción innecesaria
  • La posibilidad de pérdida de paquetes
  • El número de puntos de errores potenciales.
Si a todo esto, le añadimos que utilizamos el Códec 7.11 (a estas alturas imagino que no habrá que comentar que es el que utiliza Lync), pues el ancho de banda en las sedes y en la central que da soporte a todas las sedes conectadas se ve seriamente afectado
Lync ByMediaPass-13.jpg
De esta forma, el tráfico de señalización es mínimo y cuando establezcamos la llamada los RTP se cursarán directamente por nuestra línea de datos. Y a todo esto si le añadimos que el gateway tiene configurado un ITSP local, el rendimiento será todavía mayor. De esta forma no tendremos que desplegar o extender nuestra infraestructura de Lync (servidores, licencias, etc…)
Espero que os sea de utilidad!!!

 

Muchos de vosotros es posible  que hayáis integrado Lync Server 2013 con Exchange 2013 (Lync Server 2013: Integración con OWA en Exchange Server 2013) para que en OWA podamos mostrar la presencia y tener IM desde la Web. ​Hasta ahí todo perfecto, pero el problema es posible que os llegue cuando actualicéis a Exchange Server 2013 SP1 y os deje de funcionar …

Integracion_Lync_OWA_24_Exchange_SP1.png

Esto viene dado por dos razones principalmente, siempre y cuando no hayáis hecho nada más que actualizar al SP1

  • Topología en HA: Ahora el fichero web.config de OWA se ha traslado a los servidores de buzones, ya no está en los CAS. Por lo que debéis modificar el web.config en los servidores de buzones y Lync dejarlo tal cual estaba
  • Topología Simple: Como todos los roles están en el mismo servidor, debéis guardar una copia del web.config de OWA porque con la instalación se sobrescribirá el fichero. Una vez que se complete la instalación, volver a establecer los valores necesarios debajo de   <appSettings>

<add key="IMCertificateThumbprint" value="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"/>
    <add key="IMServerName" value="FQDN_POOL_LYNC"/>

Una vez que volváis a configurar el fichero (Lync Server 2013: Integración con OWA en Exchange Server 2013) el servicio volverá a funcionar sin problema:

Integracion_Lync_OWA_24_Exchange_SP1_1.png
 
Teniendo esto en cuenta, ya no tendréis problemas con vuestra integración de Lync en OWA después de la instalación del SP1 en Exchange 2013.

Espero que os sea de utilidad!!!