Guía rápida: Windows Virtual Desktop

En esta ocasión voy a publicar una guia rápida sobre la implementación de Windows Virtual Desktop, cuando me refiero a rápida, significa que no voy a entrar en detalles sobre lo qué es el servicio, su arquitectura, beneficios, etc. Si estás aquí es porque probablemente ya te has documentado muy bien sobre el servicio y lo que deseas es poner a prueba el mismo en el menor tiempo posible, así que empecemos.

Pre-requisitos

1. Licencia apropiada
2. Suscripción a Microsoft Azure
3. Privilegios Global Admin en Azure AD
4. Servicios de dominio (AD Connect, VPN o Azure AD DS)

NOTA: Es necesario tener autenticación mediante Active Directory, se pueden utilizar varios modelos como mencioné anteriormente en los pre-requisitos, en este caso he utilizado Azure AD DS, pero usted puede usar su propio controlador de dominio en IaaS, o bien conectarse a un controlador de dominio local a través de una conexión VPN. En este artículo se asume que ya se tiene configurado el servicio de Active Directory

Para que Windows Virtual Desktop pueda tener acceso a Azure AD necesitamos otorgar el "consentimiento", esto es necesario hacerlo antes de empezar a crear el tenant.

1. Vamos al portal de Azure y abrimos Azure Active Directory, y buscamos el GUID del tenant o el nombre, en este caso vamos a copiar el GUID.

2. Abrimos la siguiente URL: https://rdweb.wvd.microsoft.com/ en Consent option seleccionamos Server App en AAD Tenant GUID or Name pegamos el dato que copiamos en el paso anterior. y por último hacemos clic en el botón Submit

Nos pedirá las cerdenciales

Y luego nos mostrará los permisos que vamos a otorgar a esta aplicación.

Al hacer clic en Accept saldrá un mensaje indicando que la aplicación se ha registrado de forma satisfactoria.

3. Debemos volver a repetir el paso número dos, solo que en esta ocasión vamos a seleccionar Client App en lugar de Server App

Espero que este paso de registrar las aplicaciones cliente y seervidor sea provisional y que en una futura actualización sea suprimido, ya que es algo que Microsoft puede automatizar.

Asignar privilegios para crear el tenant

Ahora vamos a otorgar permisos a un usuario para crear el tenant.

4. Abrimos Azure AD y vamos a Manage->Enterprise applications

Veremos que se han creado dos nuevas aplicaciones: Windows Virtual Desktop y Windows Virtual Desktop Client

5. Hacemos clic sobre la aplicación Windows Virtual Desktop, y luego seleccionamos Users and groups

6. Hacemos clic en Add User

7. En Add Assigment, seleccionamos Users and groups y allí buscamos el usuario al cual le vamos a otorgar el privilegio para la creación del tenant.

Como podemos observar, automáticamente se ha diligenciado el campo Select role con el valor TenantCreator, por último hacemos clic en Assign

8. Podemos ver que el usuario designado ya posee el rol

Creación del Tenant

9. La creación del tenant se hace desde Windows PowerShell, así que lo primero es Instalar e Importar el módulo desde una consola de PowerShell elevada.

Import-module Microsoft.Rdinfra.RdPowershell

Una vez instalado, vamos a importarlo

Install-module Microsoft.Rdinfra.RdPowershell

Al finalizar, ejecutamos el siguiente comando:

Add-RdsAccount –DeploymentURL "https://rdbroker.wvd.microsoft.com"

Solicitará credenciales, debemosm poner las que tienen el rol de TenantCreator

Debemos obtener un resultado similar al que se muestra a continuación:

10. Ahora si vamos a ejecutar el comando para crear el tenant:

New-RdsTenant -Name -AadTenantID -AzureSubscriptionID

Donde es el nombre que va a llevar nuestro tenant (debe ser único),  el GUID de nuestro Azure AD, el cual ya utilizamos previamente para dar el consentimiento a las aplicaciones, y el último parámetro recibe el ID de la suscripción.

Creación del Host Pool

Ahora que ya hemos creado el tenant, podemos crear nuestro Host Pool, que es en escencia una colección de escritorios, aquellos que conocen Windows Server RDS, pueden asociar un Host Pool con una Colección.

11. En el portal de Azure buscamos Windows Virtual Desktop, en los resultados de búsqueda seleccionamos Windows Virtual Desktop - Provision a host pool

12. Hacemos clic en Create

13. Diligenciamos los datos como se muestra a continuación:

