Microsoft Lync Server

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)

Como ya sabemos los servicios Web de nuestro Front-END tenemos dos sitios web, uno para los servicios internos y otro los externos.

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

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

escribiremos el nombre de nuestro servidor de Front-END, el nombre del Pool de servidores Front-END o el FQDN del servidor de Director

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)

Importante, debemos elegir la opción No delegación, pero los usuarios podrían autenticar directamente

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

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.

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

Office Web Apps (WAC)

Con esta configuración cuando tratásemos de publicar alguna presentación de PowerPoint obtendríamos el siguiente error:

Y si vamos al registro de TMG vemos el siguiente error e información que nos ayudará a solventar el problema

Para solventar este problema, debemos realizar la siguiente configuración adicional desde la regla de publicación del WAC

desmarcamos las dos casillas que muestro en verde (con la primera debería ser suficiente)

y ahora si tendríamos acceso a ver el contenido de las presenteaciones de PowerPoint publicadas en Lync

Servicios Web de Exchange (EWS)

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)

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)

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)

Que la necesidad de un reverse-proxy y aquí bien claro lo deja Microsoft (http://technet.microsoft.com/es-es/library/gg398069.aspx)

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

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)

Veamos 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

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)

Si 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

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):

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

DNS

Microsoft ha pasado a versión RTM a Windows Server 2012 R2 y Windows 8.1

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

Microsoft ha dado por finalizado el desarrollo de Windows Server 2012, puesto que ya es RTM como anuncian en el blog oficial:

Today is the RTM for Windows Server 2012 R2!

As noted in my earlier post about the availability dates for the 2012 R2 wave, we are counting the days until our partners and customers can start using these products. Today I am proud to announce a big milestone: Windows Server 2012 R2 has been released to manufacturing!

This means that we are handing the software over to our hardware partners for them to complete their final system validations; this is the final step before putting the next generation of Windows Server in your hands.

While every release milestone provides ample reason to celebrate (and trust me, there’s going to be a party here in Redmond), we are all particularly excited this time around because we’ve delivered so much in such a short amount of time. The amazing new features in this release cover virtualization, storage, networking, management, access, information protection, and much more.

By any measure, this is a lot more than just one year’s worth of innovation since the release of Windows Server 2012!

As many readers have noticed, this release is being handled a bit differently than in years past. With previous releases, shortly after the RTM Microsoft provided access to software through our MSDN and TechNet subscriptions. Because this release was built and delivered at a much faster pace than past products, and because we want to ensure that you get the very highest quality product, we made the decision to complete the final validation phases prior to distributing the release. It is enormously important to all of us here that you have the best possible experience using R2 to build your private and hybrid cloud infrastructure.

We are all incredibly proud of this release and, on behalf of the Windows Server engineering team, we are honored to share this release with you. The opportunity to deliver such a wide range of powerful, interoperable R2 products is a powerful example of the Common Engineering Criteria that I’ve written about before.

Also of note: The next update to Windows Intune will be available at the time of GA, and we are also on track to deliver System Center 2012 R2.

Thank you to everyone who provided feedback during the preview process – we could not have done it without you!

I can’t wait to share even more on October 18! In the meantime, keep an eye on this blog and Twitter for updates.

Readying Windows 8.1 for release

We’ve hit an important milestone for Windows and for Microsoft—just 10 months after delivering on a bold, generational change in computing with Windows 8, our team is proud to share that we have started releasing Windows 8.1 and Windows RT 8.1 to our hardware partners. In many ways, this marks a new day at Microsoft, reflecting a number of rapid release firsts. Thanks, in part, to customer feedback and an unparalleled level of collaboration across product teams, Windows 8.1 is a significant update. We have delivered in a very short time an update to the OS that will bring an even greater unified experience for our customers. As we consider the code we just handed off, and the new intuitive and fluid computing experience it provides – anytime, anywhere, across all devices – we’re confident we made the right bet in continuing our visionand following through on our commitment to rapid innovation and responsive engineering.

In the past, the release to manufacturing (RTM) milestone traditionally meant that the software was ready for broader customer use. However, it’s clear that times have changed, with shifts to greater mobility and touch as well as the blurring of work and personal lives. As such, we’ve had to evolve the way we develop and the time in which we deliver to meet customers with the experience they need, want and expect. We’ve had to work closer to our hardware partners than ever before. Reaching this milestone is about optimizing the overall experience for our customers. Our hardware partners are in a position to prepare the wide array of innovative devices our customers can expect later this fall – just in time for the holidays. Over the next several months we’ll see beautiful, powerful devices, from the smallest tablets to the most lightweight notebooks to versatile 2-in-1s, as well as industry devicesdesigned for business.

While our partners are preparing these exciting new devices we will continue to work closely with them as we put the finishing touches on Windows 8.1 to ensure a quality experience at general availability on October 18th. This is the date when Windows 8.1 will be broadly available for commercial customers with or without volume licensing agreements, our broad partner ecosystem, subscribers to MSDN and TechNet, as well as consumers.

On behalf of the Windows engineering team, we want to thank you for joining us on this journey. So many people rely on Windows in so many ways, and so we thank you for your participation in previewing the product, for your feedback, for your contributions and for your support. You have helped us make Windows 8.1 great for everyone!

We are super excited to see Windows 8.1 help deliver the next generation of devices and a one-of-a-kind experience that’s in sync with the way you live – at home, at work, and on the go.

Ahora toca esperar un poquito pero no creo que falte mucho tiempo para tenerlo disponible en MSDN!!!

Windows 8.1, windows server 2012