Freigeben über

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

  • Artikel

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

Comments

  • Anonymous
    January 01, 2003
    Hola Puedes habilitar escritorio remoto compartido en Windows /, pero solamente aceptará una sesión simultánea, no dos Saludos

  • Anonymous
    January 01, 2003
    Hola Cuando corres el asistente de configuración de Personal Desktops en el Connection Broker, te pide que le especifiques un servidor de Remote Desktop Services para configurarlo en modo redirección. Si el servidor que especificas ahi no tiene RDSH configurado en modo redirección (lo hace automaticamente el asistente) se ocmporta como dices. El RDSH en modo redireccion no te deja conectarte por RDP (Remote Logins are Disabled) a menos que pongas el /admin cuando te conectas a el. esto es sintoma de que esta bien configurado. En resumen, cuando te conectas con el broker, la conexión se reenvia contra el RDSH configurado en modo redirección, y este conecta con el escritorio personal. Si no esta en modo redirección, esto ultimo no sucede Saludos

  • Anonymous
    January 01, 2003
    Totalmente seguro

  • Anonymous
    January 01, 2003
    Hola Ciertamente para entrar a administrar un servidor virtual, no necesitas CAL alguna. De hecho no necesitas ni los roles de RDS (TS). Basta con habilitar el escritorio remoto. Si hablamos de cliente, del mismo modo no necesitas pagar nada por la conexion RDP a la VM, pero en nuestro caso, el paso por el broker consume un RD CAL (con otros brokers, pagas el broker :-) ) Todo esto aparte del licenciamiento del propio SO que corra en la VM Definitivamente tengo que re-publicar los posts de licenciamiento con todo esto bien explicado. A ver si saco un rato Saludos

  • Anonymous
    June 22, 2009
    Estas seguro "RDP sobre HTTPS usando el puerto 443" ?

  • Anonymous
    October 30, 2009
    The comment has been removed

  • Anonymous
    May 05, 2010
    David, de nuevo excelente tu blog, tengo una duda, talvez puedas ayudarme, hice todo lo necesario para tener un escritorio virtual e incluso ya me aparece en remoteapps, pero en el momento en el q intento conectarme en lugar de conectarse con un escritorio de windows 7 virtualizado con hyper-v se hace un escritorio remoto con el servidor de virtualizacion, no se si me puedes dar una pauta de que puede estar mal?? en el active directory si esta asignado el escritorio de windows 7 para ese usuario saludos y desde ya te agradezcon por tu ayuda

  • Anonymous
    March 24, 2011
    Hola DAvid. Tengo la siguiente pregunta. Tengo en casa una computadora con buenos recursos y ejecutandose Windows 7 Enterpise 64bits. quiero habilitar un par de thin client WiFi NComputing. Entiendo que es posible habilitar RDS en Windows 7para manejar sesiones multiples y concurrentes en la computadora host y en los thin client. Tienes alguna recomendación al respecto???

  • Anonymous
    March 24, 2011
    Hola DAvid. Tengo la siguiente pregunta. Tengo en casa una computadora con buenos recursos y ejecutandose Windows 7 Enterpise 64bits. quiero habilitar un par de thin client WiFi NComputing. Entiendo que es posible habilitar RDS en Windows 7para manejar sesiones multiples y concurrentes en la computadora host y en los thin client. Tienes alguna recomendación al respecto???

  • Anonymous
    January 29, 2014
    Buen día David.Lei los post y esta muy buena la informacion, solo tengo una duda a ver si me puedes aclarar un poco el panorama. Habilite RemoteApp para publicar una aplicacion, hasta aqui no tengo problema y todo me trabaja a la perfeccion. Mi intencion es generar una granja de servidores con la misma aplicacion trabajando sobre RemoteApp. debido a que la cantidad de usuarios que ocupan dicha aplicacion es alta, necesito distribuir la carga entre 3 o 4 servidores. Mi pregunta es si el broken hace esa funcion de distribuir la carga y como publico la aplicacion hacia los usuarios?Por adelantado Gracias.Saludos.