Freigeben über

Montando un escenario de Virtualización del Escritorio: Requisitos de las Máquinas Virtuales para VDI

  • Artikel

Posts anteriores:

Hola

En los dos últimos capítulos hemos tratado cómo utilizar los roles de los Remote Desktop Services para crear y presentar máquinas virtuales personales y “pools” de máquinas virtuales. Para completar esta parte, hoy vamos a tratar que requisitos deben cumplir los sistemas operativos instalados en esas máquinas virtuales para que todo esto funcione, así como algunos métodos para configurarlo de forma sencilla.

En resumen, para que el broker, el Virtualization host, y el cliente RDP que utilizará el usuario puedan dialogar correctamente es necesario que el Windows XP, Vista o 7 de la máquina virtual tengan:

  1. El Escritorio Remoto Compartido habilitado y a los usuarios que van a acceder remotamente a ellos metidos en el grupo local “Remote Desktop Users”
  2. Los servidores de Hyper-V que pueden llegar a correr la máquina virtual deben pertenecer al grupo local de administradores
  3. Permitir la gestión remota de los servicios de RDP por RPC:
    • HKLM\System\CurrentControlSet\Control\Terminal Server\AllowRemoteRPC=1 (REG_DWORD)
  4. El firewall, de estar activado, debe permitir las conexiones entrantes de administración remota además de todo lo anterior:
  5. Adicionalmente las máquinas virtuales deben de estar configuradas de forma idéntica en todo lo demás. Eso implica
    • Tener instalado el mismo software, configurado de forma idéntica
    • Tener el cliente de APP-V configurado de la misma manera (en el caso de nuestro escenario, este es el único software que montaremos)
    • Que se les apliquen las mismas políticas de grupo
    • Que los usuarios que se conecten tengan perfiles móviles / carpetas redirigidas, etc.

Tenemos dos formas de abordar la configuración de todo esto. Ambas no son mutuamente excluyentes, sino que se pueden (y yo diría deben)complementar:

  • Podemos configurar todo lo anterior en la plantilla que utilizaremos como base de las máquinas virtuales que creemos. Es decir, nos instalamos una, le configuramos todo lo anterior, le metemos todo el software necesario, la probamos, y cuando estemos satisfechos con el resultado la convertimos en la plantilla que usaremos para aprovisionar nuestras VMs personales o de los pools
  • Las políticas de grupo permiten configurar todo lo anterior. No solamente por primera vez, sino que nos aseguran que el entorno se mantenga configurado como queremos. Basta con generar una OU que albergue las cuentas de máquina correspondientes a las VMs y crear una GPO enlazada a dicha OU:

Entremos en detalle en cada uno de los puntos anteriores.

0.- Las Group Policy Preferences

Para la configuración de parte de lo anterior resultan particularmente útiles las Group Policy Preferences. Para que funcionen correctamente es importante instalar/actualizar las “Client Side Extensions” en Windows XP y Windows Vista. Por tanto, esto yo lo instalaría si o si en la maqueta que usaremos para la plantilla.

Otro buen método consistiría en utilizar script de inicio de sesión. Os dejo también algunas pistas, aunque no son las únicas (VBS, WSH, PowerShell…)

1.- Habilitar Remote Desktop y agregar a los usuarios que accederán a la VM al grupo local “Remote Desktop Users”

Primeramente usamos la GPO correspondiente para habilitar el Escritorio Remoto Compartido

image

Lo más cómodo para configurar los usuarios que se podrán conectar es, como de costumbre, usar grupos globales del Directorio Activo. Por ejemplo, creo un grupo “Usuarios del Pool 1” y le agrego a los usuarios grupos que van a acceder a ese pool de VMs. Luego agrego este grupo al grupo local “Remote Desktop Users”. Si queremos hacer esto por políticas de grupo, es así de sencillo (como veis, mis usuarios van a ser directamente los Domain Users)

image

Para los que os guste hacerlo a mano o por scripts, los dos pasos anteriores se pueden hacer mediante:

  • reg add "HKLM\System\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0
  • net localgroup “Remote Desktop Users” /ADD “Domain\Domain Users”

2.- Agregar las cuentas de máquina de los servidores de Hyper-V al grupo local de Administradores

Como en el caso anterior, lo mejor es crear un grupo global que aglutine las cuentas de máquina de todos los servidores de Hyper-V (en mi caso lo he llamado “Hyper-V Computers”), y volver a usar las preferencias para actualizar el grupo local de Administradores.

image

Este paso es importante porque el RD Virtualization Host Agent que corre en cada Hyper-V lo hace con la cuenta LocalSystem, lo que se presenta a nivel de seguridad remotamente al resto de la red como la cuenta de máquina. Una sencilla línea de comandos para lograr el mismo efecto.

  • net localgroup Administrators /ADD “Domain\Hyper-V Computers”

3.- Permitir la gestión remota de los servicios de RDP por RPC

Simplemente se trata de crear o cambiar el valor de esta entrada del registro HKLM\System\CurrentControlSet\Control\Terminal Server\AllowRemoteRPC=1 (REG_DWORD)

Y de nuevo, las Group Policy Preferences al rescate:

image

Una opción para hacerlo mediante script:

  • reg add "HKLM\System\CurrentControlSet\Control\Terminal Server" /v AllowRemoteRPC /t REG_DWORD /d 1

4.- Configuración del Firewall de Windows

Si tenemos el firewall de Windows activado necesitaremos crear la reglas necesarias. en resumen, necesitamos permitir las conexiones RDP entrantes, la Administración Remota y las conexiones WMI entrantes. Para todo esto hay ya reglas predefinidas muy fáciles de configurar por políticas de grupo:

image

Si queremos automatizarlo por línea de comandos:

  • En XP/2003:
    • netsh firewall set service type=REMOTEDESKTOP mode=ENABLE profile=ALL"
    • netsh firewall set service type=REMOTEADMIN mode=ENABLE profile=ALL"
  • En Vista/2008/7:
    • netsh advfirewall firewall set rule group=""remote desktop"" new enable=yes"
    • netsh advfirewall firewall set rule group=""remote service management"" new enable=yes"
    • netsh advfirewall firewall set rule name=""Windows Management Instrumentation (Async-In)"" new enable=yes"
    • netsh advfirewall firewall set rule name=""Windows Management Instrumentation (DCOM-In)"" new enable=yes"
    • netsh advfirewall firewall set rule name=""Windows Management Instrumentation (WMI-In)"" new enable=yes"

5.- Otras configuraciones y consideraciones importantes

Como decía anteriormente, sobre todo en los escenarios de VDI dinámicos en los que los pools de máquinas virtuales son compartidos por varios usuarios, es muy importante que la experiencia de los mismos sea independiente de la máquina a la que se conecten. El broker se encarga de redirigir a los usuarios a la siguiente VM disponible, o allí donde se hubieran dejado la sesión desconectada. Puede incluso salvar/reanudar las VMs cuando no se estén utilizando. Sobre estos temas, un par de matices.

En según que entornos, y en particular en los de demo/pruebas, es corriente que el usuario desconecte su sesión RDP y se olvide. Esto evitará que otro usuario se conecte a esa máquina. para evitar esto, podemos configurar por políticas cómo queremos manejar las sesiones desconectadas e incluso las inactivas. Por ejemplo, en mi entorno de pruebas/demos considero que si se está mas de 15 minutos desconectado o sin hacer nada hay que forzar el cierre de la sesión “olvidada”:

image

Por otro lado, como decíamos, los perfiles de los usuarios y/o algunas de sus carpetas deberían de estar centralizados. Nuevamente esto se lleva a cabo en gran parte mediante políticas. He aquí un buen enlace para configurar todo esto:

6.- El cliente de AppV y su configuración centralizada

En el entorno que hemos estado describiendo en esta serie de posts, el cliente de Microsoft Application Virtualization tiene un papel estelar a la hora de enviar a las VMs las aplicaciones virtualizadas que puede utilizar el usuario que ha iniciado sesión. Bajo mi punto de vista, debería ir instalado y preconfigurado en la maqueta que usaremos posteriormente como plantilla. No obstante, también podemos asegurar su configuración mediante políticas de grupo, lo que nos ayudaría a reaccionar fácilmente ante un cambio en la infraestructura de los servidores de gestión.

Para ello, necesitamos:

Y he aquí un ejemplo de como quedaría:

image image

La creación de las plantillas de las máquinas virtuales no representa es más que el viejo problema de la creación de imágenes para despliegue de los sistemas operativos del cliente adaptadas a las necesidades de la organización. A los que ya tengan experiencia en estos menesteres, introducir todo lo anterior resulta trivial. En este caso me he centrado en los requisitos indispensables para que las conexiones desde el cliente de RDP acaben conectando al usuario con una máquina virtual. Lo que luego nos encontremos dentro es cuestión de cada uno. Así es que no está de más trillarse la documentación en torno al Windows Automated Installation Kit y las modernas técnicas de despliegue de Windows:

Saludos

David Cervigón

Comments

  • Anonymous
    January 01, 2003
    Hola En el Broker, en las RemoteApps y en el Web Access debes especificar el nombre externo del RD Gateway. Solo necesitas abrir el 443, no el 3389 Mi recomendación es que pruebes priemeramente si te funciona bien el gateway. Simplemente lanza una conexion rdp contra un servidor/cliente interno usando el gateway en el cliente RDP y comprueba que funcione. Cuando tengas la seguridad de que el RD gateway funciona, pasa a configurarlo en el Broker, en las RemoteApps y en el Web Access (para esto, mira DefaultTSGateway en technet.microsoft.com/.../cc731465.aspx) Saludos

  • Anonymous
    January 01, 2003
    Hola Antonio Pues ese es precisamente el tabajo del broker: 1.- Saber que máquina pertenece a que usuario en el escenario persistente o estático 2.- En el escenario no persistente / Dinámico (Pools)          - Recordar que usuario tiene abierta sesion en que escritorio VDI          - Balancear peticines nuevas Hablamos

  • Anonymous
    January 01, 2003
    Hola David, aunque nos vamos a ver en breve. Me surgen dudas. Mis VDIs, van a ser XP SP3. Puesto que ahi no implemento NLB, ¿cómo le digo al broker que balancee las peticiones de mis usuarios a mis vdi XP?

  • Anonymous
    October 20, 2010
    Hola David todo me funciona dentro de la LAN pero desde internet no me funciona ya solicite el el datacneter la apertura de puertos 3389 y 443 hace falta algo mas o la configuracion del gateway debe llevar algo mas que los grupos de usuarios y equipos Gracias

  • Anonymous
    September 18, 2013
    veo que instalas el cliente App-V pero, donde está el servidor App-V Server? Ya me dices Saludos

  • Anonymous
    September 21, 2013
    Hola En un post anterior, mencionado al principio de este •Montando un escenario de Virtualización del Escritorio: El Servidor de App-V" (blogs.technet.com/.../montando-un-escenario-de-virtualizaci-n-del-escritorio-el-servidor-de-app-v.aspx) No obstante, App-V ha cambiado bastante desde que escribí esto. En sus nuevas versiones la arquitectura y funcionamiento puede ser diferente Saludos