Microsoft Lync Server
Header

Publicar los servicios web de Lync con Web Application Proxy en Windows Server Technical Preview

marzo 11th, 2015 | Posted by Santiago Buitrago in Lync Server | Seguridad | Windows Server - (0 Comments)

Cómo ya he comentado en otras ocasiones, para publicar los distintos servicios Web de Lync debemos utilizar un Proxy​ Inverso o Reverse-Proxy, para ello he publicado distintos artículos sobre IIS ARR y TMG:

Pues ahora tocaba hacerlo con Web Application Proxy, un nuevo servicio disponible desde Windows Server 2012 que viene disponible con el Rol de Acceso Remoto. En este caso voy a mostraros como configurarlo pero ya con la versión de Windows Server Technical Preview. Para ello debemos configurar el servicio de federación (AD FS) en uno de los servidores internos de la red, y además configurar el servidor que hará de Proxy Inverso como un AD-FS Proxy. Necesitamos AD-FS para almacenar la configuración del Web Application Proxy y para la configuración de la autorización. Aquí os dejo como casi siempre un esquema de red en donde tenemos los elementos necesarios para configurar este servicio, además os he puesto a la derecha varias opciones de donde podemos situar el Proxy Inverso en nuestra red:

Web Application Proxy - Lync -1.jpg

Para configurar Web Applicatio Proxy debemos hacerlo en varias fases que veremos a continuación y son las siguientes:

  • Configuración AD FS en un servidor unido al dominio
  • Configuración de AD FS Proxy en el servidor que será nuestro proxy inverso con Web Application Proxy

Los requisitos para esta configuración son los siguientes:

  • Servidor unido a un dominio (o un controlador de dominio, pero no sería lo más idóneo)
  • Una entidad certificadora, puesto que no necesitamos certificados públicos para la configuración de AD FS puesto que será interno
  • Un servidor que no esté en el dominio en donde agregaremos el rol de Acceso remoto en donde se configurará el Web Application Proxy y el servicio de Federación.

Como la configuración del Web Application Proxy se almacenará vía AD FS, será lo primero que tenemos que hacer. Para ello utilizaremos un servidor con Windows Server 2012 R2 y agregaremos el rol de AD FS, por lo que desde el Administrador del servidor pulsamos en Administrar – Agregar Roles y pulsamos en Siguiente

ADFS_WebProxy_Win10_1.png

Seleccionamos  Instalacikón basada en características o en roles y pulsamos en SiguienteADFS_WebProxy_Win10_2.png

Selecionamos el servidor sobre el cual queremos realizar la configuración de un nuevo rol y pulsamos en SiguienteADFS_WebProxy_Win10_3.png

Ahora debemos seleccionar Serviciosde federación de Active Directory y pulsamos en SiguienteADFS_WebProxy_Win10_4.png
Si seleccionar nada, pulsamos en Siguiente

ADFS_WebProxy_Win10_5.png
Pulsamos en Siguiente
ADFS_WebProxy_Win10_6.png

Para iniciar el proceso de instalación, pulsamos en Instalar
ADFS_WebProxy_Win10_7.png

Una vez que finalice la instalación del rol de Federación, debemos iniciar el asistente de configuración, para ello pulsamos en Configure el servicio de federación en este servidor
ADFS_WebProxy_Win10_8.png
Como es nuestro primer servidor de federación, seleccionaremos Crear el primer servidor de federación de una granja de servidores de federación y pulsamos en Siguiente
ADFS_WebProxy_Win10_9.png
Seleccionamos una cuenta con permisos de administrador de dominio y pulsamos en SiguienteADFS_WebProxy_Win10_10.png

Previo a este paso, debemos tener instalado en el servidor un certificado para poder utilizarlo en el servicio de federación, este certificado puede ser privado puesto que únicamente (en este artículo) será utilizado para conectarse el Web Application Proxy. Aquí os dejo un artículo como configurar una CA en Windows Server 2012:  Windows Server 2012, Instalación de una CA

Una vez que ya tenemos nuestro certificado, únicamente debemos seleccionarlo (o importarlo en este momento), escribir un nombre para el servicio de federación (debéis crear el registro DNS correspondiente) y escribir un nombre para este servicio.
ADFS_WebProxy_Win10_11.png

Ahora debemos especificar una cuenta de dominio (sin privilegios) como cuenta de servicio, si queréis ampliar información sobre la cuenta de servicio aquís tenéis un KB de MSFT https://technet.microsoft.com/en-us/library/hh831782.aspx. Una vez que hemos creado la cuenta y la hemos configurado, pulsamos en Siguiente
ADFS_WebProxy_Win10_13.png
Debemos crear una base de datos para la configuración, bien podemos crearla usando Windows Internal Database o utilizando un servidor de SQL. En este caso utilizaremos la opción de Crear una base de datos en este servidor que usa Windows Internal Database
ADFS_WebProxy_Win10_14.png