1. Seleccionamos  la suscripción en la cual vamos a implementar el servicio WVD.
2. Creamos o seleccionamos el grupo de recursos donde se crearán todos los recursos relacionados con WVD.
3. Seleccionamos la región, se recomienda verificar previamente que exista disponibilidad del servicio en la región seleccionada.
4. Ponemos el nombre que llevará nuestro host pool.
5. En tipo marcamos Pooled, que significa compartido.
6. Ponemos las cuentas separadas por coma de los usuario que tendrán acceso a los escritorios del host pool, no podemos por ahora seleccionar grupos.
7. La ubicación de la metadata del servicio, en este caso United States.
8. Clic en Next: Configure virtual machines.

14. En Configure virtual machines configuramos como se muestra a continuación

1. Indicamos Yes para permitir la creación de un conjunto de disponibilidad, a menos de que necesitemos crear más de 200 máquinas, lo cual es una restricción propia de los conjuntos de disponibilidad.
2. Aquí podemos elegir el tipo de usuarios, pues dependiendo el uso que se dará al escritorio se nos ofrecerá un determinado tamaño de máquina, aunque esto no significa que no podamos elegir un tamaño personalizado.
3. Ponemos el total de usuarios para el pool, dependiedno la cantidad de usuarios, nos indicará cuántas máquinas en total se requiere para satisfacer esa demanda.
4. Aquí se mostrará el tamaño de máquina sugeirdo, lo cual también podemos cambiar si no se ajusta a nuestras necesidades.
5. Ponemos el prefijo que llevarán nuestras máquinas, en este caso puse WVD, lo cual significa que si creamos 3 máquinas se crearán con la siguiente nomenclatura: WVD-1, WVD-2, WVD-3
6. Hacemos clic en Next: Virtual machine settings

15. En Virtual machine settings configuramos como se muestra a continuación

1. Seleccionamos Gallery con el fin de seleccionar alguna de las imagenes predefinidas, como por ejemplo las de Windows 10 Enterprise con Office 365 ProPlus ya instalado.Quedará para tema de otra entrada el cómo utilizar una imagen personalizada.
2. Seleccionamos la imagen Windows 10 Enterprise multi-session with Office 365 ProPlus
3. Seleccionamos el tipo de disco, si se puede Premium SSD mucho mejor para obtener un mejor rendimiento.
4. Escribimos la cuenta que tiene permiso para unir equipos al dominio.
5. Escribir contraseña y confirmarla.
6. Si deseamos especificar alguna OU en particular donde quedarán los escritorios dentro del dominio este es el momento.
7. Seleccionamos una red que tenga comunicación con la red donde se encuentran los servicios de dominio.
8. Seleccionamos la subred donde quedarán los escritorios.
9. Hacemos clic en Next: Windows Virtual Desktop information

16. En Windows Virtual Desktop information configuramos como se muestra a continuación

1. Este es el nombre por defecto para el grupo de escritorios, lo dejaré tal cual.
2. Ponemos el nombre del tenant que creamos en el paso 9.
3. Seleccionamos UPN, en caso de ser una cuenta que requiere MFA debemos crear un Service Principal.
4. Ponemos el UPN de la cuenta
5. Escribimos la contraseña y la confirmamos.
6. Por último, hacemos clic en Review + create

17. Una vez confirmemos que se han superado las validaciones, hacemos clic en Create

Ahora solo falta esperar hasta que el proceso termine.

18. Ahora vamos a probar la experiencia desde un navegador web, basta con ingresar a https://aka.ms/wvdweb e ingresar las credenciales cuando se soliciten.

Aparecerá el escritorio publicado con el nombre del pool (HostPool01), simplemente hacemos clic sobre el icono.

Permitimos la redirección del portapapeles y de impresoras.

Y listo, ya tenemos acceso a nuestro escritorio con Windows 10 Enterprise multi-session y Office 365 ProPlus.

Asignar aplicaciones

Ahora que ya tenemos escritorios publicado, vamos a ver cómo presentar aplicaciones a los usuarios, como por ejemplo Microsoft Word o Excel.

Para ello es importante tener presentes las siguientes restricciones:

• No se puede asignar un usuario a un grupo de aplicaciones de escritorio y a un grupo de aplicaciones RemoteApp en el mismo grupo de hosts (host pool).

• Se puede asignar un usuario a múltiples grupos de aplicaciones dentro del mismo grupo de hosts, y lo que verá al iniciar es una acumulación de ambos grupos de aplicaciones.

19. Con el siguiente comando podemos ver los grupos de aplicaciones existentes.

Get-RdsAppGroup -TenantName -HostPoolName

 Get-RdsAppGroup -TenantName WindowsDesktopMVP -HostPoolName HostPool01

