Montando un escenario de Virtualización del Escritorio: El Bróker de conexiones de Windows Server 2008 R2

Posts anteriores:

• Montando un escenario de Virtualización del Escritorio: El objetivo
• Montando un escenario de Virtualización del Escritorio: El Servidor de App-V
• Montando un escenario de Virtualización del Escritorio: El Cliente de App-V
• Montando un escenario de Virtualización del Escritorio: Virtualizando una aplicación con el Secuenciador de App-V
• Montando un escenario de Virtualización del Escritorio: El papel de los Remote Desktop Services

Hola

En este capítulo vamos a tratar acerca de la instalación y configuración del nuevo Remote Desktop Connection Broker incluido como role dentro de los Remote Desktop Services de Windows Server 2008 R2. Como de costumbre, toda la información sobre este tema la tenéis detallada también aquí:

• Remote Desktop Connection Broker (RD Connection Broker)
• Remote Desktop Services in Windows Server 2008 R2. Getting Started

Como ya comenté en el post anterior de esta serie, cada uno de los subroles de los Remote Desktop Services tiene su propio papel en la infraestructura de virtualización del escritorio, y por tanto pueden separarse e incluso multiplicarse en diferentes servidores, pudiendo ser éstos físicos o virtuales en función de la arquitectura que se vaya a diseñar. En el caso del Connection Broker, es un role que se puede poner incluso en alta disponibilidad mediante Failover Cluster.

En los entornos de laboratorio y demo como el que planteaba en el post inicial de la serie suelo optar por combinar el Connection Broker con otros dos dos roles en la misma máquina virtual, un Session Host que utilizaremos exclusivamente en modo redirección y un Web Access que nos servirá de portal. La instalación del servidor no puede ser mas sencilla. Metemos la máquina en el dominio tras la configuración inicial del sistema operativo y le agregamos de tacada los tres roles:

• Remote Desktop Session Host (se configurará posteriormente en modo redirección, por lo que no valdrá para servir sesiones o aplicaciones)
• Remote Desktop Web Access
• Remote Desktop Connection Broker

Tras reiniciar, accedemos a la consola de configuración del Connection Broker y esto es con lo que nos encontramos:

Como se puede observar, esta todo por configurar. Lo cierto es que se tarda menos de un minuto en hacer todo esto, si antes hemos hecho los deberes:

• Agregar los Remote Desktop Virtualization Hosts, es decir, todos los servidores con Hyper-V R2 a los que les habremos tenido que instalar previamente dicho role que está disponible tanto en las instalaciones “Full” como en la Server Core. Se trata de un agente que se monta sobre la pila de gestión de Hyper-V en la partición padre, que no requiere de ningún tipo de configuración,  y que se encarga de transmitir información al bróker acerca del estado de las VMs y llevar a cabo acciones sobre ellas en su nombre.
• Agregar y si así se desea configurar automáticamente un Sesion Host en modo redirección.
• Agregar uno o varios  Remote Desktop Web Access que leerán la información de lo que expone el bróker y se lo ofrecerán a los usuarios.
• Asignar Personal Desktops, es decir, máquinas virtuales personales a usuarios.
• Crear “Pools” de máquinas virtuales configuradas de forma idéntica que servirán a conjuntos de usuarios con las mismas necesidades.
• Agregar los Remote Desktop Session Hosts (2008 R2) y Terminal Servers (2008), y/o granjas de ellos que queramos balancear.
• Configurar el certificado de servidor que se usará para cifrar accesos y comunicaciones, y el gateway que se usará si vamos a acceder remotamente encapsulando RPC sobre SSL. No voy a tratar este tema aquí, pero es conveniente hacer todo esto teniendo previamente desplegado una buena PKI en el directorio activo, para garantizar una buena distribución de certificados a equipos y usuarios, basados en la misma raíz de confianza

Configuración inicial

Lo más cómodo es lanzar el asistente para configurar los Personal Virtual Desktops, que es el primer enlace que aparece en el panel central, ya que configura de tacada gran parte de las cosas de la lista anterior. Tras la pantalla inicial del asistente, agregamos todos los hosts de virtualización en los que, insisto, tenemos que haber instalado también el role de Remote Desktop Virtualization Host:

 

A continuación nos pide un Remote Desktop Session host para usarlo en modo redirección. Si no le decimos lo contrario, realizará su configuración automáticamente. En nuestro caso se trata del propio servidor, por lo que ponemos su propio nombre. Como podéis observar, dice que necesita un nombre alternativo en el caso de que se vaya a dar servicio a clientes conversiones del protocolo RDP iguales o anteriores a la 6.1. Es tan sencillo como dar de alta un alias en el DNS apuntando a nuestro servidor con un nombre fácil de recordar. En nuestro caso, el servidor se llama Broker2008R2 y el alias que damos de alta en el DNS es Broker2008R2-bis. La tercera y la cuarta imagen imagen no salen en el asistente, y son el lugar donde se puede configurar a mano el modo de redirección del Remote Desktop Session Host. Los interesados en saber más acerca de que es esto de la redirección en Terminal Server, os recomiendo la lectura correspondiente de TechNet:

A continuación nos pide el nombre del RD Web Access Server que accederá a este bróker. Este paso no configura ese componente, y simplemente rellena el grupo local “TS Web Access Computers” donde deberán aparecer listados todos los servidores Web que estarán autorizados a leer la información de este bróker. Esto funciona igual que para los servidores de sesiones. Por tanto es muy recomendable tener clara que servidores web accederán a que bróker y servidores de sesiones y configurar de manera acode este grupo local. Como de costumbre, los grupos globales del dominio y las políticas de grupo pueden resultar muy útiles.

Con esto llegamos al final de la primera parte del asistente, y se nos presenta un resumen con los cambios que se van a realizar:

Asignar máquinas virtuales personales (escenario de VDI estático)

Llegados a este punto podríamos parar y volver a asignar máquinas virtuales a usuarios más adelante. Si continuamos con el asistente anterior, lo que sucede por debajo es bastante sencillo. En el Directorio Activo con esquema de Windows Server 2008, existe una propiedad de los usuarios que es su máquina virtual personal. Este asistente simplemente ayuda al administrador a seleccionar un usuario y rellenar dicho atributo con el nombre de una máquina virtual de las que sabemos que existen en los Virtualization Hosts que controla el bróker. Para esto y posteriormente para las VMs que conformen un “pool” es importante que el nombre de la VM en Hyper-V coincida con el nombre FQDN que tiene el el sistema operativo de la máquina virtual en el directorio activo. El nombre de la máquina virtual se puede cambiar fácilmente desde la consola de Hyper-V o desde Virtual Machine Manager. Esto es así porque el bróker localizará lo que ponga en el atributo del usuario que se le ha autenticado y le redirigirá a una sesión RDP contra dicho nombre. El cliente hará su resolución de nombres y usara su cliente RDP para hacerlo. Si los nombres no coinciden, jamás nos conectaremos. Mi recomendación es acostumbrarse a nombrar las VMs en Hyper-V con el nombre FQDN que tendrán, y renombrar la VM si cambiamos el nombre de host o el dominio al que pertenece el servidor/cliente virtual. La última imagen no corresponde al asistente, sino a la propiedad del usuario en AD, visto desde un una consola de 2008 R2, que sabe como manejar ese atributo.

 

 

 

Crear “pools” de máquinas virtuales (escenario de VDI dinámico)

Lo siguiente que podemos hacer es crear diferentes pools de máquinas virtuales, configuradas de forma idéntica, a las que se conectarán usuarios que tengan las mismas necesidades de uso. Podemos usar escritorios virtuales Windows XP, Windows Vista o Windows 7. Todos ellos tienen ciertos requerimientos de configuración para que todo esto funcione, que trataremos en el siguiente post de la serie.

La configuración de los pools en el bróker es bastante sencilla. Simplemente seguimos el asistente, que nos dará a elegir cuales de las VMs ya existentes en los diferentes servidores de Hyper-V queremos agrupar dentro del pool. Le damos un nombre y un identificador y eso es todo:

Una vez creado el pool, podemos acceder a sus propiedades y configurar algunas cosas interesantes, como sus propiedades RDP o si queremos salvar las VMs cuando no haya usuarios conectados. El bróker se encarga de arrancar/reanudar las VMs paradas/pausadas en Hyper-V a través del agente.

 

 

 

 

Podemos repetir este proceso cuantas veces queramos, siempre y cuando tengamos máquinas virtuales diferentes (una VM solo puede pertenecer a un pool). Los usuarios se conectaran al pool mediante el cliente RDP y un fichero .rdp que podremos configurar manualmente o que se nos enviará desde el portal web. Trataremos este tema en detalle en otro post.

Agregar las aplicaciones remotas provenientes de Session Hosts (2008 R2) y Terminal Servers (2008)

Por último, podemos agregar al bróker la lista de servidores de aplicaciones, bien en stand-alone o bien en granjas a los que queremos que el bróker ofrezca servicio. Es tan sencillo como esto:

Cada uno de los servidores que agreguemos aquí deberá tener su lista de aplicaciones remotas previamente rellena. En Windows Server 2008 R2, podemos incluso decidir que usuarios verán cada aplicación publicada, cosa que no podíamos hacer en los Terminal Services de Windows Server 2008:

 

Por supuesto, las aplicaciones que aquí publiquemos pueden estar instaladas localmente sobre el sistema operativo, o pueden venirnos virtualizadas a su vez con App-V. Los pasos para la configuración de granjas de servidores de sesiones la teneis detallada aqui:

• Checklist: Create a Load-Balanced RD Session Host Server Farm by Using RD Connection Broker

Publicación de la información del Broker a través de RD Web Access

