Windows Virtual Desktop

Serie de eBooks de AzureS
Windows Virtual Desktop

Guía de migración para los
servicios de escritorio remoto
Guía de migración de Windows Virtual Desktop para los servicios de escritorio remoto 2
Tabla de contenido
Introducción 3 Implementación y pasos posteriores
¿Por qué se debe considerar una VDI en la nube?......................... 3 a la implementación 28
¿Por qué migrar a Windows Virtual Desktop?................................ 4 Confirmación del estado y uso de Windows Virtual
Desktop.................................................................................................... 28
Preparación de la migración 6 Consideraciones y pasos posteriores a la implementación..... 29
Limpieza de una implementación de RDS.....................................30
Paso 1: Requisitos previos.......................................................... 7
Paso 2: Configuración de Azure Migrate................................. 7
Paso 3: Detección de VM............................................................ 8 Orientación sobre capacidades
Paso 4: Revisión de la evaluación........................................... 10 adicionales 31
Escalado automático.............................................................................31
Creación del entorno de Windows Acceso condicional...............................................................................32
Virtual Desktop 13 Supervisión............................................................................................. 33
Automatización.....................................................................................34
Requisitos previos..................................................................................13
Azure Advisor......................................................................................... 35
Consideraciones.....................................................................................15
Microsoft Teams....................................................................................35
Optimización de costos........................................................... 16
Conexión de aplicaciones MSIX........................................................36
Pautas de red..............................................................................17
Pautas de administración de perfiles..................................... 18
Múltiples sesiones de Windows 10......................................... 18 Conclusión 37
Convenciones de nomenclatura............................................. 19 Resumen................................................................................................... 37
Orientación de implementación.......................................................19 Recursos................................................................................................... 37
Paso 5: Replicación de VM....................................................... 23
Paso 6: Migración de prueba................................................... 23
Paso 7: Migración para la producción....................................24 Glosario 39
Pruebas y preparación para Acerca del autor 40

la implementación de Windows Virtual
Desktop 25
Confirmación del estado de implementación
de Windows Virtual Desktop............................................................. 25
Estado del grupo host de Windows Virtual Desktop........... 26
Orientación para realizar pruebas de las
implementaciones de Windows Virtual Desktop....................... 26
Preparativos finales para la implementación............................... 27
Introducción
¿Por qué se debe considerar una VDI en la nube?
A medida que las empresas se adaptan a nuevas formas de trabajar y evalúan cómo llevar la
resiliencia a sus negocios, la habilitación de una experiencia de escritorio remoto segura, que sea
accesible desde cualquier lugar, se vuelve cada vez más importante.
Un enfoque de infraestructura de escritorio virtual (VDI) a menudo se aprovecha para

entregar una experiencia de escritorio remoto a los empleados a través de los servicios
de escritorio remoto (RDS). Sin embargo, como solución local, los RDS no alcanzan el valor
completo de la modernización o los beneficios de una VDI en la nube.
Windows Virtual Desktop es una solución entregada por VDI administrada que se hospeda
en Microsoft Azure y le ofrece la escalabilidad de la nube. Windows Virtual Desktop no solo
es compatible con Windows Server, sino que también proporciona múltiples sesiones de
Windows 10 Enterprise, que combinan la experiencia de Windows 10 con la capacidad de ejecutar
varias sesiones de usuario de manera simultánea, algo que anteriormente solo estaba disponible
en Windows Server. También obtendrá una experiencia optimizada para las aplicaciones
de Microsoft 365, incluido Microsoft Teams y seguridad mejorada para usuarios, aplicaciones
de la empresa y datos. Además, con programas como App Assure, podrá modernizar y reducir
los costos asociados con tres pilares diferentes. La figura 1 muestra estos pilares e incluye las
diversas áreas en las que se pueden reducir costos.
Infraestructura Licencias TCO
Se aumenta la Se reutilizan licencias No es necesario

utilización con las existentes de administrar
múltiples sesiones Windows o M365. componentes
de Windows 10 de infraestructura
de RDS
Procesos, Ahorro en CAL Proceso y
almacenamiento de RDS almacenamiento
y red rentables administrados
por Azure
Se apagan las VM Windows 7 ESU Aplicación de
para ahorrar costos durante 3 años parches,
supervisión
y administración
más fáciles
Se evitan los
costos iniciales
Figura 1: Pilares de ahorro de costos de Windows Virtual Desktop

Además de permitir el trabajo remoto y de ahorrar en infraestructura, licencias y costo total

de propiedad (TCO), Windows Virtual Desktop también aporta otros beneficios a su negocio,
incluida la administración de TI simplificada, capacidades de seguridad que ayudan a mantener
la seguridad de sus usuarios, sus datos y su organización, y protección contra interrupciones con
las tecnologías de Azure Site Recovery y Azure Backup integradas.
¿Por qué migrar a Windows Virtual Desktop?

Si tiene RDS y está considerando migrar a una solución de Microsoft, puede migrar a un enfoque
de infraestructura como servicio (IaaS) con Azure o migrar directamente a Windows Virtual
Desktop.
Para entender las diferencias entre RDS locales, la migración a Azure y la migración a Windows
Virtual Desktop, eche un vistazo a la Tabla 1. Si bien los RDS le proporcionan flexibilidad, también
conllevan una enorme lista de responsabilidades. Con un entorno de RDS, usted básicamente
es responsable de administrar y mantener todos los componentes requeridos. La migración
a RDS aumenta la responsabilidad proporcionada por Microsoft; sin embargo, al migrar
a Windows Virtual Desktop, Microsoft también administra el plano de control de virtualización
por usted. Esto le permite cambiar su enfoque hacia lo que realmente le importa: la experiencia
percibida del usuario final.
Responsabilidad RDS locales RDS en Azure Windows Virtual Desktop
Identidad
Dispositivos de usuario final
(móviles y PC)
Seguridad de aplicaciones
Sistema operativo host de la sesión
Configuración de implementación
Controles de red
Plano de control de virtualización
Hosts físicos
Red física
Centro de datos físico
Cliente Microsoft
Tabla 1: Responsabilidades
Este eBook es una guía que ayuda a las organizaciones a migrar las infraestructuras de RDS
existentes a Windows Virtual Desktop. Analizará cómo obtener todos los beneficios de Windows
Virtual Desktop y Azure en general y le proporcionará orientación relacionada con los siete pasos
para migrar sus cargas de trabajo de RDS a Windows Virtual Desktop.
1 2 3 4
Requisitos previos Configuración Detección de VM Revisión de la
de Azure Migrate evaluación
5 6 7
Migración para
Replicación de VM Migración de prueba la producción
Figura 2: El plan de migración de siete pasos
La figura 2 muestra los siete pasos recomendados que permitirán un proceso de migración
sin problemas de RDS a Windows Virtual Desktop. Este eBook lo guiará en este proceso de
migración de siete pasos. En el capítulo siguiente, analizaremos en detalle cómo implementar
estos siete pasos.
Preparación de la migración
En el capítulo anterior, presentamos el enfoque de siete pasos para migrar las cargas de trabajo
de RDS a Windows Virtual Desktop. En el paso 1 se deben reunir los requisitos necesarios antes
de comentar a migrar las cargas de trabajo a Windows Virtual Desktop. En el paso 2, instale
y configure Azure Migrate como herramienta de migración de sus cargas de trabajo existentes.
Con Azure, detectará las máquinas virtuales (VM) en el paso 3. Ese descubrimiento conduce
a una evaluación de revisión en el paso 4, que le permite examinar los detalles de la replicación.
Al aceptar la evaluación de revisión, las VM se replicarán en Azure como parte del paso 5.
Una vez replicadas, puede comenzar a probar sus cargas de trabajo en el paso 6. Después de una
prueba exitosa, migrará y llevará Windows Virtual Desktop a producción.
Este eBook lo guiará en este proceso de migración de siete pasos. Estos pasos se basan en Azure
Migrate, que también se puede usar para migrar muchas otras cargas de trabajo locales a Azure.
Azure Migrate ofrece una gran cantidad de beneficios, que incluyen evaluaciones de preparación,
determinación de tamaño y estimación de costos. También contiene una migración integrada
con un tiempo de inactividad casi inexistente. Se le proporciona una experiencia integrada con
el seguimiento del progreso de extremo a extremo. Para obtener más información y orientación
sobre Azure Migrate, visite esta página.
En este capítulo, abordaremos los cuatro primeros pasos como parte del enfoque de siete
pasos que presentamos anteriormente para comenzar a migrar sus cargas de trabajo de RDS
a Windows Virtual Desktop.
1 2 3 4
Requisitos previos Configuración de Detección de VM Revisión de la
Azure Migrate evaluación
5 6 7
Migración para
Replicación de VM Migración de prueba
la producción
Figura 3: Primeros cuatro pasos del proceso de migración