En este caso podemos ver que solamente tenemos un grupo de aplicaciones, y que el mismo es de escritorio ResourceType:Desktop

20. Lo que vamos hacer ahora es crear un nuevo grupo de aplicaciones no para escritorios sino para RemoteApp de la siguiente forma:

New-RdsAppGroup -TenantName   -HostPoolName -Name “Office Apps” -ResourceType RemoteApp

New-RdsAppGroup -TenantName WindowsDesktopMVP  -HostPoolName HostPool01 -Name “Office Apps” -ResourceType RemoteApp

Nótese que ahora ResourceType es RemoteApp

21. Ahora podemos volver a ejecutar el comando del paso 19 y podemos ver que ya tenemos dos grupos de aplicaciones, uno para escritorios y otro para aplicaciones.

22. Ahora que ya tenemos el grupo de aplicaciones, vamos a agregar una aplicación a dicho grupo, en esta caso vamos a agregar la aplicación Microsoft Word

New-RdsRemoteApp -TenantName   -HostPoolName -Name “Offcie Apps” -AppAlias word

New-RdsRemoteApp -TenantName WindowsDesktopMVP  -HostPoolName HostPool01 -Name “Offcie Apps” -AppAlias word

23. Si deseamos obtener una lista de las aplicaciones que podemos presentar, basta con ejecutar el siguiente comando:

Get-RdsStartMenuApp -TenantName   -HostPoolName -AppGroupName “Remote Apps”

Y podemos ver un listado de aplicaciones y de allí podemos tomar el nombre de la aplicación.

Get-RdsStartMenuApp -TenantName WindowsDesktopMVP  -HostPoolName HostPool01  -AppGroupName “Remote Apps”

24. Ahora que ya tenemos la aplicación lista para ser presentada al usuario, solamente debemos asignar el usuario al grupo de aplicación. Pero recordemos que el usuario ya ha sido agregado al grupo de escritorio y no puede estar en los dos al mismo tiempo, tal como uindicamos al inicio en las restricciones, así que primero debemos retirarlo del grupo de aplicaciones de escritorio, para ello vamos a ejecutar el siguiente comando.

Remove-RdsAppGroupUser -TenantName   -HostPoolName -AppGroupName “Desktop Application Group” -UserPrincipalName

Remove-RdsAppGroupUser -TenantName WindowsDesktopMVP  -HostPoolName  HostPool01 -AppGroupName “Desktop Application Group” -UserPrincipalName cherrada@mscloudnow.com

25. Ahora si podemos agregar el usuario al grupo de aplicaciones RemoteApp.

Add-RdsAppGroupUser -TenantName   -HostPoolName -AppGroupName “Office Apps” -UserPrincipalName  

 Add-RdsAppGroupUser -TenantName WindowsDesktopMVP  -HostPoolName HostPool01 -AppGroupName “Office Apps” -UserPrincipalName cherrada@mscloudnow.com

26. Ahora solo nos resta probar, ingresando nuevamente a https://aka.ms/wvdweb

Podemos ver que nos aparece la aplicación Microsoft Word.

Al abrir escribimos las credenciales.

Y por último tenemos acceso de forma exitosa a la aplicación.

Y esto es todo! veo que aunque trate de ser lo más beve posible no ha quedado tan corta la entrada de blog, sin embargo son los pasos necesarios para poder empezar, entiendo que el proceso paraece un poco largo y tedioso, pero una vez lo completes vas a tener claros los pasos y será más sencillo.

Error al convertir certificado a PFX

Recientemente tuve la necesidad de convertir un certificado crt/p7b emitido por GoDaddy a PFX, lo necesitaba para una implementación en Azure, además muchos otros servicios en esta nube requieren de un certificado de este tipo, como por ejemplo: App Service, Application Gateway, LDAP seguro para Azure AD DS, entre otros. Así que lo primero que intenté fue convertir el certificado a PFX utilizando el crt proporcionado por GoDaddy, utilizando WSL como se muestra a continuación:

openssl pkcs12 -export -in 662c900db27b8e2b.crt -inkey private.key -out certificate.pfx

Y generó el siguiente mensaje de error:

unable to load private key 140415038919104:error:0906D06C:PEM routines:PEM_read_bio:no start line:../crypto/pem/pem_lib.c:691:Expecting: ANY PRIVATE KEY

Después de varias consultas en Internet, la causa que encontré sobre este error es la codificación del archivo que contiene la llave privada, que debe estar en UTF-8 sin BOM. Esto lo podemos verificar y cambiar si es el caso de manera sencilla utilizando Notepad ++.