Por último, nos muestra un resumen de la configuración que vamos a realizar a través del asistente, si todo está correcto, pulsamos en Siguiente
ADFS_WebProxy_Win10_15.png
Se comprueban los requisitos del sistema para verificar que nuestro servidor cumple con todos ellos, si es así  pulsamos en Configurar para iniciar el proceso
ADFS_WebProxy_Win10_16.png
Una vez que se ha completado el proceso de instalación, nos los mostrará con la siguiente pantalla, para cerrar esta ventana pulsamos en Cerrar
ADFS_WebProxy_Win10_17.png
Ahora lo  único que nos queda es probar que el servicio funciona correctamente, para ello accedemos a la siguiente URL: https://adfs.asirlab.com/adfs/ls/IdpInitiatedSignon.aspx y pulsamos en Iniciar sesión
ADFS_WebProxy_Win10_19.png
Nos solicitará credenciales y se las especificamos para comprobar que funciona correctamenteADFS_WebProxy_Win10_20.png
Si todo ha salido bien, veremos una pantalla similar a esta. Ahora sí que damos por finalizada la configuración de AD FS que necesitamos para almacenar la configuración del AD FS Proxy que será el servidor que tiene el rol de Proxy Inverso (Web Application Proxy)

ADFS_WebProxy_Win10_21.png
Hasta ahora hemos completado la primera parte de la configuración que necesita nuestro Proxy Inverso, por lo que ahora debemos realizar las distintas configuraciones en el propio servidor que hará de proxy. Antes comentaros que el debería tener la siguiente configuración:

  • Dos tarjetas de Red con una subred IP diferente en cada interface
  • Sólo configurar la puerta de enlace y servidores DNS públicos (8.8.8.8 u otro público) en la interface que tengamos como externa
  • Si tenemos una DMZ o distintas VLAN internas, debemos configurar las rutas estáticas necesarias  para que desde la interface interna podamos tener conexión con las redes privadas en donde tenemos los servidores que vamos a publicar y el acceso al servicio de AD FS
  • Un certificado para configurarlo en las reglas de publicación del Proxy Inverso
  • Un certificado (o el mismo que el de la publicación de servicios si procede) para el servicio de Federación
  • Modificar el fichero HOSTS del equipo para que pueda resolver los distintos nombres de los servidores que vamos a publicar o que necesitemos tener acceso (AD FS)
  • El FQDN del servidor debería ser con el sufijo del dominio interno que tenemos

Una vez dicho esto, vayamos paso a paso configurando todo lo necesario para configurar el rol de Acceso Remoto y preparar la configuración del Web Application Proxy. Para ello, una vez configuradas la tarjetas de red del servidor, establezcamos el FQDN del servidor y modifiquemos el fichero HOSTS del servidor:

WebProxy_Win10_1.png

Editamos el fichero HOSTS, aquí solo he puesto el los del servidor de Lync, pero habría que poner el nombre del servicio de AD FS que hemos configurado previamente y también nos haría falta la URL de los servicios de nuestro WAC y Exchange si lo tenemos en On-Premises. Aquí no los he puesto porque me he centrado únicamente en Lync
WebProxy_Win10_0.png
Ahora que ya tenemos los requisitos previos realizados, iniciaremos el proceso de configuración del ROL de Acceso Remoto. Comentaros, que yo estoy utilizando un Windows Server Technical Preview, pero en la versión de Windows 2012 es muy similar su configuración. Dicho esto, nos vamos a la consola de administración del servidor y agregamos el rol de Acceso Remoto:
WebProxy_Win10_2.png
Seleccionamos Role-Based or feature-based installation y pulsamos en Next
WebProxy_Win10_3.png
Seleccionamos el servidor sobre el cual vamos a querer agrear el rol de acceso remoto, en este caso es el servidor sobre el cual estamos conectados y pulsamos en Next
WebProxy_Win10_4.png
Seleccionamos el Rol de Remote Access y pulsamos en Next
WebProxy_Win10_5.png
No seleccionaremos nada y pulsamos en Next para continuar con la instalación
WebProxy_Win10_6.png
Pulsamos en Next
WebProxy_Win10_7.png
Ahora debemos seleccionar el servicio que queremos instalar dentro del ROL de Remote Access que previamente hemos seleccionado, por lo que marcamos la casilla de Web Application Proxy
WebProxy_Win10_8.png
Nos muestra los componentes que tiene que agregar adicionalmente al servicio de Web Application Proxy y pulsamos en Add Features
WebProxy_Win10_9.png
ahora ya tenemos todo lo necesario para continuar, para ello pulsamos en Next
WebProxy_Win10_10.png
Nos muestra un resumen de lo que se va a instalar, si estamos de acuerdo pulsamos en Install para iniciar el proceso
WebProxy_Win10_11.png
Una vez que termine la instalación, nos mostrará la siguiente pantalla en donde nos mostrará una opción de configuración del Web Application Proxy para ellos pulsamos en Open the Web Application Proxy Wizard
WebProxy_Win10_12.png
Una vez abierto el asistente de configuración, nos mostrará una pantalla en donde nos indica que debemo configurar inicialmente el servicio de federación, para iniciar el proceso pulsamos en Next
WebProxy_Win10_13.png
Escribiemos el FQDN del servicio de federación que habíamos configurado previamente y las credenciales correspondientes con los permisos de administrador y pulsamos en Next
WebProxy_Win10_14.png
Seleccionaremos el certificado que vamos a utilizar en el AD FS Proxy, recordad que como el servidor no está en el dominio y si utilizáis certificados privados debéis instalar el certificado raíz en el servidor para que no tengáis problemas con el certificado que utilicéis. Como el certificado que he utilzado lo ha emitido mi CA interna, una vez que he importado el certificado también he instalado el certificado raiz en el contenedor de certificados raiz de confianza del propio servidor, de tal forma que vea el certificado como válido. Dicho esto, ya podemos seleccionar el certificado en la pantalla de AD FS Proxy Certificate y pulsamos en Next
8WebProxy_Win10_15.png
 Ahora nos muestra un resumen de los comandos de powershell que se ejecutarán en base a la configuración que hemos ido realizando a través del asistente y pulsamos en Configure  para continuar