Paso 1: Requisitos previos
Primero, se necesita una suscripción a Azure. Si su organización ya tiene una, asegúrese de tener
el nivel de permisos correcto. Durante esta migración, necesita permiso para trabajar con
componentes de almacenamiento y red, además de, por supuesto, máquinas virtuales. Asegúrese
de que los servicios de dominio, sean Active Directory o Azure Active Directory Domain Services,
estén sincronizados con Azure Active Directory (Azure AD). Asegúrese de que se pueda
acceder al servicio de dominio desde la suscripción a Azure y la red virtual para conectarse
donde se implementará Windows Virtual Desktop. Siga la guía de Azure AD Connect para
sincronizar Active Directory local con Azure AD.
Paso 2: Configuración de
Azure Migrate
Ahora podemos comenzar a crear el proyecto Azure Migrate. En el portal de Azure, hay un
asistente dedicado que le permitirá configurar Azure Migrate para Windows Virtual Desktop.
Esto se puede encontrar en la sección VDI, tal como se muestra en la figura 4:
Figura 4: Inicio del asistente de Azure Migrate

En este asistente, configurará la suscripción, el grupo de recursos, el nombre del proyecto y la

geografía. Para iniciar la evaluación del entorno de RDS actual, seleccione Register (Registrarse).
En este paso, creará un nuevo proyecto de Azure Migrate en la suscripción a Azure de

destino. Esta suscripción debe coincidir con los requisitos previos descritos en el paso 1. Luego,
seleccione la opción para evaluar y migrar los servidores, seleccione VDI y agregue una
herramienta. Después de configurar los parámetros básicos, como la suscripción, el grupo de
recursos y la ubicación, asegúrese de seleccionar Azure Migrate: Migration Server como
la herramienta de migración. El asistente de configuración también le permitirá seleccionar
herramientas de socios del ecosistema opcionales que proporcionan beneficios adicionales
a la migración del servidor. Según el ejemplo, puede seleccionar Lakeside SysTrack como
su herramienta de evaluación en la parte superior de Azure Migrate como su herramienta de
migración. Lakeside es un socio del ecosistema que se especializa en la evaluación de entornos
RDS y VDI. Lakeside SysTrack proporciona conocimientos detallados sobre su carga de trabajo
actual para ayudarle a determinar el tamaño y el uso. Además de admitir Microsoft RDS,
también es compatible con los entornos de VMware y Citrix y le ayuda a evaluar esos entornos
para la migración a Azure. Después de conectar Azure Migrate y las herramientas de socios del
ecosistema opcionales y de aceptar los permisos solicitados, se inicia el proceso de detección.
Paso 3: Detección de VM
Durante esta fase, se detectará y evaluará el servidor host de la sesión de escritorio remoto
(RD) de su entorno actual. Durante este paso, vamos a reunir mucha información sobre su
infraestructura actual. Si seleccionó Lakeside SysTrack como su herramienta de evaluación en el
paso anterior, esto le ayudará a recopilar aún más información sobre su carga de trabajo actual
de RDS. Lakeside SysTrack requiere un agente que puede instalar fácilmente con sus herramientas
de implementación existentes. La figura 5 muestra el visualizador de Lakeside SysTrack, que hace
que el uso, el consumo y los inventarios de aplicaciones actuales sean fáciles de digerir, le ayuda
a determinar el tamaño de sus VM de Windows Virtual Desktop y mucho más.
Figura 5: Ejemplo del visualizador de Lakeside SysTrack
Como parte de este paso, también recopila información sobre las cargas de trabajo de back-end
de la aplicación que puede que desee o que no desee migrar también a Azure. Por lo general,
la migración de esos back-end de aplicaciones a Azure garantiza el mejor rendimiento porque,
en ese escenario, el lado del cliente de la aplicación que se ejecuta en Windows Virtual Desktop
estará más cerca del back-end de la aplicación. Azure Migrate también puede ayudarlo a migrar
estas cargas de trabajo a Azure. Si decide no migrar algunos de estos recursos de back-end,
asegúrese de configurar la conectividad con su entorno local mediante ExpressRoute o una VPN
de sitio a sitio. Los pasos detallados para la detección se encuentran aquí.
Paso 4: Revisión de la evaluación
Cuando se captura una cantidad suficiente de datos, puede revisar los datos de la evaluación
para determinar la mejor ruta de migración. Estos datos de evaluación incluyen los datos de
evaluación sin procesar del escritorio y los datos desglosados en diferentes roles de usuario.
A medida que analiza los datos, puede determinar el uso más rentable de los recursos tanto
de los recursos agrupados como de los recursos personales de Windows Virtual Desktop.
La información recopilada como parte del paso 3 se puede ver en el portal de Azure. En la
siguiente figura se muestra un ejemplo que contiene información recopilada. Esta incluye
información como la siguiente:
● La cantidad de usuarios en cada rol de usuario
● Las aplicaciones en uso por parte de los usuarios
● El consumo de recursos por parte del usuario
● Promedios de utilización de recursos por rol de usuario
● Datos de rendimiento del servidor de VDI
● Informes de usuarios simultáneos
● Principales paquetes de software en uso
Figura 6: Ejemplo de resultado de evaluación
Los pasos detallados para la evaluación se encuentran aquí.

Con respecto a las VM host de la sesión, en función de los resultados que analizó como parte
de la evaluación y de si desea obtener los beneficios de tener múltiples sesiones de Windows 10
o de seguir usando Windows Server, tiene dos opciones:
Puede optar por migrar ("lift and shift") los servidores host de la sesión de RD locales existentes
a Azure y transformarlos en servidores host de la sesión de Windows Virtual Desktop. En ese
caso, usará la opción Discover (Detectar) de las herramientas de Azure Migrate: Server
Migration. Esta le permite convertir un dispositivo en su entorno, que va a administrar la
replicación de las máquinas, a Windows Virtual Desktop. El proveedor de replicación se descarga,
se instala y se registra en el proyecto de Azure Migrate para iniciar la replicación en Azure. Dado
que la replicación de los hosts en Azure Blob Storage ya se ha iniciado, puede continuar con la
replicación hasta que esté listo para probar las VM y, a continuación, migrarlas a producción.
Cuando las máquinas comiencen a ejecutarse en Azure, asegúrese de instalar el agente de VM
de Windows Virtual Desktop en cada servidor host de la sesión. Como parte de la instalación,
introduzca un token de registro para el entorno de Windows Virtual Desktop, a fin de asociar el
servidor con el entorno correcto. Como último paso antes de la migración final, asigne usuarios
y grupos a los grupos de aplicaciones correspondientes.
También puede optar por crear una nueva imagen de plantilla basada en múltiples sesiones
de Windows 10 para aprovechar todos los beneficios que vienen con el sistema operativo.
Para la creación de una nueva plantilla, las múltiples sesiones de Windows 10 Enterprise están
disponibles en la galería de imágenes de Azure. Hay dos opciones para personalizar esta imagen:
a. La primera opción es aprovisionar una VM en Azure y luego avanzar a la preparación
e instalación del software.
b. La segunda opción es crear la imagen localmente al descargar la imagen, aprovisionar una
VM de Hyper-V y personalizarla para que se adapte a sus necesidades.
Para obtener una guía completa paso a paso sobre cómo preparar, crear e implementar
imágenes de plantilla personalizadas para Windows Virtual Desktop, consulte esta guía.
Antes de continuar con el paso 5, este es el momento de comenzar a crear su entorno de

Windows Virtual Desktop. En este paso, creará los componentes de Windows Virtual Desktop
y preparará su suscripción a Azure. En este paso, se crearán tres objetos diferentes de Azure en su
suscripción a Azure: el grupo host, el área de trabajo y el grupo de aplicaciones. Estos se explican
de la siguiente manera:
● Los grupos host son una colección de una o más VM idénticas dentro de los entornos
de Windows Virtual Desktop. Cada grupo host puede contener un grupo de aplicaciones,
que a su vez contiene una aplicación o un escritorio con el que los usuarios pueden
interactuar como lo harían en un escritorio físico.
● De forma predeterminada, el proceso de configuración del grupo host crea un grupo
de aplicaciones de escritorio. Para que el grupo host funcione según lo previsto, tendrá
que asignar este grupo de aplicaciones a usuarios o grupos de usuarios, y debe registrar
el grupo de aplicaciones en un área de trabajo.
● El grupo de aplicaciones predeterminado creado para un nuevo grupo host de Windows
Virtual Desktop también publica el escritorio completo. Además, puede crear uno o más
grupos de aplicaciones de RemoteApp para el grupo host.
En el capítulo 3, hablaremos de los requisitos previos y las consideraciones importantes para

familiarizarse con anterioridad a la creación de la implementación de Windows Virtual Desktop.
Además, elaboraremos algunos más en las opciones de implementación y lo guiaremos por
el proceso de implementación general.
Creación del entorno de Windows Virtual Desktop

Requisitos previos
Ahora que ha seguido el proceso de migración como parte de los pasos descritos anteriormente,
analizaremos con más detalle la creación del entorno de Windows Virtual Desktop. Antes de
hacerlo, deben cumplir un par de requisitos, los que se analizan en esta sección. Asegúrese de
cumplirlos antes de empezar a implementar Windows Virtual Desktop y de migrar las cargas de
trabajo de RDS.
En términos de sistemas operativos para los servidores host de la sesión como parte de sus grupos
host de Windows Virtual Desktop, hay una lista de sistemas operativos compatibles. En función
del sistema operativo que seleccione, también se requerirán las licencias correspondientes para los
usuarios que se conectan a los escritorios y las aplicaciones. Asegúrese de que todos los usuarios
a los que se les permita el acceso a cualquier recurso dentro de Windows Virtual Desktop tengan
la licencia necesaria. En la tabla 2 se muestran las licencias que se requieren por sistema operativo.
Puede obtener más información sobre las licencias requeridas aquí.
Sistema operativo Licencia requerida
Windows Server 2012 R2, 2016, 2019 Licencia de acceso cliente (CAL) de RDS con Software Assurance
Windows 7 Enterprise Microsoft 365 E3, E5, A3, A5, F3, Business Premium Windows E3, E5, A3, A5
Múltiples sesiones de Windows 10