Pare verificar, basta con editar el archivo que contiene la llave privada, luego vamos al menú Codificación y en este caso vemos que está marcado Codificar en UTF-8

Lo que debemos hacer es marcar la opción que está justo encima Codificar en UTF-8 sin BOM y guardar los cambios.

Después de esto volvemos a realizar el intento, y ahora si solicita la clave para el PFX y efectivamente lo genera sin problema.

Archivo PFX generado:

Y esto es todo! espero les sea de utilidad.

[ASR] Proteger máquinas administradas con Hyper-V - Parte 5

Entradas de esta serie:

Proteger máquinas administradas con Hyper-V - Preparar la infraestructura
Proteger máquinas administradas con Hyper-V - Replicación inicial
Proteger máquinas administradas con Hyper-V - Conmutación por error de prueba
Proteger máquinas administradas con Hyper-V - Conmutación por error planeada
Proteger máquinas administradas con Hyper-V - Conmutación por recuperación (failback)

CONMUTACIÓN POR RECUPERACIÓN - FAILBACK

Hemos llegado a la parte final de esta serie, en la entrega anterior ejecutamos una conmutación por error planeada, lo cual significa que trabajamos directamente en la máquina creada en Azure, y la máquina en el entorno local fue apagada, ahora después de haber hecho cambios en la base de datos SQL en Azure llegó la hora de volver a poner nuestro entorno local productivo, lo cual se conoce como failback, durante este proceso todos los cambios hechos en la máquina en Azure serán replicados hacia el entorno local, veamos el proceso completo.

Nótese que la dirección de la replicación ahora tiene como origen Microsoft Azure y como destino On-premises

En Data Sync hemos seleccionado minimizar tiempo de inactividad, donde el proceso que se realiza es el siguiente:

1. Crea un snapshot de la máquina virtual en Azure y lo copia al Hyper-V del entorno on-premises, pero la máquina sigue en ejecución en Azure.
2. Se apaga la máquina virtual en Azure (inicio del tiempo de inactividad), por lo cual no se aceptarán más cambios, y se envían los últimos cambios (delta) a la máquina virtual en Hyper-V

Si deseamos podemos marcar la casilla de verificación para crear la máquina virtual en el entorno local en caso de que no exista.

Después de hacer clic en Aceptar veamos a nivel de Hyper-V lo que está ocurriendo.

Hacemos clic derecho sobre la máquina replicada y seleccionamos View Replication Health

Podemos observar en el estado que la operación de failback está en progreso

Desde la misma consola de Hyper-V podemos ver el avance de la operación.

Una vez se terminen de enviar los datos se solicitará la intervención del usuario para iniciar el tiempo de inactividad, que es cuando se apagará la máquina en Azure.

Hacemos clic en la parte superior en Completar conmutación por error planeada nos saldrá un mensaje solicitando confirmación, hacemos clic en Sí

En este instante se apagará la máquina en Azure, se enviarán los cambios pendientes al entorno local y por último se iniciará la máquina en Hyper-V

Al finalizar, veremos todas las tareas ejecutadas, y como último paso ya debe estar encendida la máquina virtual en Hyper-V y apagada la máquina en Azure.

Estado de la máquina en Azure:

Estado de la máquina on-premises en Hyper-V:

Ahora vamos a verificar la base de datos en la máquina recién iniciada en Hyper-V, debería estar el registro que agregamos en la base de datos cuando la máquina estaba operando en Azure.

Como podemos apreciar en la imagen anterior, están los dos registros, el segundo fue el que agregamos cuando hicimos la conmutación por error planeada e iniciamos la máquina en Azure.

Una vez hemos verificado que la máquina se encuentra en el estado que necesitamos, podemos regresar al portal de Azure y confirmar la conmutación por recuperación (failback).

Está operación una vez confirmamos no podemos dar marcha atrás.

Esperamos a que el proceso finalice.

Una vez finalice el proceso debemos habilitar la replicación inversa, es decir, que ya no estamos replicando desde Azure hacia el entorno local, sino que ahora vamos a replicar desde el entorno local hacia Azure.

Hacemos clic en Aceptar para iniciar la replicación inversa

Una vez finalizado el proceso, la replicación ya quedó funcionando como al principio, desde nuestro entorno local hacia Azure, y de esta forma hemos finalizado el proceso de failback.

Con esta última entrega hemos finalizado esta serie sobre protección de máquinas virtuales administradas con Hyper-V utilizando Azure Site Recovery. Espero que la información aquí plasmada sea de su utilidad. 

Un abrazo!