Microsoft Lync Server
Header

Lync Server: InstallDatabaseInternalFailure: Error interno al intentar crear o actualizar la base de datos

septiembre 3rd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

​Quiero comentaros uno de los problemas que me he encontrado ahora mismo cuando he querido publicar una topología de Lync Server 2013: InstallDatabaseInternalFailure: Error interno al intentar crear o actualizar la base de datosError_Publicación_Lync_NtAccountTypeUnknown_1.png

El problema viene dado cuando he querido publicar la topología, hasta la fecha no había tenido problema alguno con el dominio. Para poneros en situación, os comento que toda la plataforma de MV había sido implementada por un proveedor de IaaS, por lo que yo debería configurar el dominio, TMG y Lync Sever 2013. Estos son los servidores de los cuales dispongo:

  • 1 Controlador de Dominio
  • 1 Servidor de Office Web App
  • 1 Front-END de Lync Server 2013
  • 1 EDGE de Lync Server 2013
  • 1 TMG 2010 SP2 como Reverse-Proxy
Lo primero que se ha hecho es actualizar todas las máquinas con las últimas actualizaciones disponibles (sobre 350MB por servidor), posteriormente e ha configurado el dominio y unido las máquinas al dominio. Ahora se ha configurado un CA, los pre-requisitos del servidor de WAC, Front-END de Lync y EDGE de Lync. Una vez todo configurado (incluso el TMG), empiezo a notar algún comportamiento extraño entre dos servidores a los cuales no puedo acceder a través del EDGE porque no me validaba las claves de usuario (TMG y Front-END), sin embargo si me conecto al controlador de dominio desde ahí si puedo hacerlo. Pensando que inicialmente puede ser otra cosa, continuo con la instalación de Lync, BBDD, etc… y cuando termino de configurar la topología y trato de publicarla me encuentro con el problema que os muestro en la captura anterior. Claramente lo primero que hago es revisar los siguiente:
  • Que haya iniciado con un usuario con los derechos administrativos necesarios (los tenía, pero nunca está de mas asegurarse)
  • Los permisos sobre la carpeta CsData
  • Que el servidor tenga espacio disponible en la partición de Sistema
Y claro, aparentemente estaba todo correcto, pero revisando más en detalle el log del error mostrado me encuentro con esto:
Error_Publicación_Lync_NtAccountTypeUnknown_2.png

Como vemos no se reconoce la cuenta de inicio de sesión, por lo que estas cosas siempre suelen ir ligadas a duplicidad de SID (Identificador de Seguridad) y como todos sabemos no pueden existir dos máquinas con el mismo SID en nuestro dominio. Aquí os dejo un artículo muy interesante para los que no conozcáis lo que es el SID y los problemas de la duplicidad de SID: http://bit.ly/14lYgRz

Teniendo en mente que el problema podría venir por una duplicidad de SID, me he descargado las  Download PsTools (1.60 MB), en donde tenemos la utilidad PSGetSID la cual nos permite visualizar de forma sencilla el SID de cada equipo unido al dominio o no. Si queremos que nos muestra el SID de la máquina sobre la cual ejecutamos la herramienta, únicamente debemos ejecutarla desde una línea de comandos sin modificador alguno, pero si queremos encontrar el SID de una máquina de forma remota de debemos ejecutar el psgetsid.exe con el siguiente modficador:

Y aquí tenemos todos los modificadores posibles para PSGetSID
Usage: psgetsid [\\computer[,computer[,…] | @file] [-u username [-p password]]] [account|SID]
-u Specifies optional user name for login to remote computer.
-p Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password.
Account PsGetSid will report the SID for the specified user account rather than the computer.
SID PsGetSid will report the account for the specified SID.
Computer Direct PsGetSid to perform the command on the remote computer or computers specified. If you omit the computer name PsGetSid runs the command on the local system, and if you specify a wildcard (\\*), PsGetSid runs the command on all computers in the current domain.
@file
PsGetSid will execute the command on each of the computers listed in the file