Microsoft 365 E3, E5, A3, A5, F3, Business Premium Windows E3, E5, A3, A5
Enterprise o Windows 10 Enterprise
Tabla 2: Sistemas operativos y licencias requeridas

Además, su infraestructura necesita lo siguiente para poder admitir Windows Virtual Desktop:
● Una instancia de Azure AD implementada.
● Una instancia de Windows Server AD que esté sincronizada con Azure AD. Puede optar por
implementarla en función de Azure AD Connect (ideal para organizaciones híbridas) o en
función de Azure AD Domain Services (ideal para organizaciones híbridas o en la nube).
En términos de orígenes de identidad y pertenencia a dominios de los servidores host de la
sesión de Windows Virtual Desktop, puede seleccionar entre las siguientes opciones:
- Puede usar Windows Server AD en sincronización con Azure AD y las cuentas de usuario
proceden de Windows Server AD. La VM host de la sesión de Windows Virtual Desktop
se une al dominio de Windows Server AD.
- Puede usar Windows Server AD en sincronización con Azure AD y las cuentas de usuario
proceden de Windows Server AD. La VM host de la sesión de Windows Virtual Desktop
se une a Azure AD Domain Services.
- Puede usar el dominio de Azure AD Domain Services y el usuario proviene de Azure AD.
La VM host de la sesión de Windows Virtual Desktop se une al dominio de Azure AD
Domain Services.
- Se requiere una suscripción a Azure, que debe estar en el mismo inquilino de Azure AD
que contiene la red virtual. La red virtual debe tener acceso a la instancia de Windows
Server AD o de Azure AD Domain Services.
El usuario que se conecta a Windows Virtual Desktop debe cumplir los siguientes requisitos:
● El usuario debe obtenerse del mismo AD que está conectado a Azure AD. Windows Virtual
Desktop no es compatible con cuentas B2B o MSA.
● E
l nombre principal de usuario (UPN) que utiliza para suscribirse a Windows Virtual Desktop
debe existir en el dominio de AD al que se une la VM.
● Las VM host de la sesión de Windows Virtual Desktop que crea como parte de su grupo
host de Windows Virtual Desktop deben estar unidas a un dominio estándar o unidas
a un AD híbrido. Las VM no pueden estar unidas a Azure AD solo en el momento.
La compatibilidad de las VM host de sesión de Windows Virtual Desktop unidas a Azure AD
está planeada para más adelante. Además, como se describió anteriormente, el servidor
host de la sesión de Windows Virtual Desktop debe ejecutar uno de los sistemas operativos
admitidos:
- Múltiples sesiones de Windows 10 Enterprise, versión 1809 o posterior
- Windows 10 Enterprise, versión 1809 o posterior
- Windows 7 Enterprise
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
Windows Virtual Desktop no es compatible con imágenes de sistema operativo x86 (32 bits),
Windows 10 Enterprise N o Windows 10 Enterprise KN. Windows 7 tampoco admite ninguna
solución de perfil de disco duro virtual (VHD) o basada en VHDX hospedada en Azure Storage
administrado. Las opciones de automatización e implementación disponibles dependen del
sistema operativo y la versión que elija, tal como se describe en este artículo sobre los sistemas
operativos compatibles.
Si bloquea activamente el tráfico saliente de los servidores host de la sesión de Windows Virtual
Desktop, deberá desbloquear las URL específicas para que la implementación de Windows
Virtual Desktop funcione correctamente. Las VM de Azure que cree para Windows Virtual
Desktop deben tener acceso a las URL enumeradas en la lista de URL seguras.
Consideraciones
Limitaciones
Al implementar Windows Virtual Desktop, hay un par de limitaciones técnicas que debe tener
en cuenta. Considere y revise estas limitaciones antes de implementar Windows Virtual Desktop
en su entorno. Puede encontrar una lista actualizada de estas limitaciones aquí.
Optimización de costos
Para hacer un uso completo de Windows Virtual Desktop, le recomendamos que considere las
diferentes formas de lograr ahorros de costos. La siguiente lista contiene seis formas de ahorrar
costos en su implementación de Windows Virtual Desktop:
● Haga uso de las múltiples sesiones de Windows 10 como el sistema operativo de sus
servidores host de la sesión de Windows Virtual Desktop. Al aprovechar una experiencia
de escritorio de múltiples sesiones para los usuarios que tienen requisitos de proceso
idénticos, puede permitir que más usuarios inicien sesión en una sola VM a la vez. Esto tiene
como resultado un considerable ahorro de costos en el consumo de Azure para las VM que
se ejecutan. Si desea obtener orientación adicional, las preguntas frecuentes de múltiples
sesiones de Windows 10 Enterprise contienen información más detallada.
● Aproveche el beneficio híbrido de Azure. Si su organización posee Microsoft Software
Assurance, puede utilizar el beneficio híbrido de Azure para Windows Server, a fin
de ahorrar en el costo de su infraestructura de Azure. Para obtener más información,
visite este enlace.
● Las Azure Reserved Instances (RI) pueden reducir considerablemente los costos en hasta
aproximadamente 72 por ciento en comparación con los precios de pago por uso, con
un compromiso de uno o tres años en VM de Windows y Linux. Con las RI, el uso de la
VM se paga por adelantado. De manera óptima, combine las RI con el beneficio híbrido
de Azure (tal como se describió anteriormente) para ahorrar hasta un 80 por ciento en los
precios de lista.
● Puede reducir el costo total de implementación de Windows Virtual Desktop al ampliar
sus VM. Esto significa apagar y anular la asignación de las VM host de la sesión en horarios
de menor demanda, para luego volver a encenderlas y reasignarlas durante las horas punta.
En el capítulo 6 se proporciona información más detallada.
● Al configurar las VM host de la sesión, considere las diferentes opciones de equilibrio de
carga. El modo predeterminado (y el más utilizado) es el equilibrio de carga con predominio
de amplitud. El equilibrio de carga con predominio de amplitud distribuye a los usuarios en
los servidores host de la sesión en función del número de sesiones por host. El equilibrio
de carga con predominio de profundidad llena primero un servidor host de la sesión con
el número máximo de usuarios antes de que pasar al siguiente servidor. En función de su
caso de uso, el equilibrio de carga con predominio de profundidad en primer lugar puede
generar ahorros de costos adicionales, pero en algunos escenarios, es posible que esto no
sea suficiente para enfrentar los problemas de inicio de sesión del usuario. Puede ajustar esta
configuración para obtener los máximos beneficios de costo. Para obtener información más
detallada sobre las opciones de equilibrio de carga, visite este enlace.
Pautas de red
La recomendación general es diseñar sus redes de Azure con una topología tipo hub-and-spoke
(de centro y radio). Considere el "hub" (centro) como una red perimetral (DMZ) implementada
con sus gateways de red virtual y otros dispositivos de seguridad/perímetro, como firewalls,
entre otros, mientras que el "spoke" (radio) actuará como la zona de back-end donde se
implementarán los servidores host de la sesión y se emparejarán con el centro. Consulte a su
equipo de red durante esta fase para una implementación óptima.
El ancho de banda disponible del cliente local para los componentes de la placa posterior
de Windows Virtual Desktop, o más específicamente el componente de gateway dentro de
Windows Virtual Desktop, desempeña un papel importante en la experiencia general que
percibe el usuario final. En la tabla 3 se muestran los anchos de banda mínimos recomendados
para una experiencia de usuario sin problemas.
Tipo de carga de trabajo Ancho de banda recomendado
Ligero 1.5 Mbps
Medio 3 Mbps
Intenso 5 Mbps
Potente 15 Mbps
Tabla 3: Anchos de banda mínimos recomendados
Tenga en cuenta que los factores externos también pueden aumentar el ancho de banda
que se está utilizando. Por ejemplo, si aumenta la velocidad de fotogramas o la resolución de
pantalla, también aumentará el requerimiento de ancho de banda. Los anchos de banda en
la tabla 3 son valores recomendados que variarán en función de las aplicaciones consumidas
y del caso de uso específico de Windows Virtual Desktop que implemente. Se aconseja realizar
siempre la evaluación comparativa y las pruebas para confirmar los valores promedio para la
implementación de Windows Virtual Desktop.
La resolución de pantalla que se usa también afecta el ancho de banda disponible. La tabla 4
contiene una lista de anchos de banda recomendados para permitir una experiencia de usuario
sin problemas basada en una velocidad de 30 fotogramas por segundo (FPS).
Resoluciones de pantalla típicas a 30 fps Ancho de banda recomendado
Aproximadamente 1024×768 píxeles 1.5 Mbps
Aproximadamente 1280×720 píxeles 3 Mbps
Aproximadamente 1920×1080 píxeles 5 Mbps
Aproximadamente 3840×2160 píxeles (4K) 15 Mbps
Tabla 4: Resoluciones de pantalla típicas y anchos de banda recomendados
Pautas de administración de perfiles

