Montando un escenario de Virtualización del Escritorio: El papel de los Remote Desktop Services

Posts anteriores:

Hola

En este post vamos a desgranar el papel que juegan todos y cada uno de los subroles de los Remote Desktop Services de Windows Server 2008 R2 en un escenario de virtualización del escritorio. En el siguiente entraremos ya en detalle a ver cómo se configura el bróker en particular.

Antes de nada, mencionar que en Windows Server 2008 R2, el viejo nombre de "Terminal Services”, presente en nuestros sistemas operativos servidor desde los tiempos del NT 4.0, desaparece del producto en favor de los “Remote Desktop Services”. La idea es englobar bajo este paraguas todas las funcionalidades necesarias para que un cliente pueda acceder a escritorios y aplicaciones remotas de manera unificada. Este cambio de nomenclatura afecta en especial a dos roles, que son el “Remote Desktop Virtualization Host” (nuevo) y el Remote Desktop Connection Broker”, siendo para los demás prácticamente un renombrado, con ciertas salvedades en lo tocante a funcionalidad. A la izquierda los roles de Terminal Services en Windows Server 2008 y a la derecha los de Remote Desktop Services en Windows Server 2008 R2:

 image image

A las novedades incluidas en estos roles hay que sumar las del protocolo RDP 7.0 disponible por el momento únicamente en Windows 7 y Windows Server 2008 R2 (Soporte Multimonitor, Aero, Audio bidireccional, DirectX 10 / DirectShow / Multimedia Remoting…)

Remote Desktop Session Host. Virtualización de la Presentación

Este role nos ofrece dos formas diferentes de trabajar:

  • Nos permite que un usuario abra un escritorio completo sobre el servidor, lo que constituye el modo clásico de trabajar en los entornos de Terminal Server.
  • En de Windows Server 2008 se introduce la funcionalidad de lanzar aplicaciones remotas, de modo que la aplicación ejecutándose en el servidor aparece integrada con el escritorio local del cliente desde el que se realiza la conexión.  El administrador decide que aplicaciones de las instaladas (o virtualizadas con App-V) en el servidor se exponen de esa manera y el protocolo RDP 6.1 (y posteriores) hacen el resto. En Windows Server 2008 no se podía establecer que aplicaciones de las publicadas estaban a disposición de usuarios/grupos. En R2 existe una propiedad “User Assignment” para cada aplicación publicada con Remote App que nos permite hacer esto

image

Para saberlo todo sobre este role:

Remote Desktop Virtualization Host

Este nuevo role consiste en una especie de “pegamento” entre los servicios de gestión de Hyper-V y el Bróker de conexiones, o lo que es lo mismo, entre lo que vemos en la consola de Hyper-V y el mundo de las conexiones RDP. Se encargará de informar acerca de las VMs disponibles en el host al broker y de llevar ciertas acciones sobre las máquinas virtuales. Arrancarlas o despertarlas si están paradas o salvadas en el momento de ser solicitadas por el usuario, o apagarlas tras un cierto tiempo de inactividad.

Este role no tiene mayor misterio ni configuración, y tiene simplemente que habilitarse en todos los servidores de Hyper-V R2 con los que queramos tratar desde el broker de conexiones, sean stand-alone o miembros de un cluster. En las instalaciones “Core” o en Hyper-V server 2008 R2, adopta el nombre de “VmHostAgent”.

Remote Desktop Licensing.

Este role se necesita para gestionar las licencias de acceso de cliente a Terminal Server (TS CALs), que para ser congruentes con el cambio de nombre ahora pasan a llamarse RDS CALs. Prefiero no detenerme mucho aquí en esta ocasión, porque si no voy a acabar siendo blanco de todas las dudas acerca del peliagudo tema de las licencias de Terminal Server y su compatibilidad entre versiones de la comunidad hispanohablante. No obstante aquí hay un montón de información al respecto:

Remote Desktop Session Broker

