Charla técnica: «COVID-19 y teletrabajo: WVD»

El pasado lunes, abordamos el tema de los escritorios virtuales que ahora, con la situación desencadenada por el COVID-19, se han vuelto tan importantes para poder seguir con el trabajo, en concreto Windows Virtual Desktop.

Aunque es una herramienta relativamente reciente (la presentación de la misma fue a finales del año pasado), la charla venía con novedades, y es que, Microsoft sacaba a principios del mes de Mayo la Spring Release de WVD. Así que, nos pusimos manos a la obra y repasamos el despliegue junto con todas las novedades que traía WVD, que no eran pocas.

Algunas de las ventajas que ya nos proporcionaba WVD:

• Windows 10 multisesión que, junto a la escalabilidad de los recursos, nos permite reducir costes.
• RDS compatible con navegadores, IOS, MacOS, Android y por supuesto Windows
• Publicación del Desktop o RemoteAPP desde el mismo servicio
• Soporte extendido de seguridad para Windows 7

La Spring Release suma a todas estas ventajas un cambio importantísimo y es la integración total con Azure, por simplificar un poco hemos pasado de un servicio externo que se gestionaba como una WebApp a un servicio integrado en el portal con ARM.

Esto nos permite una gestión muchísimo más sencilla, ya que la mayoría de las tareas las podemos realizar desde el propio portal. Recordemos que, en la versión anterior, prácticamente la totalidad de la gestión se realizaba mediante Powershell.

Este gráfico nos permite visualizar todos los cambios en la arquitectura y ver los nuevos componentes que vamos a explicar en el modelo ARM:

PRE-REQUISITOS

Antes de comenzar a desplegar WVD necesitamos una infraestructura con las siguientes condiciones:

• Una instancia de Azure Active Directory.
• Necesitaremos Windows Server Active Directory que esté sincronizado con AAD. Podemos utilizar las siguientes herramientas según sea nuestro caso:
  • Azure AD Connect (si tenemos un DC on-premises o un DC virtualizado en Azure)
  • Azure AD Domain Services (en el caso de que hayamos trabajado con nuestro AAD)
• Una VNET que sea capaz de resolver los DNS hacia nuestro Windows Server Active Directory

También necesitaremos las licencias adecuadas para los usuarios finales y en caso de que nuestro global admin sea un B2C (usuario externo), crearemos uno que tenga el dominio registrado en Azure (o el que nos da por defecto @—.onmicrosoft.com).

Por último necesitaremos registrar el proveedor de recursos «Desktop virtualization»:

Y configurar el entorno de Powershell para poder hacer uso de los nuevos cmdlets integrados en módulo Az, con el siguiente cmdlet:

Install-Module -Name Az.DesktopVirtualization

NUEVOS CONCEPTOS

Una vez que ya tengamos nuestra infraestructura lista podemos comenzar a desplegar WVD, para ello voy a hacer un resumen de los nuevos conceptos que podemos encontrarnos:

Host pool: Se trata del conjunto de VM que desplegamos con las mismas características (imagen, tamaño, localización…). En este host pool podremos ver los session host, que son cada una de las VM que lo componen y tendrá asociado un Application Group que veremos más adelante.

Algunas de las cosas nuevas que se incluyen en la definición de los host pool son las siguientes:

• Tipo de host pool: personal, una VM asignada a cada usuario; pooled en una misma VM pueden iniciar sesión varios usuarios

• Load balancing algorithm: en caso de elegir el tipo pooled, debemos indicar como se van a distribuir las sesiones en las VM. Breadth-first, distribuye las sesiones a cualquier host disponible; Depth-first, primero distribuye las sesiones al host con más conexiones y que no haya llegado al límite.

• Tipo de imagen: este es uno de los grandes cambios si vamos a desplegar una imagen personalizada, pues se incorpora la SIG (Shared Image Galery) que nos permite tener versiones de una misma imagen. De esta forma conseguimos que no sea necesario borrar el host pool si actualizamos la imagen.

Application Groups: Nos permite definir las aplicaciones y el escritorio remoto de cada host pool y asignarlo a los usuarios finales. Es decir, definimos que va a ver cada usuario al conectarse con el RDC; le asignamos VM y/o app de la VM.

Hay dos tipos de Application groups; remote app para publicar a los usuarios aplicaciones de la VM o Desktop que les publica la conexión a la VM

Workspace: Almacena todos los Application Groups, de esta forma podemos simplificar la delegación de gestión a través de permisos de IAM.

ACCESO DEL USUARIO FINAL

Por último destacar que el acceso final del usuario es muy sencillo y también se ha modificado un poco, la nueva URL de conexión vía web para los usuarios es la siguiente:

https://rdweb.wvd.microsoft.com/arm/webclient

Mientras que si usamos el cliente RDC para otras plataformas como Android, MacOS o IOS la Feed URL es:

https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery

Con esto ya tenemos los conceptos para un despliegue básico de WVD, os recomiendo revisar otras funcionalidades más avanzadas e interesantes como FsLogix (para la persistencia de los perfiles de usuario) entre otras.

Aquí os dejo la documentación oficial de Microsoft, sobre la Spring Release de WVD:

https://docs.microsoft.com/es-es/azure/virtual-desktop/

Espero que os resulte interesante 😉
Jessica Crespo Muñoz