Si su implementación actual de RDS hace uso del disco de perfil de usuario (UPD) o de perfiles
móviles como la solución de administración de perfiles, tenga en cuenta que debe migrar
o realizar la transición a los contenedores de perfiles FSlogix. Esto se debe a que el UPD no es
compatible con Windows Virtual Desktop. La migración de perfiles del UPD a los contenedores
de perfiles FSLogix se puede realizar manualmente o mediante un método de su elección,
pero para proporcionar una buena ruta de migración entre su solución de perfil existente y el
contenedor de perfiles, hemos creado un script de migración que actualmente está disponible
como vista previa privada.*
Múltiples sesiones de Windows 10

Si hoy tiene una implementación de RDS que se ejecuta localmente y desea migrar a Windows
Virtual Desktop, está usando una versión de Windows Server como sistema operativo para los
servidores host de la sesión de RD. Esto se debe a que las múltiples sesiones de Windows 10 no
se admiten fuera de Windows Virtual Desktop. Como parte de esta migración, puede migrar
los servidores host de la sesión de RD existentes. Windows Server 2012 R2 y cualquier versión
anterior es compatible con Windows Virtual Desktop. Sin embargo, por varios motivos, como se
describe en el capítulo 1, aprovechar las múltiples sesiones de Windows 10 proporciona muchos
beneficios adicionales, los que incluyen un ahorro de costos, dado que ya no se requiere una
CAL de RDS. Para optimizar por completo Windows Virtual Desktop y Azure, le recomendamos
volver a compilar sus imágenes para múltiples usuarios de Windows 10. En este artículo se explica
cómo preparar una imagen maestra de disco duro virtual (VHD) para cargarla en Azure, lo que
incluye cómo crear VM e instalar software en ellas. Le recomendamos que siga este artículo para
aprovechar plenamente las capacidades de Windows Virtual Desktop.
* La vista previa privada para la conversión de contenedores UPD a FSLogix para Windows Virtual Desktop se proporciona sin un contrato de nivel de servicio, y no se
recomienda para las cargas de trabajo de producción. Es posible que algunas características no sean compatibles o que tengan capacidades restringidas. Es posible
que los contenedores de perfiles FSLogix no admitan toda la funcionalidad de los formatos que se convierten. Para obtener más información, consulte los Términos
de uso complementarios para las vistas previas de Microsoft Azure.
Convenciones de nomenclatura
Con cualquier suscripción a Azure, es importante tener una convención de nomenclatura sólida.
La siguiente lista contiene consideraciones con respecto a las convenciones de nomenclatura:
● Una convención de nomenclatura eficaz reúne los nombres de recursos mediante el uso
de información de recursos importante como parte del nombre de un recurso. Cuando
cree su convención de nomenclatura, identifique los elementos clave de la información que
desea que se reflejen en un nombre de recurso.
● Cada carga de trabajo puede constar de muchos recursos y servicios individuales.
La incorporación de prefijos de tipo de recurso en los nombres de los recursos facilita
la identificación visual de componentes de una aplicación o un servicio.
● Al aplicar etiquetas de metadatos a los recursos de la nube, puede incluir la información
sobre esos activos que no se pudo incluir en el nombre del recurso.
Si no tiene una convención de nomenclatura existente para su suscripción, siga las instrucciones
de este enlace para mantener una convención de nomenclatura coherente en todos sus recursos.
Orientación de implementación
Después de haber evaluado los requisitos previos y las consideraciones tal como se describe en
las dos secciones anteriores, está listo para implementar los objetos de Windows Virtual Desktop
necesarios en su suscripción a Azure.
Empiece por implementar un grupo host. Los grupos host son una colección de una o más VM
idénticas dentro de los entornos de Windows Virtual Desktop. Para crear el grupo host, decida un
nombre único en un grupo de recursos y proporcione la región de Azure.
Figura 7: El asistente para crear un grupo host en el portal de Azure
La geografía de Azure asociada con las regiones que seleccionó es donde se almacenarán los
metadatos de este grupo host y sus objetos relacionados. Asegúrese de elegir las regiones
dentro de la geografía en la que desea que se almacenen los metadatos del servicio. En Host
pool type (Tipo de grupo host), seleccione si el grupo host será Personal o Pooled (Agrupado).
Si elige Pooled (Agrupado), escriba un límite máximo de sesiones y un algoritmo de equilibrio
de carga. Antes de finalizar la creación del grupo host, puede determinar si crear nuevas VM
basadas en una nueva imagen de plantilla o no crearlas aún para migrarlas posteriormente
desde su implementación de RDS local. En el capítulo 2, tratamos esta opción con mayor
detalle. Para obtener una descripción técnica detallada de la implementación de grupos host,
visite esta página.
De forma predeterminada, el proceso de configuración del grupo host crea un grupo de

aplicaciones de escritorio. Para que el grupo host funcione según lo previsto, tendrá que
asignar este grupo de aplicaciones a usuarios o grupos de usuarios, y debe registrar el grupo
de aplicaciones en un área de trabajo.
Figura 8: Creación del grupo de aplicaciones
Si selecciona No, puede registrar el grupo de aplicaciones en otro momento, pero le

recomendamos que obtenga el registro del área de trabajo tan pronto como sea posible para
que el grupo host funcione correctamente. Elija si desea crear una nueva área de trabajo
o selecciónela entre las áreas de trabajo existentes. Solo las áreas de trabajo creadas en la misma
ubicación que el grupo host podrán elegirse para registrar el grupo de aplicaciones.
Figura 9: Creación del área de trabajo

Revise la información sobre su implementación para asegurarse de que todo se vea correcto.
Cuando esté listo, seleccione Create (Crear). Esto inicia el proceso de implementación, que crea
los siguientes objetos:
● Un nuevo grupo host.
● Un grupo de aplicaciones de escritorio.
● Un área de trabajo, si decide crearla.
● Si decide registrar el grupo de aplicaciones de escritorio, el registro quedará completo.
● Un enlace de descarga para una plantilla de administración de recursos de Azure basada
en su configuración.
Ahora que ha creado el grupo host, puede rellenarlo con programas RemoteApp o con un
escritorio por grupo host. El grupo de aplicaciones predeterminado creado para un nuevo grupo
host de Windows Virtual Desktop también publica el escritorio completo. Además, puede crear
uno o más grupos de aplicaciones de RemoteApp para el grupo host. Solo puede crear grupos de
50 aplicaciones para cada inquilino de Azure AD. Agregamos este límite debido a las limitaciones
de servicio para recuperar fuentes para nuestros usuarios. Para obtener una descripción técnica
detallada de la implementación de grupos de aplicaciones, visite este enlace.
Anteriormente, completamos los pasos 1 al 4 y, en la sección anterior, creamos nuestra

implementación de Windows Virtual Desktop. Ahora estamos listos para iniciar la replicación
de los servidores host de la sesión de RD a Azure (paso 5) y para hacerlos parte de la
implementación de Windows Virtual Desktop, realizar una migración de prueba (paso 6) y migrar
a producción (paso 7).
1 2 3 4
5 6 7
Migración para
Replicación de VM Migración de prueba la producción
Figura 10: Pasos 5, 6 y 7

Paso 5: Replicación de VM
En este paso, replicaremos los servidores host de la sesión de RD desde el entorno local a Azure
para permitirnos agregar los servidores replicados a nuestra implementación de Windows Virtual
Desktop creada. Puede comenzar la replicación de VM a Azure. En el proyecto Azure Migrate,
haga clic en Replicate (Replicar) en Server Migration (Migración de servidor). Si ha ejecutado
una evaluación para las VM, puede aplicar las recomendaciones de tamaño de la VM y de tipo de
disco (premium/estándar) de los resultados de la evaluación. Busque las VM según sea necesario
y revise cada VM que desea migrar. Habilite el beneficio híbrido de Azure si tiene máquinas con
Windows Server cubiertas con suscripciones de Software Assurance o Windows Server activas
y desea aplicar el beneficio a las máquinas que está migrando. Una vez finalizada la replicación
inicial, comenzará la replicación diferencial. Los cambios incrementales en los discos locales se
replican periódicamente en Azure. Puede hacer un seguimiento del estado del trabajo en las
notificaciones del portal.
Los pasos detallados para la replicación se encuentran aquí.
Como se analizó anteriormente, es posible que en algunos escenarios no desee migrar sus VM
existentes, sino crear una nueva plantilla de VM; por ejemplo, si desea aprovechar las múltiples
sesiones de Windows 10, que solo están disponibles como parte de Windows Virtual Desktop.
En este artículo se explica cómo preparar una nueva imagen maestra. En este caso, la información
recopilada durante la fase de evaluación será de gran ayuda para informarle cómo componer sus
imágenes y configurar el entorno de su aplicación.
Paso 6: Migración de prueba
Cuando la replicación diferencial comienza como parte del paso 6, puede ejecutar una migración
de prueba para las VM, antes de ejecutar una migración completa a Azure. Le recomendamos
encarecidamente que haga esto al menos una vez por cada servidor host de la sesión de RD
antes de migrarlo. Ejecutar una migración de prueba comprueba que la migración funcionará
según lo esperado, sin afectar a las máquinas locales, que se mantienen operativas y continúan
replicándose. En Migration goals (Objetivos de migración), seleccione Servers (Servidores),
luego Azure Migrate and Server Migration (Azure Migrate y Server Migration) y haga clic en
Test migrated servers (Probar servidores migrados). Supervise el trabajo en las notificaciones
del portal.
Los pasos detallados para la migración de prueba se encuentran aquí.