Una vez ejecutado en todos los servidores, me encuentro una desagradable sorpresa por un lado y por otro la causa del problema:

SID for \\SRV-LYNC00:
S-1-5-21-639020047-2635447608-3603641496
SID for \\srv-fw00:
S-1-5-21-639020047-2635447608-3603641496
SID for \\srv-dc00:
S-1-5-21-639020047-2635447608-3603641496
SID for \\srv-wac00:
S-1-5-21-639020047-2635447608-3603641496
SID for \\EDGE:
S-1-5-21-639020047-2635447608-3603641496

Ahora bien, como se soluciona esto, puesto ejecuntado un SYSPREP (¿Qué es Sysprep?) a cada servidor, pero sin tocar el DC para que no tenga que reconstruir el dominio de nuevo. Simplemente dejar al DC con ese SID y el resto lo volverán a generar de forma aleatoría. Debemos borrar las cuentas de los servidore unidos al dominio, para que cuando los volvamos a crear tengamos la seguridad de que se asigna con el nuevo SID. Esto ocurre cuando se clona una máquina base para acelerar el proceso de despliegue de entornos virtualizados, pero también se podía hacer en su tiempo con las máquinas fisicas con Norton Ghost, Acronis. No es que ahora no se puede hacer, pero ya es menos común. En este caso mi proveedor se le ha olvidado aplicar un SYSPREP y la verdad me ha fastitiado un poco, porque ha tirado a la basura algunas horas de mi trabajo.

La idea era comentar el problema de publicación de Lync y las causas, aunque finalmente he tenido que comentar otras cosas

Espero que os sea de utilidad!!!

Lync Server: Modificar el tiempo de validez de un certificado de usuario

septiembre 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Hace ya algún tiempo, había publicado un artículo que me había parecido muy interesante sobre la diferencia entre deshabilitar un usuario en el Directorio Activo y no en Lync: Deshabilitar un usuario en el Directorio Activo y en Lync

Aqui os dejo el texto incial del artículo para que veáis de que se trata: 

​En más de una ocasión os habréis encontrado con la situación de tener que deshabilitar un usuario en el Directorio Activo que tiene cuenta de Lync. Sin embargo esto no evita que el usuario pueda iniciar sesión en Lync durante un periodo máximo de 6 meses, y siempre en función de otros factores. Esto puede llegar a ser un problema muy importante para las organizaciones, puesto que el usuario  podría estar realizando llamadas a la PSTN sin control o incluso hablar con gente de la organización y poder sacar información de la empresa sin que nadie de cuenta de ello. 
 
Caducidad_certificados_1.png
 
Pues ahora vamos a ver como podemos manejar el tiempo de expiración de un certificado de usuario emitido por nuestro servidor de Lync. Por defecto, como os había comentado los certificados tienen una fecha de expiración de 6 meses, esto en algunos casos puede ser excesivo, por lo que debemos poder manejar estas ventanas temporales de alguna forma.  Y por supuesto que podemos hacerlo, para ello tenemos el siguiente cmdlet para establecer el tiempo máximo de duración de un certificado de usuario:
 
Set-CsWebServiceConfiguration –DefaultValidityPeriodHours
 
Pues si queremos que en vez de 6 meses, los certificados caduquen a los 90 días el valor de DefaultValidityPeriodHours deberá ser de 2160:
 
Set-CsWebServiceConfiguration –DefaultValidityPeriodHours 2160
 
A partir de este momento, todos los usuarios que inicien sesión en Lync recibirán un certificado de usuario por parte del servidor con una duración máxima antes de caducar de 90 días. Pero claro, que ocurrirá con los usuarios que un día antes de este cambio ya se las había emitido el certificado, pues que seguirán utilizando este certificado hasta que caduque. Y claramente, esto no es lo que queremos, para ello lo que podemos hacer es revocar todos los certificados de usuarios, y la próxima vez que los usuarios inicien sesión ya tendrán el nuevo certificado con una caducidad de 90 días. Para ello tenemos el siguiente cmdlet que revocará todos los certificados asignados a los usuarios:
 