Ya tenemos nuestro bróker funcional. Solo necesitamos una forma de poner la información a disposición de los usuarios de una manera sencilla. Para eso vamos a usar el Remote Desktop Web Access. En este caso lo instalamos en el mismo servidor, pero puede estar localizado en otro o incluso en varios servidores virtuales simultáneamente. El único requisito es que estén dados de alta el grupo local “TS Web Access Computers” de los servidores de aplicaciones y del broker. Una vez hecho esto, iniciamos sesión en el portal (https://servidor.dominio.local/RDWEB) con un usuario con permisos de administrador y accedemos a la pestaña configuración. Como podéis observar, el RDWEB puede servir a varios servidores de aplicaciones a la vez, pero solo a un bróker. El detalle de poder personalizar el nombre se configura en las propiedades de connection broker:

 

Y finalmente lo que verá un usuario que se conecte al portal web desde se equipo o cliente ligero será lo siguiente:

 

 

 

 

Aquí tenemos:

• My Desktop: Lleva a la VM personal que hemos asociado al usuario que ha iniciado sesión en el portal
• Pool de Escritorios Windows 7: Nos lleva a una VM de las del pool. A una libre si no habíamos iniciado sesión antes, o a la que mantiene nuestra sesión desconectada
• Aplicaciones instaladas y publicadas en diferentes servidores de aplicaciones (TS o RDS)
• Aplicaciones virtualizadas con APP-V y publicadas en diferentes servidores de aplicaciones (TS o RDS)

En el siguiente post de esta serie veremos en detalle cómo hay que configurar las VMs para que funcionen correctamente y algunos métodos para hacerlo de manera desatendida. Más adelante veremos también diferentes maneras que tenemos para acceder a toda esta información, además del portal web.

Enhorabuena por haber leído hasta aquí :-)

Saludos

David Cervigón

Comments

• Anonymous
  January 01, 2003
  Hola Tomás Si y si (creo) En la misma máquina puedes poner el gateway. Sin embargo, si pones un gateway es porque vas a acceder desde fuera. Y si vas a acceder desde fuera es muy posible que los certificados SSL no valgan porque el nombre público y el interno no coincidan. En ese caso puedes montar otro servidor físico o virtual con los roles de RD Web Access y RD Gateway que compartiran el mismo certificado SSL con el nombre público, y que apuntaran al broker. En este caso el Web necesita una pequeña personalización adicional para que lo que publiques use el gateway. De esta manera tienes un portal interno y otro externo, ambos apuntando al mismo broker y el externo apoyándose en el Gateway, que por supuesto puedes usar directamente. Creo que esto va a merecer un post de la serie... Sobre lo de las licencias, por lo que he entendido, el redirector si consume licencias de TSCAL del dispositivo que se conecta. Entiendo que es la misma que usara el dispositivo cuando acceda a las aplicaciones publicadas. Lo tengo que mirar bien Saludos

• Anonymous
  January 01, 2003
  Hola Los servidores se balancean por NLB o Round Robin DNS y los servidores se agregan al broker. Además hay que indicar a los servidores que son miembros de una granja y cual es el broker. Mejor lo tienes todo documentado aqui: http://technet.microsoft.com/en-us/library/cc771419.aspx http://technet.microsoft.com/en-us/library/cc772418(WS.10).aspx http://download.microsoft.com/download/b/1/0/b106fc39-936c-4857-a6ea-3fb9d1f37063/Step-by-Step_Guide_for_Configuring_Network_Load_Balancing_with_Terminal_Services_in_Windows_Server_2008.doc Saludos

• Anonymous
  August 21, 2009
  Gracias David por el post. Una consulta. Comentas que en un mismo servidor pones los roles de Connection Broker, RD Session Host y RD Web Access. En el caso de usar el rol RD Gateway, ¿se podría poner en el mismo servidor o es necesario otro? Otra duda. Si el RD Session Host funciona en modo Redirección para redireccionar clientes a las VM y no sirve ni sesiones ni aplicaciones, ¿sería necesario adquirir licencias TSCAL para cada redirección a una VM? Un saludo.

• Anonymous
  August 24, 2009
  Hola david, No se si este comentario encaja muy bien en este post o encajaria mejor en alguna de los anteriores de la serie, el caso es que estoy intentando montar un session broker que se encargara de redirigir la sesiones a dos servidores utlizados para publicar una serie de aplicaciones (vritualizacion de la presentacion), mi pregunta es la siguiente, estos dos servidores de terminal server  los debo configurar en nlb y configurar el broker para que apunte al cluster o por el contrario esto ya no es necesario y se puede encargar el broker de redirigir y recuperar las sessiones sin necesidad de que estos dos servidores esten en nlb? Un saludo y gracias de antemano

• Anonymous
  November 11, 2015
  tengo instalado windows server 8 r2 y 20 clientes ligeros que estan conectados al servidor de esos 20 solamente admite a dos usuarios si se quieren conectar mas aparece una ventana que dice inicio de sesion en windows, seleccione el usuario al que desea desconectar para poder iniciar sesion... es algun error de configuracion??