Paso 7: Migración para la producción
Una vez que haya verificado que la migración de prueba funciona según lo esperado, puede
migrar los servidores host de la sesión de RD locales. En el área Replicating machines
(Replicación de máquinas), haga clic con el botón secundario del mouse sobre la VM y luego
haga clic en Migrate (Migrar). De forma predeterminada, Azure Migrate apaga la VM local
y ejecuta una replicación on-demand para sincronizar cualquier cambio de VM que se hubiera
producido desde la última replicación. Esto garantiza que no se produzcan pérdidas de datos.
Se inicia un trabajo de migración para la VM. Realice seguimiento del trabajo en las notificaciones
de Azure. Una vez finalizado el trabajo, puede ver y administrar la VM desde la página Virtual
Machines (Máquinas virtuales). Después de completar la migración, use la opción Stop
migration (Detener la migración). Este proceso detiene la replicación de la máquina local
y elimina la máquina del recuento de replicación de servidores en Azure Migrate.
Los pasos detallados para la migración para la producción se encuentran aquí.
1 2 3 4
5 6 7
Replicación de VM Migración de prueba Migración para
la producción
Figura 11: Los siete pasos completados
Hemos completado el proceso de siete pasos de Azure Migrate. En el capítulo 4, seguiremos

explicando cómo hacer más pruebas y preparar de mejor manera su entorno de Windows
Virtual Desktop, y en el capítulo 5 le proporcionaremos orientación sobre cómo llevar a cabo
la implementación y le recomendaremos pasos posteriores a la implementación.
Pruebas y preparación para la implementación

de Windows Virtual Desktop
Confirmación del estado de implementación de Windows Virtual Desktop
La región en la que se encuentra puede tener efectos tanto en la experiencia del usuario como
en las condiciones de la red. El cliente de Windows Virtual Desktop, basado en la información
de los DNS, siempre dirigirá la conexión del usuario a la región de Azure más cercana que tenga
componentes de placa posterior de Windows Virtual Desktop. Para determinar qué región
de Azure funciona mejor para su ubicación específica, explore el Estimador de experiencia de
Windows Virtual Desktop. Este le permite estimar la calidad de la experiencia que recibirán los
usuarios al conectarse a Windows Virtual Desktop. Mide y estima el tiempo de ida y vuelta
(RTT) de la conexión desde su ubicación actual, a través del servicio de Windows Virtual
Desktop, a cada región de Azure en la que puede implementar VM como parte de su grupo host
de Windows Virtual Desktop.
Figura 12: Ejemplo del resultado del Estimador de experiencia de Windows Virtual Desktop
Se resalta la región de Azure con el RTT de conexión más bajo con relación a su ubicación actual.
Tenga en cuenta que los tiempos que se muestran son estimaciones que tienen como finalidad
ayudar a evaluar la experiencia del usuario final percibida y la calidad de la implementación
de Windows Virtual Desktop. La experiencia real variará en función de otras condiciones,
por ejemplo, otras especificaciones de la red, el dispositivo del usuario final y la configuración
de las VM implementadas.
Estado del grupo host de Windows Virtual Desktop

El portal de Azure ofrece una manera sencilla para determinar el estado de sus grupos host de
Windows Virtual Desktop. Cuando esté dentro del portal de Azure, diríjase a Windows Virtual
Desktop, haga clic en Host pools (Grupos host) y abra el grupo host correspondiente. El estado
de todos los servidores host de la sesión individual de Windows Virtual Desktop debe estar
Available (Disponible) si está activado.
Figura 13: El estado del servidor host de la sesión de Windows Virtual Desktop está Available (Disponible)
Orientación para realizar pruebas de las implementaciones de Windows

Virtual Desktop
Una vez que haya confirmado el estado de su entorno de Windows Virtual Desktop, puede
comenzar a probar la implementación.
Ahora que ha creado el grupo host, puede rellenarlo con programas RemoteApp o con un
escritorio por grupo host. El grupo de aplicaciones predeterminado creado para un nuevo grupo
host de Windows Virtual Desktop también publica el escritorio completo. Además, puede crear
uno o más grupos de aplicaciones de RemoteApp para el grupo host. Use el portal de Azure
para personalizar la implementación de Windows Virtual Desktop mediante la publicación de
aplicaciones, la asignación de usuarios y la configuración de opciones del grupo host.
Puede acceder a los recursos de Windows Virtual Desktop en dispositivos con Windows
7, Windows 10 y Windows 10 IoT Enterprise con el cliente de Windows Desktop. Además
de la plataforma Windows, también puede aprovechar los clientes Android, iOS, macOS
y web. La siguiente lista contiene enlaces a los diversos clientes y guías para la instalación, la
configuración y el uso del cliente:
● Conéctese con el cliente de Windows Desktop
● Conéctese con el cliente web
● Conéctese con el cliente Android
● Conéctese con el cliente macOS
● Conéctese con el cliente iOS
En la figura 14 se muestra un ejemplo del cliente Windows de Windows Virtual Desktop, que
contiene escritorios publicados y RemoteApps.
Figura 14: Ejemplo de cliente de Windows Virtual Desktop
Si presenta problemas de conexión en este punto, consulte esta página, que contiene escenarios
de errores comunes, errores de administración y códigos de error de conexión externos.
Preparativos finales para la implementación

La adaptación del usuario es una parte clave de cada proyecto de TI que implica cambios para
los usuarios finales. Aunque los usuarios podrán tener acceso a sus aplicaciones y escritorios
publicados como antes, debe preparar minuciosamente la adopción de Windows Virtual Desktop
por parte de los usuarios. Los usuarios requieren capacitación, manuales y recursos del estilo
de preguntas frecuentes como ayuda para el servicio de Windows Virtual Desktop en todo su
potencial. El acceso a escritorios y aplicaciones de Windows Virtual Desktop es un poco diferente
en comparación con los RDS, ya que los usuarios deben pasar por un registro inicial único en su
dispositivo. Asegúrese de que los usuarios tengan las instrucciones correctas e incorporen enlaces
a los diversos clientes de Windows Virtual Desktop, tal como se describe en el capítulo anterior.
Implementación y pasos posteriores a la implementación

Confirmación del estado y uso de Windows Virtual Desktop
Una vez que haya migrado a Windows Virtual Desktop, investigue el uso y el estado de Windows
Virtual Desktop de su entorno. Durante la fase de preparación, hemos determinado qué tamaño
de VM utilizar para las VM host de la sesión e investigado el uso del entorno mediante la
recopilación de datos de telemetría de los recursos que se consumieron; por ejemplo, mediante
la implementación de Log Analytics, tal como se describe en la sección Supervisión, más adelante.
Esto le permite obtener información sobre cuántos usuarios aprovechan las aplicaciones y los
escritorios publicados de Windows Virtual Desktop, y le proporciona datos de telemetría sobre el
consumo de recursos. Use esta información para volver a ampliar los servidores host de la sesión
según sea necesario.
Tal como se explicó en el capítulo anterior, el estado de todos los servidores host de la sesión
individual de Windows Virtual Desktop debe estar Available (Disponible). Investigue el estado
de todos los servidores host de la sesión para asegurarse de que todos estén conectados
y funcionen correctamente. Tenga en cuenta que si implementó el escalado automático, como
se explica en el capítulo 6, las VM que actualmente están reducidas aparecen como Unavailable
(No disponible), pero no es necesario que haga nada.
Recopile información sobre cuántos usuarios están utilizando activamente Windows Virtual
Desktop y recopile información sobre los diagnósticos para enterarse de qué sesiones
presentaron errores de conexión. Investigue estos errores y realice un seguimiento de las
correcciones sugeridas.
Azure Advisor le proporciona información sobre su entorno de Windows Virtual Desktop y lo

guía a los procedimientos recomendados que podría haber perdido durante la implementación.
Investigue de cerca las recomendaciones que contiene Azure Advisor e implemente los
procedimientos recomendados sugeridos que se muestran allí.
En la figura 15 se muestra un ejemplo de Azure Advisor que proporciona pautas para Windows
Virtual Desktop.
Figura 15: Ejemplo de Azure Advisor for Windows Virtual Desktop
Consideraciones y pasos posteriores a la implementación

