Cómo desplegar Windows Virtual Desktop 2020 Spring Release

Los profesionales de Windows Virtual Desktop llevábamos un tiempo configurando y administrando el servicio vía PowerShell o mediante interfaces web y de aplicaciones de terceros pero, por fin, podemos anunciar que eso se acabó.

Hoy es un día especial. Hoy más de uno sonreirá al leer esto… Hoy os traigo la nueva versión del servicio Windows Virtual Desktop (v2), conocida como Spring Release, recientemente salida del horno de Microsoft.

Analizaremos la nueva interfaz de gestión de Windows Virtual Desktop directamente desde el portal de Azure y veremos las nuevas funcionalidades que ésta nos trae.

WVD es un servicio en constante crecimiento, es por ello que el uso de este servicio ha sido incrementado en los últimos meses más de 3 veces su uso, tal y como indica este artículo de la revista Forbes.

En esta Spring Release observamos una serie de cambios a tener muy en cuenta, debido al gran valor que nos aportan. Sin más dilación, comencemos:


Cambios respecto a la anterior versión de WVD

A continuación analizaremos los cambios que se han producido respecto a la versión anterior, publicada como GA allá por Septiembre de 2019


Requisitos

En cuanto a los requisitos, nada a variado. Debemos continuar teniendo en cuenta los requisitos que vimos en un post anterior.


Nuevos componentes

Han surgido nuevos componentes dentro del portal de Azure referentes a Windows Virtual Desktop que vamos a desglosar:

Workspace

HostPools

Application Groups

El Workspace corresponde a lo que antiguamente denominábamos Tenant. Tendremos un espacio de trabajo y no será ya necesaria la creación del Tenant.

Los Host Pools continúan igual que hasta ahora. Tendremos nuestros Host Pools donde almacenaremos los Session Hosts que contendrán nuestros Desktops y/o Apps.

Continuamos teniendo los 2 tipos de Application Groups: Desktops y Apps. Como novedad, cabe destacar la posibilidad de crear estos Desktop y Apps en el mismo Host Pool y asignar usuarios a ambos Application Groups al mismo tiempo.


Despliegue de Windows Virtual Desktop Spring Release

Nos metemos de lleno en el despliegue de la nueva versión del servicio. Para ello, debemos dirigirnos al portal de Azure y buscar el servicio (hasta ahora no disponible) llamado Windows Virtual Desktop:

A continuación, tenemos la visión general del servicio, donde observamos las partes que podremos administrar una vez el servicio esté implementado:

Para comenzar, debemos pulsar sobre Create a host pool y se nos abrirá el asistente. Rellenamos los campos y continuamos al siguiente apartado. En nuestro caso, hemos tomado un escenario de partida en el que ya teníamos el Active Directory en una VM, desplegado como Domain Controller. Este Active Directory está sincronizado contra Azure AD mediante otra VM que tiene instalado y configurado Azure AD Connect:

Dado que el servicio se encuentra en Public Preview, tan solo podremos desplegar el servicio en las siguientes ubicaciones:

  • (US) Central US.
  • (US) East US.
  • (US) East US 2.
  • (US) North Central US.
  • (US) South Central US.
  • (US) West Central US.
  • (US) West US.
  • (US) West US 2.

Como podemos observar, tenemos un parámetro que nos indica el tipo de Host Pool, que puede ser Personal o Pooled:

  • Personal: los usuarios se conectarán a una VM asignada dedicada.
  • Pooled: los usuarios iniciarán sesión en una VM disponible al azar en cada login dentro del Host Pool.

Si seleccionamos Personal, debemos indicar si la asignación de los usuarios es automática o directa.

Si seleccionamos Pooled, debemos indicar el número máximo de sesiones por Host y el método de balanceo de carga:

  • Breadth-first: permite distribuir uniformemente las sesiones de usuario entre los Session Hosts en un Host Pool.
  • Depth-first: permite saturar un Session Host con sesiones de usuario en un Host Pool. Una vez que el Session Host alcanza su límite, el Load Balancer dirige cualquier conexión de usuario nueva al siguiente Session Host en el Host Pool hasta que alcanza su límite, y así sucesivamente.