WebProxy_Win10_15.png
Si tanto la URL, como las credenciales y el certificado presentado están correctos, nos mostrará la siguiente pantalla indicándonos que se ha completado de forma correcta.
WebProxy_Win10_17.png
Ahora lo único que nos queda es crear las reglas de publicación necesarias para nuestro Lync, para ello pulsamos en Publish
WebProxy_Win10_18.png
Pulsamos en Next
WebProxy_Win10_19.png
Cómo para los servicios de Lync no utilizamos preautenticación, seleccionamos Pass-through y pulsamos en Next
WebProxy_Win10_20.png
Debemos cubrir los siguientes campos disponibles en la publicación del servicio:

  • Nombre: Será el nombre descriptivo que tendrá la regla de publicación
  • External URL: Dirección web del servicio que vamos publicar, en este caso voy a publicarlos servicios web externos de Lync y este es el FQDN que había establecido en la topología de Lync (lync.asirlab.com)
  • External Certificate: Es el certificado que vamos a presentar a los usuarios externos cuando se conecten a los distintos servicios de Lync
  • Backend serve URL: Dirección web del servidor que vamos a publicar, al igual que hacemos con otros proxy debemos especificar la URL y el puerto 4443 que se corresponde con el sitio web externo que tenemos en nuestros front-END

Ahora que ya tenemos todos los campos cubiertos, pulsamos en Next
WebProxy_Win10_22.png
Nos muestra un resumen de la configuración que se va a aplicar vía powershell (Add-WebApplicationProxyApplication) y para que se cree la regla de publicación pulsamos en Publish
WebProxy_Win10_23.png

Y por último en Close y ya tenemos nuestra primera regla de publicación de los servicios web de Lync
WebProxy_Win10_24.png
Y aqui tenemos nuestra primera de Lync en el Web Application Proxy, ahora tendremos que hacer todas las necearias como por ejemplo:

  • meet.asirlab.com (Reuniones en línea)
  • dialin.asirlab.com (Conferencias Telefónicas)
  • lyncdiscover.asirlab.com (Cliente Lync Móvil)
  • office.asirlab.com (Office Web App)
  • mail.asirlab.com (EWS de Exchange)

WebProxy_Win10_26.png
Por mostraros una diferente a Lync, aquí tenéis la regla de publicación del Office Web, en mi caso he puesto la dirección externa y el servidor interno siempre con la misma URL pero puede ser diferente sin problema alguno.
WebProxy_Win10_27.png

Claramente lo que nos quedaba por haacer es probar que podíamos conectarnos, por lo que tratamos de conectarmos por ejemplo a la URL de las reuniones en línea y vemos que funciona perfectamente.
WebProxy_Win10_32.png
Algo que debemos hacer es configurar el tiempo de desconexión de las conexiones que pasan por el Proxy, como por ejemplo el cliente Lync Móvil. Si recordáis había pulicado este articulo sobre las desconexiones del cliente Lync móvil através del IIS ARR (Cliente Lync Móvil 2013: La información del servidor ha cambiado. Reinicia Lync). Por defecto MSFT recomendaba poner un valor de 200 segundos Your_server_configuration_has_changed_3.jpg
y con este valor los clientes Lync de móvil cuando no tenían la aplicación en primer plano a los 200 segundos se desconectaban y claro eso genera problemas a los usuarios finales que deben reconectar cada poco tiempo. Para esto se configuraban las desconexiones a los 960 segundos, algo más razonable y que permite tener la aplicación en segundo plano iniciada durante un tiempo prudencial:

Your_server_configuration_has_changed_4.jpg