Una vez que haya puesto en marcha la implementación de Windows Virtual Desktop, se recomienda
considerar y planificar los pasos posteriores a la implementación. En un paso anterior, confirmó
el estado y el uso de la implementación de Windows Virtual Desktop, pero se recomienda
supervisar ese estado de forma continua. Considere la implementación de supervisión basada
en Azure Monitor y Log Analytics, tal como se describe en la sección Supervisión más adelante.
La seguridad es una parte importante de Windows Virtual Desktop. Es posible que haya utilizado la
autenticación multifactor (MFA) en la implementación de RDS. Este es un buen momento para
considerar la incorporación de acceso condicional a su implementación. Dado que Windows Virtual
Desktop se basa en Azure AD, esta es una tarea relativamente fácil. Describimos esta tarea en la
sección Acceso condicional, más adelante. Cuando empiece a hacer uso de Windows Virtual Desktop,
considere otros escenarios que pueden obtener beneficios de esta implementación. Por ejemplo,
puede permitir que los administradores tengan acceso remoto a su entorno para realizar tareas
de mantenimiento. Puede que actualmente use una solución VPN para eso. Los administradores
también pueden aprovechar Windows Virtual Desktop mediante el acceso seguro a un servidor
de administración central (host de salto). Es importante planificar tareas de escalado automático
y actualización de las VM host de la sesión continuas como parte de su grupo host. Automatice estas
actualizaciones como se describe en la sección Escalado automático, a continuación.
Limpieza de una implementación de RDS

Una vez que haya migrado correctamente la implementación de RDS a Windows Virtual Desktop,
también se aconseja limpiar la implementación de RDS. Es importante investigar, planificar
y ejecutar exhaustivamente esta limpieza para asegurarse de que no queden abandonados
componentes ni configuraciones. Hay un par de áreas donde se recomienda la limpieza del
entorno de RDS:
● Es obvio que las VM de la implementación de RDS se pueden eliminar. Las VM que ejecutan
sus roles de infraestructura de RDS, como el agente de conexión a RD, el acceso web de RD
y el gateway de RD, ya no son necesarias. Las VM host de la sesión de RD se han migrado
a Azure como parte de la migración a Windows Virtual Desktop y también se pueden
eliminar. Un procedimiento recomendado es exportar los valores de su configuración
de RDS, como, por ejemplo, las aplicaciones publicadas, las opciones de redirección, etc.
para asegurarse de que cuenta con esa información en caso de que desee comparar la
configuración de Windows Virtual Desktop en una etapa posterior. Puede que también sea
una buena idea hacer una instantánea o una copia de seguridad de uno de sus servidores
host de la sesión de RD en caso de que experimente un comportamiento inesperado con
aplicaciones o configuraciones dentro de los servidores host de la sesión como parte de
Windows Virtual Desktop en una etapa posterior, y que desee comparar la configuración
con la implementación de RDS anterior.
● La implementación de RDS también habrá utilizado diversos registros de DNS que
probablemente se crearon en servicios de DNS públicos y privados. Se utilizaron registros
de DNS tipo A para acceder al agente de conexión a RD, el gateway de RD y el acceso web
de RD. Lo más probable es que también usó registros TXT de DNS para permitir que la
miniaplicación de panel de control de RemoteApp and Desktop Connections (RADC)
configure automáticamente la URL de la fuente web en función de la dirección de correo
electrónico de un usuario. Estos registros de DNS ahora se pueden eliminar de forma
segura, ya que ya no son necesarios para Windows Virtual Desktop.
● Todos los componentes de infraestructura de la implementación de RDS, incluidos
los servidores host de la sesión de RD reales, son parte de su AD Domain Services
interno. Dado que ya quitamos las VM de infraestructura, los objetos de equipo de AD
correspondientes, incluidas sus entradas de DNS, también se pueden eliminar. Si puede
o no eliminar además el objeto de equipo del servidor host de la sesión de RD dependerá
de cómo migró esas cargas de trabajo. Si migró las VM por sí mismas, está reutilizando esos
objetos de equipo y no debe eliminarlos. Si realizó la migración en función de un nuevo
conjunto de VM en Azure, por ejemplo, como parte de su migración de Windows Server
a múltiples sesiones de Windows 10, es muy probable que también utilice nuevos nombres
y objetos de equipo, lo que significa que puede eliminar los objetos antiguos.
Orientación sobre capacidades adicionales

Escalado automático
Como se mencionó brevemente en el capítulo 3, al escalar automáticamente las VM host de la
sesión, puede reducir el costo total de implementación de Windows Virtual Desktop. El escalado
automático de Windows Virtual Desktop garantiza que se apague y se anule la asignación de las
VM host de la sesión en horarios de menor demanda, y que luego estas se vuelven a encender
y asignar durante las horas punta. La herramienta de escalado le proporciona una opción de
automatización de bajo costo para un escenario en el que desea optimizar los costos de VM host
de la sesión.
La herramienta de escalado automático que proporciona Microsoft le ayudará a automatizar

y programar las VM host de la sesión para que se inicien y se detengan en función de las horas
punta y los horarios de menor demanda que usted defina como parámetros. Las siguientes dos
acciones se llevarán a cabo después de haber configurado el escalado automático:
● L a herramienta de escalado automático escalará horizontalmente las VM host de la sesión
en función del número de sesiones por vCPU definidas como uno de los parámetros.
● L a herramienta de escalado automático escalará verticalmente las VM en los horarios de
menor demanda, dejando el número mínimo de VM host de la sesión que se ejecutan
definido como uno de los parámetros.
En las siguientes secciones se proporcionan más detalles sobre las horas punta y de menor
demanda.
Durante las horas punta, el trabajo comprueba el número actual de sesiones y la capacidad de
la VM host de la sesión en ejecución para cada grupo host. Utiliza esta información para calcular
si las VM host de la sesión en ejecución pueden admitir sesiones existentes en función del
parámetro SessionThresholdPerCPU.
Durante los horarios de menor demanda, el trabajo determina cuántas VM host de la sesión
deben apagarse en función del parámetro MinimumNumberOfRDSH. A continuación, el trabajo
notificará a los usuarios que han iniciado sesión que deben guardar su trabajo y esperar la cantidad
de tiempo configurada. Entonces, se obligará a los usuarios a cerrar sesión. Una vez que se hayan
cerrado todas las sesiones de usuario en la VM host de la sesión, el trabajo apagará la VM. Después
de que la VM se apague, el trabajo reiniciará el modo de purga del host de la sesión.
En cualquier momento, el trabajo también toma en cuenta el valor MaxSessionLimit del grupo
host para determinar si el número actual de sesiones es superior al 90 por ciento de la capacidad
máxima. El trabajo se ejecuta con regularidad en función de un intervalo de periodicidad
establecido. Puede personalizar este intervalo en función del tamaño del entorno de Windows
Virtual Desktop. Tenga en cuenta que el inicio y el apagado de las VM pueden tardar un poco, así
que recuerde considerar el retraso. El intervalo de periodicidad recomendado es cada 15 minutos.
Actualmente, la herramienta también tiene las siguientes limitaciones que debe tener en cuenta:
● La herramienta de escalado automático solo se aplica a las VM host de la sesión de
múltiples sesiones agrupadas. Los hosts de Windows Virtual Desktop asignados por
personal no se pueden escalar automáticamente con esta herramienta.
● La herramienta de escalado automático administra las VM en cualquier región; sin
embargo, solo se puede usar en la misma suscripción que la cuenta de Azure Automation
y Azure Logic App (el objeto de Azure del que consta la herramienta de escalado
automático).
● Si iniciar o detener las VM en el grupo host tarda más de tres horas, se producirá un error
en el trabajo.
Para empezar a usar el escalado automático, siga esta guía.
Acceso condicional
Como se mencionó brevemente en el capítulo 1, Windows Virtual Desktop se basa en Azure AD.
Esto significa que Windows Virtual Desktop puede aprovechar al instante todas las características
de seguridad de Azure AD. En la mayoría de los entornos de producción, recomendamos
configurar el acceso condicional para Windows Virtual Desktop. Esto le permite definir requisitos
de seguridad adicionales que la sesión de un usuario debe cumplir antes de poder obtener
acceso a las aplicaciones y los escritorios publicados.
Un ejemplo de acceso condicional común es Azure MFA. Después de configurar Azure MFA,
cuando un usuario inicia sesión, el cliente le pide su nombre de usuario y contraseña, seguido
de un mensaje de Azure MFA. Cuando selecciona Remember me (Recordarme), los usuarios
pueden iniciar sesión después de reiniciar el cliente sin necesidad de volver a escribir sus
credenciales. Estas credenciales se almacenan en el administrador de credenciales local. Esto
último se aplica al uso del cliente Windows de Windows Virtual Desktop; otros clientes de
Windows Virtual Desktop podrían mostrar una experiencia diferente según la plataforma
y la versión del cliente. Si bien recordar las credenciales es cómodo, también puede que las
implementaciones en escenarios empresariales o en dispositivos personales sean menos seguras.
Para proteger a los usuarios, debe asegurarse de que el cliente siempre solicite credenciales de
Azure MFA. Para obtener más información sobre los ajustes y la configuración de Azure MFA
para Windows Virtual Desktop, diríjase aquí.
Supervisión
Al igual que muchos otros servicios de Azure, Windows Virtual Desktop también puede usar
Azure Monitor para fines de supervisión y alertas. Esto permite a los administradores de
Windows Virtual Desktop identificar problemas a través de una interfaz y un panel consolidados.
Azure Monitor y Log Analytics pueden recopilar registros de actividad de las acciones
administrativas y del usuario final. Cada registro de actividad capturado se clasifica en una de las
siguientes categorías:
● Administración de administración
● Fuente
● Conexiones
● Registro de host
● Errores
● Puntos de control
Las conexiones que no lleguen a Windows Virtual Desktop no aparecerán en los resultados de
diagnóstico, ya que el propio servicio de rol de diagnóstico forma parte de Windows Virtual
Desktop. Pueden producirse problemas de conexión de Windows Virtual Desktop cuando el
usuario experimenta problemas de conectividad de red.
Azure Monitor le permite analizar la información consolidada de su implementación de Windows