Continuamos con la creación de máquinas. Podemos crear un nuevo Resource Group para almacenarlas o utilizar el que se creó en el apartado anterior.

NOTA personal: cuanto intenté desplegar Session Hosts en Resource Groups que tenían recursos en su interior, el deployment falló. Recomiendo crear un Resource Group previamente, mantenerlo sin recursos y desplegar las VMs que serán Session Hosts dentro de él.

Escogemos localización, tamaño de VM, número de VMs, prefijo para las mismas, tipo de imagen (si proviene de la galería o de un contenedor de almacenamiento), escogemos el tipo de disco para el sistema operativo y si queremos discos gestionados o no.

Rellenamos los parámetros relacionados con la red, donde podremos escoger la red, subred, IP pública y especificar el dominio.

NOTA: para esto, debemos contener nuestro Active Directory localizable, es decir, las VMs que generemos deben tener conectividad con el dominio, sea Azure AD DS, AD DS On-Premises o (como en nuestro caso), AD DS on Azure VM.

Rellenamos los datos de la cuenta que unirá las VMs al dominio y continuamos:

A continuación, crearemos un Workspace si no lo tenemos creado previamente:

Lo siguiente que se nos ofrece es el sistema de etiquetado. Esto es un entorno de demo y, por tanto, no lo definiremos.

Por último, revisar la configuración y crear:

Finalmente y tras esperar unos 12-15 minutos, el deployment finalizó con éxito:


Resultado

Observamos, en primer lugar, el Workspace generado:

Dentro de ese Workspace, tenemos el Host Pool creado:

Podemos ver la vinculación del Application Group creado con este Host Pool:

Adicionalmente, podemos ver los Session Hosts que se han creado (3) y vinculado al Host Pool:

En el apartado de Properties, podremos cambiar parámetros de configuración de WVD:

Por último, nos queda ver el Application Group creado. Dado que este Application Group es exclusivo para Desktops, nos aparece deshabilitada la opción de Applications:

Si queremos crear un Application Group para Apps, pulsaremos sobre Add. Rellenamos el Resource Group donde se implementará (en este caso, seleccionamos el anteriormente creado). Escogemos el Host Pool que tenemos creado y le indicamos un nombre al Application Group de RemoteApp:

Asignamos usuarios que tendrán acceso a este Application Group. De momento, como no tenemos configurado aún los grupos y usuarios, lo dejaremos en blanco.

NOTA: el método de asignación de usuarios ha cambiado. Para asignar usuarios a estos Application Groups, debemos haber iniciado sesión y realizar todas las operaciones con una cuenta que sea Owner de la suscripción de Azure, sino, el proceso de validación fallará porque se necesita este rol para poder realizar la asignación de roles a usuarios.

NOTA: Una de las nuevas funcionalidades es la posibilidad de asignar directamente grupos de Azure AD.

Nos toca seleccionar aplicaciones. El nuevo portal de administración realiza el autodescubrimiento de las aplicaciones que los hosts tienen instaladas y definidas en el Start menu, con lo cual, podremos escoger fácilmente las apps que queramos desplegar:

Seleccionamos el Workspace para registrar nuestro Application Group:

Ahora nos toca el sistema de etiquetado. En este entorno, no definiremos nada:

Revisamos y creamos:

Ya tenemos los 2 Application Groups creados, uno para Desktops y otro para Remote Apps:

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-26-1024x344.png

Y hasta aquí el post de hoy! En los siguientes post sobre Windows Virtual Desktop exploraremos más configuraciones del nuevo entorno, aplicaremos seguridad avanzada, etc.

Nos vemos en el siguiente post!

<< La nube puede ser maravillosa >>

Darío Romero