Azure Virtual Desktop ya ofrece de forma general una gestión de host pools que crea, actualiza y escala los hosts de sesión desde una configuración común. La propuesta reduce automatización propia, pero exige tomar una decisión importante al principio: el enfoque de gestión se fija al crear el pool y no puede cambiarse después.
Para un equipo que hoy mantiene imágenes, scripts y máquinas con procesos separados, el beneficio es reconocible: definir cómo debe ser la flota y dejar que el servicio reponga los hosts por lotes. Para quien ya dispone de una fábrica de imágenes y despliegues maduros, el enfoque estándar puede seguir siendo el adecuado.
Qué incluye la gestión mejorada
La novedad agrupa tres capacidades. La configuración de host de sesión define imagen, tamaño de VM, disco, red, unión al dominio, seguridad, etiquetas y un script opcional. Session host update aplica una configuración nueva sustituyendo máquinas de forma controlada. Dynamic autoscale puede crear o eliminar hosts según demanda, además de encenderlos o detenerlos.
Microsoft añade discos de sistema efímeros para cargas sin estado. Al vivir en almacenamiento local de la VM, reducen latencia y favorecen ciclos rápidos de recreación, pero no conservan cambios locales. No son una mejora automática para cualquier escritorio: encajan cuando perfiles y datos persistentes viven fuera del host.
La elección se hace al crear el host pool
La comparativa oficial limita este enfoque a pools compartidos. Un pool creado con gestión estándar no puede recibir después una configuración de host de sesión. Tampoco se pueden mezclar las herramientas pensadas para gestión estándar con la creación, actualización o escalado administrados por Azure Virtual Desktop.
Esta restricción convierte el piloto en una decisión de arquitectura. Antes de elegir, conviene listar qué hace hoy la automatización propia: creación de NIC, extensiones, instalación de agentes, unión al dominio, etiquetas, personalizaciones y retirada de máquinas. Lo que no quede en la imagen, Intune, una GPO o el script de configuración puede perderse al recrear el host.
Cómo se aplica una actualización
Session host update empieza por una VM de prueba y continúa por lotes. Los usuarios reciben un aviso, el host entra en modo de drenaje, se crea su sustituto y la máquina original se elimina. El tamaño del lote determina cuánta capacidad puede quedar fuera durante el proceso.
Hay límites que deben entrar en el runbook. Microsoft pide desactivar autoscale mientras se ejecuta la actualización, recomienda probar en un pool equivalente y advierte de que Azure Monitor Agent no se instala automáticamente en los hosts nuevos. También hay que revisar cuotas y recordar que la función solo está disponible en la nube global de Azure.
Una prueba que mida operación, no solo despliegue
Yo crearía un pool pequeño con la misma imagen, identidad y red que producción. Probaría una actualización de imagen, una sustitución con usuarios conectados, el retorno de telemetría y una escala de demanda. Después confirmaría que perfiles, certificados, aplicaciones y políticas reaparecen sin intervención manual.
La gestión mejorada puede quitar mucho trabajo repetitivo. Su valor depende de aceptar un modelo declarativo: los hosts son reemplazables y la configuración vive fuera de ellos. Si todavía hay cambios manuales que solo existen dentro de una VM, ese es el primer problema que resolver.