Virtual Desktop, así como datos de telemetría sobre las VM host de la sesión. Al definir los
contadores de rendimiento, puede crear un panel personalizado. Azure Monitor también permite
a los administradores crear paneles personalizados y compartirlos con otros administradores de
Azure. Se puede acceder a estos paneles de forma fácil y cómoda desde el portal de Azure.
La siguiente captura de pantalla muestra un ejemplo de resultado de Azure Monitor y Log

Analytics para Windows Virtual Desktop.
Figura 16: Ejemplo de Azure Monitor for Windows Virtual Desktop
Para empezar a trabajar con Azure Monitor para Windows Virtual Desktop, use esta guía.
Automatización
Windows Virtual Desktop se basa completamente en Azure Resource Manager (ARM).
Esto también significa que puede aprovechar varias formas de automatizar la implementación
y el mantenimiento de Windows Virtual Desktop. Para la automatización con ARM, Microsoft
proporciona y mantiene una ubicación en GitHub donde puede recuperar scripts de
automatización para varias tareas.
ARM le permite definir la infraestructura que debe implementarse en el código. El código

de infraestructura se convierte en parte de su proyecto. Al igual que el código de la aplicación,
almacena el código de infraestructura en un repositorio de origen y crea una versión de este.
Cualquier persona de su equipo puede ejecutar el código e implementar entornos similares.
Para implementar la infraestructura como código para sus soluciones de Azure, use las
plantillas de ARM. La plantilla es un archivo JavaScript Object Notation (JSON) que define la
infraestructura y la configuración de su proyecto. La plantilla utiliza la sintaxis declarativa, que le
permite indicar lo que pretende implementar sin tener que escribir la secuencia de comandos
de programación para crearla. En la plantilla, especifica los recursos que se implementarán y las
propiedades de esos recursos. Puede obtener más información sobre las plantillas de ARM aquí.
Hay plantillas de ARM disponibles para crear y actualizar grupos hosts de Windows Virtual
Desktop, para configurar el escalado automático y mucho más. El repositorio de GitHub principal
se puede encontrar aquí.
Azure Advisor
Azure Advisor puede ayudar a los usuarios a resolver problemas comunes en Windows Virtual
Desktop. Estas recomendaciones pueden reducir la necesidad de enviar solicitudes de ayuda,
lo que le ahorrará tiempo y costos. Azure Advisor analiza sus configuraciones y su telemetría
para ofrecer recomendaciones personalizadas para resolver problemas comunes. Con estas
recomendaciones, puede optimizar sus recursos de Azure para la confiabilidad, la seguridad,
la excelencia operativa, el rendimiento y el costo.
Asegúrese de revisar sus recomendaciones con frecuencia, al menos más de una vez a la semana.
Siempre intente resolver los problemas con el nivel de prioridad más alto en Azure Advisor. Si una
recomendación parece menos importante, puede descartarla o posponerla. Cuando observe un
problema en Windows Virtual Desktop, siempre revise primero Azure Advisor. Azure Advisor le
dará instrucciones para resolver el problema o, al menos, lo guiará hacia un recurso que puede
resultarle útil. Para obtener más información sobre cómo acceder y configurar Azure Advisor
para Windows Virtual Desktop, visite este enlace.
Microsoft Teams
Microsoft Teams en Windows Virtual Desktop admite el chat y la colaboración de forma
predeterminada. Con las optimizaciones de elementos multimedia para Windows Virtual
Desktop, también es compatible con la funcionalidad de llamadas y reuniones. Con la
optimización de elementos multimedia instalada y configurada para Microsoft Teams, el cliente
de Windows Desktop maneja localmente el audio y el video de las llamadas y reuniones de
Teams. Actualmente, las optimizaciones de elementos multimedia se limita únicamente al
cliente Windows Virtual Desktop. Sin embargo, aún puede usar Microsoft Teams en Windows
Virtual Desktop con otros clientes sin llamadas y reuniones optimizadas. Las características de
chat y colaboración de Teams son compatibles con todas las plataformas, sin limitaciones. Para
obtener más información sobre cómo habilitar y configurar las optimizaciones de elementos
multimedia, siga este enlace.
Actualmente hay un par de limitaciones para usar el cliente de escritorio de Teams en entornos
de Windows Virtual Desktop. Visite este enlace para familiarizarse con las limitaciones actuales.
Conexión de aplicaciones MSIX

Para mejorar la experiencia de paquete de todas las aplicaciones de Windows, se introdujo MSIX
como un nuevo formato de paquete que ofrece muchas características excelentes. La conexión
de aplicaciones MSIX es una forma de entregar aplicaciones MSIX a máquinas físicas y virtuales.
En una implementación de Windows Virtual Desktop, la conexión de aplicaciones MSIX crea una
separación completa entre los datos de usuario, el sistema operativo y las aplicaciones mediante
el uso de MSIX dentro de un contenedor virtual. Elimina la necesidad de volver a hacer paquetes
porque puede aprovechar los paquetes MSIX existentes. El uso de la aplicación de conexión de
aplicaciones MSIX puede estar disponible para el servidor host de la sesión de Windows Virtual
Desktop y para el usuario de una manera rápida y eficiente. Tanto para el sistema operativo como
para el usuario, una aplicación de conexión de aplicaciones MSIX se trata como cualquier otra
aplicación MSIX.
Hay algunas cosas que debe tener implementadas antes de poder poner en marcha la conexión
de aplicaciones MSIX:
● Debe tener, como mínimo, Windows 10 versión 2004 como sistema operativo del servidor
host de la sesión de Windows Virtual Desktop.
● Es necesario contar con una implementación de Windows Virtual Desktop funcional.
● Idealmente, aprovechará la conexión de aplicaciones MSIX con las aplicaciones MSIX nativas
proporcionadas por el proveedor de la aplicación. Consulte más información al proveedor
de la aplicación. Si no se proporciona una aplicación MSIX nativa, también puede utilizar la
herramienta de paquetes MSIX para transformar las aplicaciones existentes (MSI, EXE, etc.)
en paquetes MSIX.
● Un recurso compartido de red en la implementación de Windows Virtual Desktop, donde
se almacenará el paquete MSIX. Este recurso compartido de red se puede basar en un
servidor de archivos de IaaS de Azure y en Azure Files.
Puede encontrar más información sobre la configuración de la conexión de aplicaciones MSIX

para Windows Virtual Desktop aquí.
Conclusión
Resumen
En el capítulo 1, presentamos los beneficios de aprovechar la VDI en la nube para su estrategia
de trabajo remoto y los motivos para migrar a Windows Virtual Desktop. Hablamos de las
ventajas desde una perspectiva de costos y proporcionamos una introducción al servicio
de Windows Virtual Desktop. Además, presentamos el plan de siete pasos para migrar RDS
a Windows Virtual Desktop aprovechando Azure Migrate. En el capítulo 2, abordamos con
más detalle los cuatro primeros pasos del plan de siete pasos y le ofrecimos orientación sobre
cómo ejecutar estos pasos. En el capítulo 3 se trató la creación de un entorno de Windows
Virtual Desktop, además de los tres pasos restantes del plan. En el capítulo 4 hablamos de
realizar pruebas al entorno de Windows Virtual Desktop y prepararlo para su implementación.
En el capítulo 5, abarcamos la implementación y ofrecimos orientación sobre los pasos
posteriores a la implementación. En el capítulo 6, ofrecimos orientación sobre las capacidades
adicionales que se deben tener en cuenta como parte de la implementación de Windows
Virtual Desktop. Siga leyendo para obtener recursos adicionales, orientación sobre capacidades
adicionales, un glosario y más información sobre el autor de este eBook.
Recursos
Esperamos que haya disfrutado el recorrido y que ahora se sienta más preparado para migrar
a Windows Virtual Desktop. Hay muchos otros recursos y soporte para ayudar, aquí hay algunas
referencias clave:
1. Lea más documentación de Windows Virtual Desktop para recibir la orientación técnica
más reciente.
2. Realice un tutorial sobre cómo empezar a trabajar con Windows Virtual Desktop.
3. Mire el video de Microsoft Mechanics para obtener un resumen rápido sobre cómo realizar
la migración.
4. Regístrese para obtener una cuenta gratuita de Azure, para así intentar implementar sus
aplicaciones y escritorios virtualizados de Windows.
5. Obtenga orientación práctica de implementación si ya tiene una suscripción a Azure.
6. Únase al Programa de migración de Azure para obtener orientación y ayuda de expertos.
7. Póngase en contacto con ventas para hablar acerca de los precios, los requisitos técnicos
y las soluciones a corto y largo plazo para proteger el trabajo remoto.
Si es necesario, use los siguientes recursos para obtener información más detallada sobre temas
específicos mencionados en este eBook:
● Azure Reserved VM Instances (RI)
● Integraciones de socios de Windows Virtual Desktop
● ¿Qué es Windows Virtual Desktop?
● Especificaciones de equipo y requisitos de sistemas de Windows 10
● SLA para máquinas virtuales
● Servicios de escritorio remoto: aceleración de GPU
● Tamaños de máquina virtual optimizados para GPU
● Serie de máquinas virtuales
● Integraciones de socios de Windows Virtual Desktop
● Acerca de Azure Migrate
● Prepare y personalice una imagen VHD maestra
● Módulo de vista previa de migración de FSLogix
● Precios de Windows Virtual Desktop
● Imágenes de SO de máquina virtual compatibles
● Lista de URL seguras
● Preguntas frecuentes de múltiples sesiones de Windows 10 Enterprise
● Métodos de equilibrio de carga del grupo host
● Convenciones de nomenclatura y etiquetado recomendadas
● Cree un un grupo host con el portal de Azure
● Administre grupos de aplicaciones con el portal de Azure
● Estimador de experiencia de Windows Virtual Desktop
● Escale los hosts de la sesión con Azure Automation
● Habilite la autenticación multifactor de Azure para Windows Virtual Desktop
● Use Log Analytics para la característica de diagnóstico
● ¿Qué son las plantillas de ARM?
● Plantillas de ARM de RDS/Windows Virtual Desktop
● Use Azure Advisor con Windows Virtual Desktop
● Use Microsoft Teams en Windows Virtual desktop
● Configure la conexión de aplicaciones MSIX
Glosario
La siguiente tabla contiene un glosario de la terminología utilizada en este libro.
Término Descripción
Un directorio es una estructura jerárquica que almacena información sobre los