Dicho esto, ahora debemos ver como hacerlo en el Web Application Proxy, para ello debemos hacerlo mediante PowerShell. Lo primero es ver el valor por defecto y luego cambiar si fuese necesario, para ello ejecutamos el siguiente cmdlet: Get-WebApplicationProxyApplication y vemos todas las reglas de publicación. Si ahora ejecutamos Get-WebApplicationProxyApplication -Name Lync | fl nos muestra la configuración de cada publicación y vemos que el valor InactiveTransactionsTimeoutSec está establecido a 300
WebProxy_Win10_28.png
Por lo que debemos cambiarlo a 950 y así ajustarlo de forma adecuada, para ello ejecutamos el siguiente cmdlet: Set-WebApplicationProxyAppliation -ID xxxxxx.xxxxxx.xxxxxx.xxxxxxx -InactiveTransactionsTimeouts 950. El ID de la aplicación lo veis con ejecutando el cmdlet  Get-WebApplicationProxyApplication -Name Lync | fl
WebProxy_Win10_31.png
De esta forma el valor por defecto de desconexión establecido a 300 segundos (más que la recomendación de 200 segundos en el IIS ARR), lo hemos pasado a 950.
 
Por último comentaros, que si publicáis algún servicio vía HTTP tendréis que permitir la conexión en el Firewall Local de Windows, porque por defecto se ha creado solo una regla para el tráfico HTTPS. Si abrimos la consola avanzada del firewall la regla AD FS HTTPS Services (TCP-in), por lo que permitirá todas las conexiones al puerto 443 de entrada a cualquiera de las interfaces del Proxy.
WebProxy_Win10_34.png
Si creamos una regla para publicar una web vía HTTP, la conexión no funcionará …
WebProxy_Win10_32-1.png
Si vemos las conexiones activas en el servidoa al puerto 80 y el firewall activado vemos que no tenemos ninguna conexión activa
WebProxy_Win10_33.png
Lo que debemos hacer es crear una reglapara el tráfico HTTP de entrada y listo, ya tendremos acceso a los servicios web publicados en el PROXY  através del puerto 80 en TCP
WebProxy_Win10_42.png
Si ahora volvemos a conectarmos al servicio web publicado, ya tendremos acceso al mismo
WebProxy_Win10_43.png
Si nuevamente volvemos a revisar las conexiones activas, vemos que ya las vemos establecidas y con el Firewall activo
WebProxy_Win10_44.png
Por último hacer un breve comentario sobre las tres posibles (hay más, pero como norma general) ubicación del Proxy Inverso en nuestra red, he esquematizado los más habituales:
 
Opción 1: Situaremos el Proxy (fuera del dominio) en una DMZ protegido por dos Firewall corporativos, realizando filtrados a nivel 3 desde todas las zonas de red (Internet, LAN). Esta es la mejor opción posible de las que os expongo, puesto que tenemos distintas barreras de seguridad antes de tener acceso a la red interna, además de que podemos realizar distintos filtrados en distintas zonas de la red. Si fuese posible, que los dos Firewalls fuesen de compañias diferentes, evitando así que si uno  de ellos tuviese alguna vulnerabilidad, no estuviese afectada toda la red. Ni que decir tiene que debemos mantener nuestra infraesctructura de red adecudamente actualizada
WebProxy_Win10_001.png
Opción 2: La más común de todas, tenemos un firewall / Router a nivel de perímetro co un interface LAN con una subred IP diferente a la de la LAN. De esta forma el Proxy se conectará directamente al router (o switch intermedio) con una interface y subred IP y con la otra internface y subred IP a la LAN. Para esto podremos utilizar VLAN o simplemente configurar dos subredes diferentes pero todos compartiendo el mismo medio físico (Switch). Si es así no es lo más recomendable aun para este escenario  lo suyo sería una VLAN para poner las interfaces LAN del Router y WAN del Proxy, y otra VLAN en el switch para configurarlo para la red local e interface LAN del Proxy.
WebProxy_Win10_002.png

Opción 3: Menos común y la peor opción, es tener el proxy con dos interfaces en la misma subred, no tiene ni sentido tenerlo así. El proxy también puede funcionar con una sola IP, por lo que es lo mismo que tener dos interfaces con la misma subred. Es común en las empresas pequeñas tener este esquema, porque tienen un router y una interface LAN que está en la misma subred IP que la red interna para que los equipos se puedan conectar a internet. Pero si bien es cierto que con este escenario no tenemos una capa de seguridad a nivel de filtrado IP, puesto que si un atacante compromenten el Proxy, por lo menos a nivel IP ya se encuentra en la misma subred. Esto facilitará al atacanque descrubrir distintos servicios de la red local, los equipos, etc… si estuviese en otra subred IP se podrían aplicar de forma "más efectiva" distintos filtrados, porque realmente el Proxy Inverso solo necesita comunicarse con los equipos de la red coporativa que van publicar sus servicios a internet (para más cosas, pero vamos por se escueto)