Get-CsClientCertificate | Revoke-CsClientCertificate
 
También podemos establecer el valor mínimo y máximo de validez de un certificado pero con las siguientes limitaciones:
  • Mínimo –> 1 Hora
 Caducidad_certificados_2.png
  • Máximo –> 8760 Horas (1 año)
 Caducidad_certificados_3.png

Para establecer estos valores, debemos utilizar los siguientes cmdlets:
 
Set-CsWebServiceConfiguration –MinValidityPeriodHours 1

 

Set-CsWebServiceConfiguration –MaxValidityPeriodHours 2880
 
Así que ya sabéis, que si necesitáis cambiar la fecha de caducidad de vuestros certificados de usuario, dos comandos y todo arreglado.
 
Espero que os sea de utilidad!!!

Lync Server: Reverse-Proxy requisito indispensable

agosto 30th, 2013 | Posted by Santiago Buitrago in Lync Server - (1 Comments)

Algo que debemos tener en cuenta cuando estamos ante una implementación de Lync, es que a parte de los servidores en donde instalaremos la plataforma necesitaremos una solución de reverse-proxy. Esto lo necesitamos para publicar los distintos servicios web de Lync y otros servidores de nuestra organización:

  • Reuniones en línea
  • Conferencias telefónicas
  • Libreta de direcciones
  • Office Web Apps
  • Exchange Web Services (EWS)