Active Directory objetos en la red. Un servicio de directorio, como Active Directory Domain Services
Domain Services (AD DS), proporciona los métodos para almacenar datos de un directorio y poner estos
datos a disposición de los usuarios y administradores de la red.
Un grupo de aplicaciones es una agrupación lógica de aplicaciones instaladas en los
Grupo de aplicaciones hosts de la sesión en el grupo host. Un grupo de aplicaciones puede ser de tipo
Escritorio o Aplicación remota.
Azure Active Directory Azure Active Directory (Azure AD) es el servicio de administración de identidades
(Azure AD) y acceso basado en la nube de Microsoft, que ayuda a sus empleados a iniciar sesión
y acceder a los recursos.
Usuarios finales Después de asignar a los usuarios a sus grupos de aplicaciones, estos pueden
conectarse a una implementación de Windows
FSLogix está diseñado para recorrer perfiles en entornos informáticos remotos,
FSLogix como Windows Virtual Desktop. Almacena un perfil de usuario completo en un
solo contenedor.
Un grupo host es una colección de máquinas virtuales de Azure que se registran en
Grupo host Windows Virtual Desktop como hosts de sesión al ejecutar el agente de Windows
Virtual Desktop.
La autenticación multifactor es un proceso en el que se solicita al usuario, durante el
MFA proceso de inicio de sesión, una forma adicional de identificación, como introducir
un código en su teléfono celular o someterse a un análisis de huella dactilar.
Conexión de aplicaciones La conexión de aplicaciones MSIX es una forma de entregar aplicaciones MSIX
MSIX a máquinas físicas y virtuales.
Servicios de escritorio remoto es la plataforma de IaaS para la creación de soluciones
RDS
de virtualización.
Múltiples sesiones de Múltiples sesiones de Windows 10 Enterprise, conocido anteriormente como
Windows 10 Enterprise Windows 10 Enterprise for Virtual Desktops (EVD), es un nuevo host de sesión
de escritorio remoto que permite varias sesiones interactivas simultáneas.
Un área de trabajo es una agrupación lógica de grupos de aplicaciones en Windows
Espacio de trabajo Virtual Desktop.
Windows Virtual Desktop Un servicio de virtualización de escritorios y aplicaciones que se ejecuta en

Microsoft Azure.
Tabla 5: Glosario
Acerca del autor

Freek Berson es un arquitecto de soluciones en la nube con una especialización en aplicaciones
y entrega de escritorios basada en tecnología de comunicación remota. Tiene una larga
trayectoria en el espacio RDS y ha sido galardonado como el Profesional más valioso (MVP)
de Microsoft desde 2011.
Freek participa activamente en la comunidad. Se presenta en varias conferencias de todo

el mundo, incluidas Microsoft Ignite, Microsoft Ignite | The Tour, Microsoft TechSummit,
Microsoft TechDays, Azure Saturday, BriForum, E2EVC, ExpertsLive y muchos más eventos
(en línea). También es autor de un libro.
Trabaja en Wortell, una empresa de integración de la nube con sede en los Países Bajos, donde
se centra en la informática para el usuario final, principalmente en la plataforma de Microsoft con
un gran enfoque en Azure. También es socio administrador de RDS Gurus.
Lleva su blog personal en themicrosoftplatform.net, donde escribe artículos y publicaciones

relacionadas con Windows Virtual Desktop, RDS, Azure y otras tecnologías de Microsoft.
Puede seguirlo en Twitter en @fberson y consultar sus contribuciones a través de su cuenta de

GitHub.
© 2020 Microsoft Corporation. Todos los derechos reservados.

Este documento se entrega “tal cual”. La información y las opiniones expresadas en este documento, incluidas las direcciones URL y otras referencias a sitios web
de Internet, están sujetas a cambios sin previo aviso. Usted asume el riesgo de usarlo. Este documento no le otorga derecho legal alguno a ningún aspecto de
propiedad intelectual de ninguno de los productos de Microsoft. Puede copiar y usar este documento para uso interno como referencia.

Windows Virtual Desktop

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Windows Virtual Desktop

Cargado por

Copyright:

Formatos disponibles

Serie de eBooks de AzureS

Windows Virtual Desktop

Pruebas y preparación para Acerca del autor 40

Un enfoque de infraestructura de escritorio virtual (VDI) a menudo se aprovecha para

Infraestructura Licencias TCO

Se aumenta la Se reutilizan licencias No es necesario

Figura 1: Pilares de ahorro de costos de Windows Virtual Desktop

Además de permitir el trabajo remoto y de ahorrar en infraestructura, licencias y costo total

¿Por qué migrar a Windows Virtual Desktop?

Responsabilidad RDS locales RDS en Azure Windows Virtual Desktop

Sistema operativo host de la sesión

Plano de control de virtualización

Centro de datos físico

Figura 2: El plan de migración de siete pasos

Figura 3: Primeros cuatro pasos del proceso de migración

Paso 1: Requisitos previos

Figura 4: Inicio del asistente de Azure Migrate

En este asistente, configurará la suscripción, el grupo de recursos, el nombre del proyecto y la

En este paso, creará un nuevo proyecto de Azure Migrate en la suscripción a Azure de

Figura 5: Ejemplo del visualizador de Lakeside SysTrack

Paso 4: Revisión de la evaluación

Figura 6: Ejemplo de resultado de evaluación

Los pasos detallados para la evaluación se encuentran aquí.

Antes de continuar con el paso 5, este es el momento de comenzar a crear su entorno de

En el capítulo 3, hablaremos de los requisitos previos y las consideraciones importantes para

Creación del entorno de Windows Virtual Desktop

Sistema operativo Licencia requerida

Múltiples sesiones de Windows 10

Tabla 2: Sistemas operativos y licencias requeridas

Tipo de carga de trabajo Ancho de banda recomendado

Ligero 1.5 Mbps

Tabla 3: Anchos de banda mínimos recomendados

Resoluciones de pantalla típicas a 30 fps Ancho de banda recomendado

Aproximadamente 1024×768 píxeles 1.5 Mbps

Aproximadamente 1280×720 píxeles 3 Mbps

Aproximadamente 1920×1080 píxeles 5 Mbps

Aproximadamente 3840×2160 píxeles (4K) 15 Mbps

Tabla 4: Resoluciones de pantalla típicas y anchos de banda recomendados

Pautas de administración de perfiles

Múltiples sesiones de Windows 10

Figura 7: El asistente para crear un grupo host en el portal de Azure

De forma predeterminada, el proceso de configuración del grupo host crea un grupo de

Figura 8: Creación del grupo de aplicaciones

Si selecciona No, puede registrar el grupo de aplicaciones en otro momento, pero le

Figura 9: Creación del área de trabajo

Anteriormente, completamos los pasos 1 al 4 y, en la sección anterior, creamos nuestra

Figura 10: Pasos 5, 6 y 7

Los pasos detallados para la replicación se encuentran aquí.

Paso 6: Migración de prueba

Los pasos detallados para la migración de prueba se encuentran aquí.

Paso 7: Migración para la producción

Los pasos detallados para la migración para la producción se encuentran aquí.

Figura 11: Los siete pasos completados

Hemos completado el proceso de siete pasos de Azure Migrate. En el capítulo 4, seguiremos

Pruebas y preparación para la implementación

Estado del grupo host de Windows Virtual Desktop

Orientación para realizar pruebas de las implementaciones de Windows

Figura 14: Ejemplo de cliente de Windows Virtual Desktop

Preparativos finales para la implementación

Implementación y pasos posteriores a la implementación

Azure Advisor le proporciona información sobre su entorno de Windows Virtual Desktop y lo

Figura 15: Ejemplo de Azure Advisor for Windows Virtual Desktop

Consideraciones y pasos posteriores a la implementación

Limpieza de una implementación de RDS