WebProxy_Win10_003.png

Y ya dicho esto, ahora que cada uno tome las decisiones que crea oportunas para situar su Proxy Inverso en su red, el riesgos que quiera asumir cada uno ya …

Como veis un Proxy Inverso no es un servicio muy complicado de configurar, únicamente debemos cumplir  todos los requisitos y tener claros los conceptos de publicación, DNS, certificados, etc… pero hay que tenerlo claro :-).
 

Os dejo algunos artículos que os podrían ser de interés con respecto al Proxy Inverso para una topología de Lync:

Espero que os sea de utilidad!!!

Actualización para el cliente Lync 2013 (KB2920744)

marzo 11th, 2015 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

MSFT ha liberado nuevas actualizaciones del cliente Lync 2013, aquí tenéis los problemas que se corrigen:

Lync_2013_15.0.4693.1000.PNG

Additionally, this update resolves the Lync 2013 issues that are described in the following Microsoft Knowledge Base articles:

Y aquí tenéis los enlaces de descarga correspondientes

 

Servidores RODC y Lync Server 2013 (Parte I)

marzo 11th, 2015 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Muchas empresas tienen múltiples sedes en su ámbito  nacional/ internacional, en donde además se va extendiendo los distintos servicios a dichas ubicaciones. Un escenario comun suele ser tener un CPD principial (más ancho banda, capacidad de proceso, seguridad, etc…) en donde se configuran distintos servidores y servicios (Active Directory, RDS, DirectAccess, Exchange, SharePoint, CRM, ERP, …). Y según la empresa se va expandiendo por el mundo, lo que queremos es extender estos servicios al resto de sedes, un claro ejemplo es nuestro Directorio Activo. Por lo que en las ubicaciones remotas conectadas vía VPN (Cisco VPN IPSec Site-to-Site con Certificados Digitales), MPLS, etc.. con el CPD central, podríamos instalar uno o varios servidores con una réplica del nuestro Directorio Activo (Controlador de Dominio Adicional) en donde tendremos además más servicios de infraestructura para la red local (DHCP, DNS, NPS, etc..). Pero no siempre en las sedes remotas se consigue unos niveles de seguridad física aceptable, por lo que debemos ser capaces de proteger sobre todo a estos servidores que pueden estar expuestos a ataques o malas prácticas de uso sin "nadie se entere". De ahí que MSFT había recuperado el antigudo "BDC" de NT4 que ahora es un RODC (Read Only Domain Controller https://technet.microsoft.com/es-es/library/cc753223(v=ws.10).aspx), que no es más que un controlador de dominio pero de solo lectura. Vamos, que los administradores con derechos administrativos sobre el mismo no puede hacer cambio alguno en el dominio, simplemente recibe una copia del AD del resto de servidores pero no puede realizar modificación alguna. Es algo más que todo esto, pero creo como resumen rápido espero que se haya entendido. Muchas aplicaciones ya están preparadas para trabajar con este tipo de servidores, entre ellas Lync Server 2013 (Lync Server 2013 supports Active Directory Domain Services deployments that include read-only domain controllers or read-only global catalog servers, as long as there are writable domain controllers available. aunque desde luego con este comentario de MSFT no me queda nada claro que puedo hacer con un servidor de Lync Server en una sede con un RDOC. Aunque si bien es cierto que no encuentro muchas excusas para tener juntos una Front-END de Lync Server 2013 y un RODC, algunas existen, comor por ejemplo  una sede en otro continente y en donde la conexión entre dicha sede y el CPD no es de los más fiable, además de que queremos dotar a autosuficiencia a esta sede en caso de algún corte de conexión ocasional:

Lync con RODC.jpg
Dividiré el artículo en dos partes:
  • Parte I: Instalación de un RDOC
  • Parte II: Comportamiento de Lync con un RODC
La idea es ver que comportamiento tiene Lync Server y los clientes Lync, cuando el RODC de nuestra sede no tiene contacto con los controladores de dominio de la sede central. Dicho esto, vamos centrarnos en la instalación de un RODC, partiendo de la base de que ya tenenos nuestro dominio creado y únicamente queremos instalar un RDOC para unirlo a nuestro dominio con controlador de dominio de solo lectura en la Sede B. En la Sede A tenemos todos los controladores de dominio, servidores de SQL Server, SharePoint, Servidores de Ficheros, etc… y en la Sede B tenemos un RODC, Lync Server 2013, Exchange Server 2013, Office Web App 2013 (para Lync y Exchange), Servidor de Ficheros (replicación vía DFS-R). Este escenario para mi es irreal, pero creo que es una buena forma de mostrar el comportamiento de Lync en este escenario. Lo suyo sería que todo estuviese en el CPD y en la sede B un RODC, Lync Server (Front-END, Mediation Server, EDGE), Servidor de Ficheros y poco más, vamos, lo justo para dar servicio a una oficina remota que pueda sobrevivir unas horas en modo supervivencia (sin conexión con el CPD). Una vez aclarado la topología "fantasma", veamos como podemos instalar un RODC, yo he elegido provisionar previamente la cuenta en el Directorio Activo para que la gente que no lo haya visto aún pueda ver como se configura.
 
Lo primero que haremos será en alguno de los controladores de dominio abrir la consola de Usuarios  y Equipos de Active Directory, pulsamos con el botón secundario del ratón encima de la OU de Controladores de Dominio y pulsamos en Crear previamente una cuenta de controlador de dominio de solo lectura
Lync Server RODC-1.png
Pulsamos en Usar la instalación en modo avanzado y pulsamos en Siguiente
Lync Server RODC-2.png
Cómo se supone que el usuario con el que hemos iniciado sesión en el controlador de dominio tiene derechos administrativos en el Directorio Activo, seleccionamos Mis credenciales de inicio de sesión actuales y pulsamos en Siguiente
Lync Server RODC-3.png
Escribimos el nombre que le asignaremos posteriormente al RODC y pulsamos en Siguiente
Lync Server RODC-4.pngAhora elegimos el SITE en donde estará este controlador de dominio (ES: 10.10.10.0/24 y UK 10.10.20.0/24), en este caso el RODC estará en UK, lo elegimos y pulsamos en Siguiente
Lync Server RODC-5.png
Nota: Aquí os muestro las subredes asignadas a los sitios, como se supone que si instaláis un RODC es una una ubicación remota, esta configuración ya la deberíais tener hecha antes de empezar la configuración del RODC
Lync Server RODC-6.png
Continuamos con la configuración, este servidor será Catálogo Global, Servidor DNS y por supuesto RODC (eso no lo podéis tocar claramente), para continuar pulsamos en Siguiente
Lync Server RODC-7.png
Ahora nos muestra la configuración de replicación de contraseña para este RODC, por defecto los administradores, Opers. de servidores, etc.. no tienen sus contraseñas cacheadas en este RDOC. Además, tenemos dos grupos predeterminados (Grupo de replicación de contraseña RODC denegada y Grupo de replicación de contraseña RODC permitida) en donde podemos ir agregando usuarios y equipos para que se le permita el almacenar la contraseña en la caché del RODC. Esto nos interesa para las estaciones de trabajo, servidores y usuarios que deben iniciar sesión en la sede remota cuando el enlace de VPN con el CPD esté caido. De momento lo vamos a dejar sin tocar, ya lo configuramos más adelante, por lo que pulsamos en Siguiente
Lync Server RODC-8.png
Especificaremos un usuario que podrá completar la instalación del RODC, esto es  interesante si tenemos algún grupo o usuario que tendrá tareas delegadas en la sede remota para la instalación de este RDOC sin que para ello deba tener más privilegios de los necesarios a nivel de Directorio Activo. En mi caso como es un LAB he elegido la cuenta de administrador, pero es recomendable hacerlo con otra cuenta.

Lync Server RODC-10.png
En esta pantalla se nos muestra un resumen de la configuración que hemos ido realizando en los pasos anteriores, si todo está correcto pulsamos en Siguiente
Lync Server RODC-11.png
Con esto ya hemos finalizado la primera parte de la configuración de un RODC, simplemente pulsamos en Finalizar y veremos que ya tenemos la cuenta de equipo del RODC
Lync Server RODC-12.png
Desde la OU de Domain Controllers podemos observa la cuenta de equipo del RODC pero deshabilitada, por lo que ahora debemos acceder al servidor que hará de RODC y continuar con la configuación.
Lync Server RODC-13.png

Ahora en el servidor SRV-D0C1 que será nuestro RODC debemos primero agregar los roles necesarios, pero lo primero será asegurarse de que está correctamente configurado, para ello abrimos la consola de Administrador del Servidor y vemos que ya tiene el nombre correcto (SRV-DC01) y que está en un grupo de trabajo.

Lync Server RODC-14.png
Iniciamos el asistente que nos permite agregar roles y características y pulsamos en Siguiente
Lync Server RODC-15.png
Seleccionamos Instalación basada en características o en roles y pulsamos en Siguiente
Lync Server RODC-16.png
Elegimos la opción por defecto Seleccionar un servidor del grupo de servidores y pulsamos en Siguiente
Lync Server RODC-17.png
En la sección de roles de servidor elegimos Servicios de dominio de Active Directory y pulsamos en Siguiente
Lync Server RODC-18.png
Aquí no tocamos en nada  y pulsamos en Siguiente
Lync Server RODC-19.png
Pulsamos en Siguiente
Lync Server RODC-20.png
Nos muestra un resumen de los roles que se agregarán y si estamos de acuerdo, pulsamos en Instalar
Lync Server RODC-21.png
Una vez completada la instalación de los distintos roles, nos mostrará una opción de Promover este servidor a controlador de dominio que será lo que haremos, por lo que pulsaremos en ese texto y se iniciará al proceso de promover este servidor a controlador de dominio
Lync Server RODC-22.png
Seleccionamos Agregar un controlador de dominio a un dominio existente, escribimos el nombre del domnio (en mi caso ASIRLAB.COM) y escribimos las credenciales del usuario que habíamos definido en la preparación del RODC
Lync Server RODC-23.png
Pulsamos en Aceptar
Lync Server RODC-26.png
Seleccionamos Usar cuenta RODC existente y ya se establecen el resto de opciones según las configuraciones realizadas anteriormente, además vemos que nos muestra que ya existe la cuenta RODC porque ha comprobado el nombre del servidor que se corresponde con la cuenta creada anteriormente. Establecermos la contraseña de recuperación de los servicios de directorio (DSRM) y pulsamos en Siguiente
Lync Server RODC-25.png
Le indicamos el servidor desde el cual va a replicar por primera vez el Directorio Activo y pulsamos en Siguiente
Lync Server RODC-27.png
Esto es como siempre, nos muestra los directorios en donde se ubicará la BBDD, Registros y carpeta SYSVOL, por lo que únicamente lo dejamos como está si así nos vale y pulsamos en Siguiente
Lync Server RODC-28.png
Nos muestra un resumen de las distintas configuraciones que hemos ido realizando y pulsamos en Siguiente
 Lync Server RODC-29.png
Se realizarán una serie de verificaciones y si todo está correcto, ya podemos iniciar el proceso final de promover este servidor a controlador de dominio, en nuestro caso un RODC para ello pulsamos en Instalar
Lync Server RODC-30.png
Depende de la conexión que tengamos entre ambos servidores le llevará más o menos tiempo la replicación, y bueno la cantidad de objetos, etc.. en este caso como es un LAB no será más de 5 min. Ahora únicamente debemos esperar a que finalice el proceso y el servidor se reiniciará para completar el proceso
Lync Server RODC-31.png
Mientra que reinicia el servidor, ya podemos ver que se ha activado la cuenta del RODC, por lo que el proceso ha finalizado correctamente. Ya tenemos un RODC operativo y en situado en la sede remota de la subred 10.10.20.0/24 (Site UK).
Lync Server RODC-32.png

Ahora lo que podemos probar es si cachea las contraseñas de los usuarios que queramos que así sea, para ello en el grupo de seguridad Grupo de replicación de contraseña RODC permitida añadiremos a los usuarios de la sede de UK que si queremos que cacheen sus contraseñas. Esto permitirá a los usuarios iniciar sesión en el dominio teniendo presente solo al RDOC, esto debemos hacerlo siempre para este tipo de instalaciones sino tendremos problemas  si nos quedamos desconectados de la sede principal y perder el contacto con el DC. bien, Bien una vez quemos añadido a los usuarios o grupos de usuarios al grupo Grupo de replicación de contraseña RODC permitida vamos a verificiar que es así, lo primero que haremos será ir a las propiedades de SRV-DC01 (el RODC) y vamos a la pestaña Directivas de replicación de contraseñas, en mi caso además he creado un grupo a parte para añadir de forma explícita a la gente de UK para permitir que se repliquen las contraseñas de esos usuarios en el RDOC. Ahora pulsamos en el botón Opciones avanzas

Lync Server RODC-38.png
En la pestaña Directiva Resultante podemos comprobar si realmente el usuario que pertenece al grupo que hemos habilitado para replicar las contraseñas se le permite o no la replicación de su contraseña. Para ello simplemente agregamos al usuario o usuarios que queremos testear  desde el botón Agregar y nos mostrará si se le permite o no la replicación de su contraseña:
 Usuarios al que no se le permite porque no pertenece a los grupos habilitados para ello, por lo que se le deniega
Lync Server RODC-39.png
Si añadimos al usuarios al grupo que permitimos la replicación de contraseñas y volvemos a comprobar que realmente ya tiene acceso.
Lync Server RODC-41.png
Si ahora queréis ver si realmente esto funciona, iniciaremos sesión con este usuario en algún equipo del dominio en el SITE de UK, yo lo haré en el RODC para que véais que ocurre. Como el usuario no es administrador ni tiene derechos para iniciar sesión en el RODC, es lo que nos indica puesto que la contraseña la hemos introducido de forma correcta (sino sería otro mensaje)
Lync Server RODC-42.png

Ahora si desde la consola de Usuarios y Equipos de Active Directory nos vamos a las propiedades de SRV-DC01 (RODC) y a la pestaña de Directiva de replicación de contraseña pulsamos en Opciones avanzadas, ahora tenemos dos pestañas pero ya nos quedamos en la primera Uso de directivas y elegimos Cuentas cuyas contraseñas están almacenadas en este controlador de dominio … observamos que ya aparecer la cuenta LyncUser4 con la que hemos querido iniciar sesión en el RODC que por otro motivos no hemos podido. Era simplemente a modo demostración, si se hubiese hecho desde cualquier equipo de la red también hubiese funcionado.

Lync Server RODC-43.png
Con esto ya tenemos el LAB preparado en cuanto a la topología de AD, Sites y RODC, el proceso de instalación de Lync me lo voy a saltar en esta serie de artículos. Lo que si os dejaré aquí el enlace a mi guía de Lync y un artículo del blog en donde hay un resumen de varias configuraciones para que las podáis seguir:

En el siguiente articulo veremos como se comporta un Front-END cuando tiene conexión con el DC y cuando solo tiene acceso al RDOC. Sobre todo orientado a lo que podemos o no hacer y como se ven afectados los usuarios.

Nos vemos en el siguiente artículo!!!

las videollamadas entre Skype y Lync está deshabilitada temporalmente

marzo 11th, 2015 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

​Microsoft de forma momentánea ha deshabilitado la videoconferencia entre Skype y Lync, aquí tenéis su explicación (el 26 de Enero volverá estar disponible):

Lync_Skype_No_Video.png
En diciembre de 2014, anunciamos la disponibilidad inicial de videollamadas entre Skype y Lync en una entrada de blog
(http://blogs.office.com/2014/12/05/video-calling-skype-lync-available-now)

en el sitio Web de Blogs de Office. En las semanas que siguieron esa disponibilidad inicial, hemos descubierto varios problemas en las versiones de cliente de consumidor de Skype que se han habilitado para video llamada con Lync. Estos incluyen al menos un problema que podría provocar que el cliente de Skype se bloquee. En función de la gravedad de los problemas, hemos desactivado videollamadas para la mayoría de los usuarios de consumidor de Skype mientras trabajamos en arreglar los problemas subyacentes.

En concreto, nos estamos asesorando lo siguiente:

  • A partir del 20 de enero de 2015, video llamada entre Skype y Lync está deshabilitado para la mayoría de las versiones del cliente de consumidor de Skype. Esto es debido a los problemas que se descubrieron que podrían provocar el cliente de escritorio de Skype Windows se bloquee en algunos casos.
  • Estamos trabajando activamente en un cliente de escritorio de Skype Windows actualizado y esperamos publicar esto en la página de descarga de Skype
    (http://www.skype.com/en/download-skype/skype-for-windows/downloading)

    en las próximas semanas.

  • Proporcionaremos un mensaje actualizado en el centro de administración cuando se haya completado el trabajo en este nuevo cliente.
  • Cuando publicamos a un nuevo cliente de escritorio de Skype Windows, toma varias semanas hasta que la mayoría de los usuarios finales ha actualizado y está habilitada. Durante este período transitorio, los clientes Lync que desean probar las nuevas capacidades del cliente pueden indicar a los participantes para descargar manualmente el nuevo cliente de la página de descarga de Skype
    (http://www.skype.com/en/download-skype/skype-for-windows/downloading)

Preguntas más frecuentes (P+F)

Q1: ¿Cómo y cuándo se volverá a habilitar el vídeo llamada entre Skype y Lync?
A1: Esperamos que vuelva a habilitar esta funcionalidad no más tarde de la semana de 26 de enero de 2015, al lanzar un nuevo cliente de escritorio de Skype Windows.

Q2: Con respecto a Q1, videollamadas con Lync se volver a habilitar mediante el uso de un nuevo cliente de escritorio de Skype Windows. ¿Cómo puedo comprobar si tengo el cliente correcto?
A2: Nos permitirá volver a videoconferencias con versiones de cliente de escritorio de Skype Windows o de Lync 7.1.xx.xxx y versiones posteriores. Puede comprobar el número de versión de Skype siguiendo las instrucciones en el ¿qué versión de Skype estoy usando en mi equipo?

 

10.000 Descargas de mi Guía de Lync Server 2013 en Español

marzo 11th, 2015 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Este post va a dirigido principalmente a todos los que os habéis descargado mi guia de Lync Server 2013 y después a todos los lectores de este blog. Hoy mismo he llegado a las 10.000 descargas de la guía que había publicado en su momento (Primera Guía de Instalación de Lync Server 2013 en Español), para mi es todo un lujo que siendo un desconocido en el mundo tecnológico haya podido llegar a las 10.000 descargas:

20150112_211621000_iOS.png
Además he recibido varios comentarios de los que hacen que uno se sienta muy agradecido, comentando que les ha sido de mucha ayuda en sus instalaciones, procesos de autoformación y presentaciones. No voy a poner ningún comentario porque considero que son comentarios privados, pero los acojo con mucha ilusión y agradecimiento.
 
Gracias a todos por leerme, dejar vuestros comentarios y espero que pueda seguir aportando mi granito de arena para que las Comunicaciones Unificadas sea una realidad en vuestras empresas y en la de vuestros clientes!!!