Existen múltiples fabricantes con soluciones de reverse-proxy, tanto vía hardware como software (F5, KEMP, TMG 2010) y que debemos adquirir. Pero también tenemos alguna solución más «casera» pero funcional como es ARR (Application Request Routing Module), aquí os dejo un enlace para que podáis conocerla en profundidad: http://www.iis.net/learn/extensions/planning-for-arr/using-the-application-request-routing-module. Microsoft no nos obliga a adquirir ninguna solución de reverse-proxy, pero nos muestra los requisitos que debe cumplir para ser compatible con Lync:
  • Usar la Capa de sockets seguros (SSL) y la Seguridad de la capa de transporte (TLS) implementadas mediante certificados emitidos por una entidad de certificación pública para conectarse a los servicios web externos publicados del Director, Grupo de directores, Servidor front-end o Grupo de servidores front-end. El Director y el Servidor front-end pueden estar en un grupo de carga equilibrada mediante equilibradores de carga de hardware.
  • Poder publicar externamente un sitio web hospedado de forma interna usando su nombre de dominio completo (FQDN).
  • Poder publicar todo el contenido del sitio web hospedado. Se puede usar de forma predeterminada la directiva /*, que la mayoría de los servidores web identifica como que significa «Publicar todo el contenido en el servidor web». También se puede modificar la directiva, por ejemplo, /Uwca/*, que quiere decir «Publicar todo el contenido en el directorio virtual Ucwa».
  • Debe ser configurable para requerir conexiones de Capa de sockets seguros (SSL) o de Seguridad de la capa de transporte (TLS) con los clientes que soliciten contenido de un sitio web publicado.
  • Debe aceptar certificados con entradas de nombre alternativo del firmante (SAN).
  • Debe poder permitir el enlace de un certificado a una interfaz o agente de escucha a través del que el FQDN de servicios web externos vaya a resolverse. Se prefiere una configuración de agente de escucha a una de interfaz. Se pueden configurar varios agentes de escucha en una sola interfaz.
  • Debe permitir la configuración de control de encabezados de host (Los encabezados host (que también se conocen como nombres de dominio o nombres de host) permiten asignar varios sitios a una sola dirección IP en un servidor web.). Con frecuencia, el encabezado de host original enviado por el cliente solicitante debe pasar de forma transparente, en lugar de modificarse a través del proxy inverso.
  • Crear un puente para el tráfico SSL y TLS desde un puerto definido externamente (TCP 443, por ejemplo) a otro puerto definido (TCP 4443, por ejemplo). El proxy inverso puede descifrar el paquete al recibirlo y, seguidamente, volver a cifrarlo en el envío.
  • Crear un puente para el tráfico TCP no cifrado desde un puerto (TCP 80, por ejemplo) a otro (TCP 8080, por ejemplo).
  • Permitir la configuración para los tipos de autenticación Sin autenticación y Autenticación de paso a través.
Todos los requisitos son indispensables, pero los que he marcado en rojo serían los más importantes a mi entender. En el siguiente esquema trataré de mostraros un reverse-proxy (TMG 2010) que utlizaremos para publicar los servicios web de Lync y las Office Web Apps. Todo ello vía HTTPS para que los usuarios puedan conectarse a los servicios de movilidad y las reuniones en línea con todas las características disponibles.
(pulsa en la imagen para verla a tamaño completo)
Proxy_Inverso.jpg
Como ya sabemos los servicios Web de nuestro Front-END tenemos dos sitios web, uno para los servicios internos y otro los externos.
Proxy_Inverso_Lync_2013_1.jpg
Como sabemos las URLs simples configuradas en la topología serán las que se utilicen para conectarse a los distintos servicios web, entre los cuales tenemos las reuniones online (meet.dominio), conferencia telefónica (dialin.dominio.com), servicios web para los dispositivos móvils (lyndiscover.dominio.com y lyndiscoverinternal.dominio.com). Ahora bien, no podemos tener dos sitios web con SSL a la escucha en el mismo puerto (a excepcion de que en Windows Server 2012 utilicemos SNI (Windows Server 2012, Encabezados de Host en SSL con SNI en IIS 8), pero que Lync no los necesita ni utilizará), de ahí que por defecto cuando los instalamos ya están en puertos diferentes:
  • Servicios Web Internos
    • HTTPS 443
    • HTTP 80
  • Servicios Web Externos
    • HTTPS 4443
    • HTTP 8080
Lo normal es que los usuarios se conecten a los distintos servicios por los puertos estándar, de tal forma los usuarios que se conecten desde dentro de la red se conectarán a los servicios web internos y ahí tenemos los puertos 80 y 443 configurados. De esta forma, los usuarios que se quieran conectar al Lync Web App accederán únicamente escribiendo la URL de la reunión sin tener que especificar puerto alguno, puesto que por defecto el puerto para el HTTPS es el 443 y los navegadores será el que utilice. Ahora bien, que ocurrirá con los servicios Web Externos, pues que debemos publicar las distintas URLs desde nuestro reverse-proxy y configurando un cambio de puerto de escucha al de publicación del servidor. Puesto que también queremos que las distintas URLs utlicen puertos estándar y no tengamos problemas con bloqueos de firewalls, etc.. Vamos a ver alguna capturas de pantalla de como se debe configurar la publicación de los distintos servicios web mediante el TMG:
  • Servicios Web de Lync
Escribimos un nombres descriptivo para esta regla de publicación de sitios web y seleccionamos permitir
TMG_Publicacion_50.pngTMG_Publicacion_51.png
en función de vuestra topología debéis elegir la mejor opción de la primera pantalla, pero en la segunda sí o sí la primera opción de publicación de sitio web usando SSL
 TMG_Publicacion_52.pngTMG_Publicacion_53.png
escribiremos el nombre de nuestro servidor de Front-END, el nombre del Pool de servidores Front-END o el FQDN del servidor de Director
TMG_Publicacion_54.png TMG_Publicacion_55.png
En el nombre público escribiremos el fqdn establecido para los servicios web externos definido en la topología, y elegimos el listener HTTPS previsamente configurado con su certificado (Certificados SAN o Wildcard para nuestra implementación de Lync Server)
TMG_Publicacion_56.pngTMG_Publicacion_57.png
Importante, debemos elegir la opción No delegación, pero los usuarios podrían autenticar directamente
TMG_Publicacion_58.pngTMG_Publicacion_59.png
en la pestaña Nombre Público (Public Name) debemos escribir todos los FQDN de los distintos servicios que vamos a publicar:
  • Conferencia Telefónica: dialin.dominio.com (las capturas son del dominio ucomsenespanol.com, pero cada uno debe especificar su propio dominio)
  • Servicio para dispositivos móviles: lyncdiscover.dominio.com (las capturas son del dominio ucomsenespanol.com, pero cada uno debe especificar su propio dominio)
  • Reuniones Online: meet.dominio.com (las capturas son del dominio ucomsenespanol.com, pero cada uno debe especificar su propio dominio)
  • FQDN de los Servicios Web: pool.dominio.com (las capturas son del dominio ucomsenespanol.com, pero cada uno debe especificar su propio dominio)
Cada uno de vosotros debéis configurar los nombres que tengáis especificados en vuestra topología, por supuesto estos FQDN deben estar creados en los servidores DNS externos como registros DNS de tipo A o CNAME
 TMG_Publicacion_63.pngTMG_Publicacion_65.png
Otra parte muy importante que debemos tener en cuenta que es la Ruta, por defecto dejaremos que se pueda acceder a cualquier directorio del Sitio Web Externo de los servicios web de Lync. Y por último debemos configuar a que puertos enviaremos las conexiones que recibamos sobre esta regla, recodarmos que el Sitio Web Externo  de los servicios Web de Lync utlizan los puertos 4443 para SSL y el 8080 para HTTP. Claramente recomiendo únicamente utilizar SSL, por lo que aquí le indicamos que la conexión se enviará al servidor de destino previamente especificado al puerto 4443. De esta forma, enviaremos las conexiones al sitio web correcto.
TMG_Publicacion_64.png TMG_Publicacion_62.png
Por último podemos pulsar en Test Rule y verificar que todo funciona correcatmente. Logicamente para estar seguros al 100% de que todo está correcto, debemos probar a acceder alguno de los distintos servicios publicados
TMG_Publicacion_61.png
  • Office Web Apps (WAC)
TMG_Publicacion_66.pngTMG_Publicacion_67.png
 TMG_Publicacion_68.pngTMG_Publicacion_69.png
TMG_Publicacion_70.pngTMG_Publicacion_87.png
Con esta configuración cuando tratásemos de publicar alguna presentación de PowerPoint obtendríamos el siguiente error:
TMG_Publicacion_122.png
Y si vamos al registro de TMG vemos el siguiente error e información que nos ayudará a solventar el problema
TMG_Publicacion_79.png
Para solventar este problema, debemos realizar la siguiente configuración adicional desde la regla de publicación del WAC
TMG_Publicacion_76.png
desmarcamos las dos casillas que muestro en verde (con la primera debería ser suficiente)
 TMG_Publicacion_77.png
y ahora si tendríamos acceso a ver el contenido de las presenteaciones de PowerPoint publicadas en Lync
TMG_Publicacion_123.png
  • Servicios Web de Exchange (EWS)
TMG_Publicacion_18.png
TMG_Publicacion_19.pngTMG_Publicacion_20.png
TMG_Publicacion_21.pngTMG_Publicacion_22.png
TMG_Publicacion_24.pngTMG_Publicacion_25.png
TMG_Publicacion_26.pngTMG_Publicacion_27.png
TMG_Publicacion_28.pngTMG_Publicacion_30.png
Una vez configurada nuestra regla de publicación, debemos realizar ciertos ajustes adicionales que os expongo a continuación. Para que todo funcione adecuadamente, debéis tener el Exchange correctamente configurado, DNS Internos y Externos, etc… en la guía de Lync que había publicado en su momento tenéis toda la información al detalle (Guía de Implementación de Lync 2013 Standard en Español)
TMG_Publicacion_31.pngTMG_Publicacion_32.png
TMG_Publicacion_33.pngTMG_Publicacion_34.png
TMG_Publicacion_35.pngTMG_Publicacion_36.png
TMG_Publicacion_37.pngTMG_Publicacion_38.png
En la primera configuración hemos elegido una configuración diferentes, pero lo suyo es autenticación básica (no por Exchange sino por lo que va a necesitar Lync de este servicio)
 TMG_Publicacion_40.pngTMG_Publicacion_42.png
TMG_Publicacion_43.png TMG_Publicacion_44.png
Ahora ya tenemos todos los servicios web publicados de Lync, Exchange y Office Web App para tener nuestra implementación completamente operativa. Como podéis apreciar, la necesidad de un reverse-proxy es vital, puesto que necesitamos poder leer los encabezados de host (Los encabezados host (que también se conocen como nombres de dominio o nombres de host) permiten asignar varios sitios a una sola dirección IP en un servidor web) de las peticiones que nos llegan para enviarlas posteriormente a los servidores internos. Además, también debe poder escuchar por un puerto (443) y enviarlo al servicio de Lync por ejemplo en otro diferente (443). Además, debemos tener muy en  cuenta la delegación de la autenticación, etc.. En mi caso las pruebas se han completado con solo listener en HTTPS y su certificado wildcard correspondiente (Certificados SAN o Wildcard para nuestra implementación de Lync Server).
Luego cada uno tendrá que adptar las distintas configuraciones que sean necesarias en su organizacion:
  • Autenticación
  • Nombres de Dominio
  • Direccionamiento IP
  • Certificados
Publicar los distintos puertos se puede hacer directamente desde vuetro firewall, pero sino es capaz de leer los encabezados de host solo podréis enviar una petición HTTPS a un servidor, porque un puerto y una misma IP solo se puede publicar hacia un único servidor. Aquí hemos visto que accediendo al encabezado de host podemos distinguir a que servidor queremos enviarle la petición y a que puerto en interno, autenticación, etc… esto con un router o firewall al uso no es posible.  Y además, el reverse-proxy debe ser capaz de enviar el encabezado de host que ha recibido al servidor web correspondiente, de tal forma que el servicio web del servidor de destino sea capaz de presentarnos el servicio demandando. Esto con un router o firewall al uso sería imposible, ellos reciben una petición en el puerto xxx y la dejará pasar o no (según tu configuración) al servidor de destino especificado, pero sin más información adicional.
Lo he comentado anteriormente, pero por si no he sido claro, con la configuración del TMG para la publicación de los servicios web de Lync que os he mostrado, ya tendriamos todo publicado, incluso el acceso para la conexión del cliente móvil: (Lync 2013: Publicar los Servicios de Lync Mobile)
Proxy_Inverso_Lync_2013_2.jpg
Que la necesidad de un reverse-proxy y aquí bien claro lo deja Microsoft (http://technet.microsoft.com/es-es/library/gg398069.aspx)
Proxy_Inverso_Lync_2013_3.jpg
Por último comentarios, que sí bien Microsoft no nos obliga a adquirir ninguna solución de reverse-proxy si he visto los que nos recomienda
Proxy_Inverso_Lync_2013_4.jpg
En próximos articulos trataré de probar (que aún no lo he hecho) el IIS ARR y publicaré las experiencias con esta solución
Espero que os se de utilidad!!!

Lync Server: Equilibrio de carga de DNS

agosto 28th, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

​Lync Server soporta la configuración de equilibrio de carga vía DNS para el tráfico SIP y de Medios, pero para los servicios HTTPs debemos implementar alguna de las soluciones de hardware existentes en el mercado. Podemos utilizar el equilibrio de carga vía DNS para los Director, Front-End, Mediation Server y Edge (con excepciones) para para el tráfico SIP y Media, para los servicios web (HTTP/(S)) debemos adquirir un balanceador vía hardware. Voy a tratar de comentar un poco cuales son los pasos a seguir para montar un sistema de balanceo vía DNS, para ello he creado este pequeño esquema que espero que os ayude a haceros una composición de lugar:

  • Pool de Servidores Front-END
  • Pool de Servidores Director
  • Pool de Servidores de Mediación
  • Pool de Servidores EDGE
  • Dos conexiones de Internet con un Firewall para cada conexión, en alta disponibilidad,  y cada Firewall tienen un pool de 4 IPs públicas
(pulsar en la imagen para ver el esquema a tamaño real)
DNS_Lync_Alta_Disponibilidad.jpgVeamos cuales son las configuraciones a llevar a cabo en cada caso:
  • Pool de Front-END y/o Directores

Debemos tener dos FQDN, uno que se corresponde con el nombre del pool y otro con los servicios web. Debemos crear el FQDN del pool con la IP de cada uno de los servidores del pool, en el ejemplo del esquema serían de la siguiente forma:

Registro DNS Tipo A para el FQDN pool.dominio.com con las IPs de los servidores del pool: 192.168.0.10 y 192.168.0.11
Registro DNS Tipo A para el FQDN del servicio Web lync. Dominio apuntando a la IP virtual del grupo de servidores. Aquí debemos tener en cuenta que debemos activar la casilla Reemplazar FQDN interno del grupo de servidores de servicios web internos  y debemos escribir las URL para los servicios web
1097426_647741715243764_108478754_n.jpg
Debemos tener en cuenta que si tenemos más de un pool de servidores Front-END o Directores, debemos tener nombres diferentes tanto para los pool como para los servicios web. El balanceo vía DNS solo es efectivo para el tráfico SIP y de media, para el tráfico web debemos configurar balanceadores vía hardware. Debemos crear el registro para el FQDN de los servicios Web con la IP del balanceador:
Servidores Front-END:
  • Registro DNS Tipo A para el FQDN meet.dominio.com con las IPs de los servidores del pool: 192.168.0.16
  • Registro DNS Tipo A para el FQDN dialin.dominio.com con las IPs de los servidores del pool: 192.168.0.16
  • Registro DNS Tipo A para el FQDN lyncdiscoverinternal.dominio.com con las IPs de los servidores del pool: 192.168.0.16
  • Registro DNS Tipo A para el FQDN lync.dominio.com con las IPs de los servidores del pool: 192.168.0.16
Servidores Directores (publicación mediante reverse-proxy):
  • Registro DNS Tipo A para el FQDN meet.dominio.com con las IPs de los servidores del pool: 192.168.0.17
  • Registro DNS Tipo A para el FQDN dialin.dominio.com con las IPs de los servidores del pool: 192.168.0.17
  • Registro DNS Tipo A para el FQDN lync.dominio.com con las IPs de los servidores del pool: 192.168.0.17
  • Registro DNS Tipo A para el FQDN lync.dominio.com con las IPs de los servidores del pool: 192.168.0.17
Las peticiones provienen de internet  y se publican mediante un reverse-proxy hacia el balanceador hardware que luego distribuirá la peticiones hacia los Directores
  • Servidores de Mediación
Debemos crear un registro DNS con el nombre del grupo de servidores y con cada IP de cada servidor de mediación.
Registro DNS Tipo A para el FQDN poolms.dominio.com con las IPs de los servidores del pool: 192.168.0.12 y 192.168.0.13
  • Servidores EDGE
El rol del EDGE es algo más particular, porque no podemos utilizar el balanceo de carga vía DNS en los siguientes escenarios:
  • Federación con organizaciones que ejecutan versiones de Office Communications Server anteriores a Lync Server 2010.
  • Intercambio de mensajes instantáneos con usuarios de servicios de mensajería instantánea (MI) pública, como Windows Live, AOL y Yahoo!, además de servidores y proveedores basados en XMPP, como Google Talk.
Esto funcionará adecuadamente si todos los servidores EDGE del pool están funcionando correctamente, pero si uno de ellos no está funcionando todas las solicitudes hacia ese servidor no serán enviadas a otro servidor del pool. Esto es un problema y muy importante a tener en cuenta, para que esto funcione de forma adecuada debemos implementar un balanceador de hardware. He creado el siguiente esquema de como podríamos implementar un sistema de balanceo vía DNS para toda la infraestructura a excepción de los servidores EDGE que utilizarán balanceadores hardware para las conexiones internas y externas:

(pulsar en la imagen para ver el esquema a tamaño real)

DNS_Lync_Alta_Disponibilidad_EDGE.jpgSi aún con estos condicionantes debemos configurar el balanceo vía DNS debemos configurar los siguientes registros DNS internos y externos:
  • Registros Internos
Registro DNS Tipo A para el FQDN edge.dominio.com con las IPs de los servidores del pool: 192.168.10.3 y 192.168.10.4
  • Registros Externos (las direcciones IP Públicas son inventadas)
Registro DNS Tipo A para el servicio de acceso (sip.dominio.com) con las IPs de dos conexiones a internet diferentes (alta disponibilidad a nivel de las conexiones de datos)
  • Conexión 1: 222.222.222.1
  • Conexión 2: 222.222.222.4
Registro DNS Tipo A para el servicio de A/V (av.dominio.com) con las IPs de dos conexiones a internet diferentes (alta disponibilidad a nivel de las conexiones de datos)
  • Conexión 1: 222.222.222.2
  • Conexión 2: 222.222.222.5
Registro DNS Tipo A para el servicio de conferencia (webconf.dominio.com) con las IPs de dos conexiones a internet diferentes (alta disponibilidad a nivel de las conexiones de datos)
  • Conexión 1: 222.222.222.3
  • Conexión 2: 222.222.222.6
Otra cosa que debemos tener en cuenta si utilizamos el balanceo de cargar vía DNS es el problema con la mensajería instantánea de Exchange con los usuarios remotos:
  • Reproducir el correo de voz de Enterprise Voice en el teléfono
  • Transferir llamadas de un operador automático de la mensajería unificada de Exchange

El resto de servicios de la mensajería unificada funcionarán sin problema, pero es algo a tener en cuenta. Y por último debemos implementar el mismos sistema de balanceo de carga para las interfaces externas e internas, o utilizamos DNS o balanceadores vía hardware.

Si bien, ahora queremos implementar el balanceo vía hardware, los FQDN con las IPs externas quedarían exactamente igual pero el FQDN e IP del registro interno deberá apuntar a la VIP (Virtual IP) del balanceador:
Registro DNS Tipo A para el FQDN edge.dominio.com con las IPs de los servidores del pool: 192.16810.1
Otra es que las conexiones desde el exterior pasarían por los firewall perimetrales y se enviarían directamente al balanceador (y no a los EDGE directamente) a cada una de las VIP (Virutal IP) para cada servicio que enviará a los EDGE de forma balanceada:
  • Servicio de Acceso: 192.168.15.1
  • Servicio de A/V: 192.168.15.2
  • Servicio de Conferencia: 192.168.15.3
DNS_Lync_Alta_Disponibilidad_EDGE-1.jpg
Ahora por parte del cliente Lync, tanto en la versión 2010 como 2013 utilizarán el balanceo de carga vía DNS sin problema. Como sabéis cuando un cliente se conecta a un grupo de servidores Front-END, lo primero es realizar una consulta al DNS para saber que servidor están configurados, si no consigue conectarse con uno de los servidores tratará de conectarse con alguno de los otros servidores del grupo. Los clientes anteriores a 2010, utilizarán al balanceo de carga vía DNS, pero si no le conecta el primer servidor al que se intenta conectar, no tratará de conectarse a otro servidor del grupo.
Este mismo proceso se consigue cuando es un usuario externo, aquí os muestro un resumen de las consultas DNS que debe realizar para iniciar sesión y utilizar los distintos servicios (Acceso, A/V, Conferencia Web):
DNS_Lync_Alta_Disponibilidad_DNS.jpg
Por último y por aclarar que el balanceo de carga podemos utilizarlo para el tráfico SIP y de Medios, pero para los servicios web (Front-END o Director) debemos utilizar un balanceador vía hardware. Si queremos implementar balanceo de carga a nivel de EDGE, igualmente debemos utilizar balanceadores hardware para mantener siempre la disponibilidad en caso de algún fallo en alguno de los servidores EDGE.

Espero que os sea de utilidad!!!

Lync Server para profesionales de TI

agosto 27th, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

​​Web de recursos y formación para profesionales de IT para Lync Server y Lync Services ….

LyncServer_para_profesionales_de_IT.pngEspero que ose sean de utilidad!!!