Es una evolución de TS Sessión broker, que hasta ahora “solo” servía para balancear carga de trabajo entre servidores de una misma granja de Terminal Servers, y reconectar a los usuarios con el servidor en el que estuviera abierta su sesión. Si imaginamos un pool de máquinas virtuales como un conjunto de servidores de Terminal Server configurados de forma idéntica y que solo pueden recibir una sesión de usuario simultánea, la idea es perfectamente extrapolable al mundo de VDI. En este role podemos configurar:

  • Escenarios de Publicación de Aplicaciones en Terminal Servers / Remote Desktop Session Hosts stand-alone.
  • Escenarios de Publicación de Aplicaciones en granjas de Terminal Servers / Remote Desktop Session Hosts.
  • Escenarios de VDI estáticos. Cada usuario tiene asignada una VM específica. Esto se logra mediante una nueva propiedad de los usuarios en AD, en la que se almacena la VM asignada a ese usuario.
  • Escenarios de VDI Dinámicos. Se definen conjuntos de VMs o Pools de VMs idénticamente configuradas, que serán asignadas a los usuarios que las demanden de manera dinámica. Los usuarios que hayan dejado sus sesiones abiertas o desconectadas, serán redirigidos de nuevo a la misma VM del pool para mantener su trabajo. Dedicaré otro post de la serie a ver los requerimientos y configuración necesarios en las VMs del Pool.

Para configurar y operar los dos escenarios de VDI, el Bróker habla con el RD Virtualization Host de los servidores con Hyper-V donde corren esas máquinas virtuales

Pondré un post dedicado a un ejemplo de cómo montar y configurar el broker en el entorno de pruebas que planteaba en el primer post de esta serie. Mientras tanto:

Remote Desktop Web Access

Como en Windows Server 2008, en R2 el RDWeb consiste en un portal en el que el administrador pone a disposición del usuario todas o algunas de las siguientes cosas.

  • Aplicaciones Remotas publicadas en TS / RDSH
  • Escritorios completos de TS / RDSH
  • Máquinas Virtuales personales
  • Pools de máquinas virtuales

Remote Desktop Web Access puede recolectar y publicar lo que este expuesto en:

  • Uno o varios servidores TS / RDSH
  • Un Broker de conexiones

En el primer caso, solo veremos las diferentes Remote Apps definidas en los diferentes servidores. En el segundo veremos las VMs además de todas las Remote Apps que vengan de los servidores/granjas que el broker esté manejando. Por otro lado, un mismo TD / RDSH / Broker puede estar siendo publicados en varios RDWebs diferentes, pudiéndose establecer un control bastante fino de que queremos presentar a los usuarios.

Una novedad es que para acceder al portal se requiere por defecto autenticación. De esa manera se identifica al usuario y sabemos a que VM mandarle cuando haga clic en el icono “My Desktop” y que aplicaciones enseñarle o no según su pertenencia a grupos (solo en RDSH, como hemos dicho mas arriba):

image

Una funcionalidad interesante de este Web es que expone todas las conexiones en un RSS. Windows 7 es capaz de consumirlos y exponerlos como elementos del menú del usuario. Al igual que los elementos del portal, no son mas que ficheritos .rdp que procesa el cliente de RDP (mstsc.exe)

image image

Más sobre este ejemplo también en el siguiente post. Mientras:

Remote Desktop Gateway

Al igual que en el TS Gateway, este role permite un escenario de publicación segura del protocolo RDP. Es muy similar al uso de RPC sobre HTTPs que hace Outlook para comunicarse con el CAS de Exchange. En este caso le solicitamos al gateway que nos conecte con cualquier cosa que hable RPC que esté detrás. Nosotros hablamos RDP sobre HTTPS usando el puerto 443, y el gateway habla con el destino usando ya el 3389, tras llevar a cabo los chequeos de seguridad y salud pertinentes contra el Network Policy Server (NPS). Este role se pone en la DMZ, quizás junto con el RDWeb y/o se pueden publicar con ISA Server. Es una manera alternativa para conectarnos a clientes y servidores desde cualquier parte, evitando tener que levantar una VPN.

Espero que el resumen os resulte aclaratorio. En los enlaces que os he puesto tenéis bastante más información y seguro que seguirán apareciendo más cosas al respecto un futuro próximo.

Saludos

David Cervigón