Cómo afrontar los problemas de conexión en Azure Virtual Desktop

W11 » Tutoriales para Windows 11 » Cómo afrontar los problemas de conexión en Azure Virtual Desktop

Azure Virtual Desktop funciona como una cadena con muchos eslabones: la red del usuario, el cliente, el servicio de intermediación, el agente del host, la identidad y el perfil de FSLogix. Por eso, cuando aparece un fallo de conexión, quedarse solo con el mensaje de error visible suele llevar a callejones sin salida. Un corte de internet en una granja multis sesión, un aviso de conexión pausada o un feed vacío pueden venir de capas muy distintas y conviene mirar el conjunto antes de tocar nada.

En las líneas que siguen vamos a repasar los escenarios más habituales que se ven a pie de campo: desde el cliente Netskope que deja sin salida a internet a todos los usuarios de un host hasta los errores de registro del agente, pasando por latencia, permisos, acceso condicional, perfiles FSLogix y diagnóstico con Log Analytics. La idea no es memorizar una lista infinita, sino tener un mapa claro para saber por dónde empezar y qué evidencias pedir antes de cambiar configuraciones a lo loco.

Netskope, sesiones múltiples y ese extraño corte de internet

Un caso que suena a conocido: en un host de AVD con varias sesiones, el primer usuario que inicia sesión a las 7:15 se queda inactivo o se desconecta, y a partir de ahí todos los demás pierden la salida a internet hasta que ese usuario cierra sesión del todo. El tráfico web pasa por Netskope y el entorno no tiene NPA habilitado, así que la duda lógica es si el cliente de Netskope para VDI está aplicando algún comportamiento extraño. Merece la pena revisar la documentación específica de Netskope Client para infraestructura de escritorio virtual y comprobar si la versión desplegada tiene limitaciones con sesiones concurrentes, túneles por usuario, afinidad de sesión, tiempos de espera o cambios de contexto cuando una sesión queda desconectada.

No es descartable que el cliente asocie el túnel de red a la primera sesión y luego no sepa rehacerlo cuando esa sesión pasa a estado inactivo o desconectado. También puede influir una política de split tunnel, una exclusión mal puesta o un temporizador de inactividad que deje la pila de red en un estado del que no sale hasta el cierre de sesión. Probar con un usuario y una política mínima, comparar con un host sin Netskope y revisar los logs del cliente en el propio host suele aclarar más que dar vueltas a la configuración general de AVD.

Otro mensaje que se ve con frecuencia es el de conexión pausada, esperando a que se restaure la red. Aparece en Windows 11 Enterprise multis sesión 24H2 con FSLogix, en varios grupos de hosts, varias veces al día y con usuarios que trabajan desde redes distintas, así que culpar automáticamente a la red doméstica de cada persona no tiene mucho sentido. Si la monitorización no muestra desconexiones del dispositivo, toca mirar la calidad de la ruta hacia AVD, la pérdida de paquetes, el RTT, el uso de UDP o RDP Shortpath y la salud del agente en el host. Un perfil FSLogix que tarda en montar o un almacenamiento lento también pueden parecer un problema de red cuando en realidad son una espera del sistema de archivos.

• RTT bajo y estable: por debajo de 150 ms la experiencia debería ser buena incluso con cargas gráficas; entre 150 y 200 ms se puede trabajar con texto, aunque lo gráfico se resiente; por encima de 200 ms aparecen quejas con bastante probabilidad.
• Pérdida y fluctuación: no basta con tener mucho ancho de banda; una conexión inestable o con picos de latencia estropea la sesión.
• Ruta y región: acercar los hosts a los usuarios, revisar VPN y evitar saltos innecesarios ayuda más que añadir recursos a ciegas.

Red y rendimiento: lo que el usuario percibe de verdad

La configuración de red en AVD no se limita a que la máquina tenga salida. Hay que cuidar el grupo de hosts, la conectividad, los dispositivos de red y los grupos de seguridad. Una red bien planteada reduce latencia y evita bloqueos raros, mientras que una configuración heredada o con reglas demasiado restrictivas puede romper tanto el acceso al servicio como la conexión al host. Si se usan puntos de conexión de servicio o privados, conviene revisar que el tráfico hacia Azure, Microsoft 365, bases de datos y otras dependencias externas esté bien encaminado. También merece la pena revisar fallos de despliegue de ARM, límites de suscripción y errores de asignación de VM, porque a veces el problema no está en la sesión sino en la infraestructura que la sostiene.

Para mejorar la experiencia, lo sensato es partir de una conexión por cable o fibra, evitar redes móviles inestables, elegir una región de Azure cercana a los usuarios y a los datos, y dimensionar bien las máquinas virtuales. Un host con CPU o memoria justos, o con discos lentos, va a generar esperas que el usuario interpretará como problemas de conexión. Las series B no son buena idea para VDI; suelen encajar mejor las familias F, D o NV según la carga, y siempre con margen para picos. El equilibrio de carga, el tipo de disco y la política de optimización de la sesión remota también influyen en esa sensación de fluidez.

Cuando el tiempo medio de codificación está por debajo de 33 ms y aun así hay quejas, el cuello de botella puede estar en la aplicación o en el sistema operativo. Ahí entra en juego el contador User Input Delay, que mide cuánto tarda en atenderse una entrada de teclado o ratón. No es lo mismo que el RTT de Citrix, aunque ambos hablen de latencia percibida; la forma de muestrear y recoger el dato es distinta. Si el retardo de entrada sube, merece la pena revisar procesos, perfiles, antivirus y tareas de fondo antes de echar la culpa a la red.

• Internet: conexión estable, preferiblemente cableada y sin redes intermedias problemáticas.
• Azure: red virtual y región cercanas, endpoints adecuados, conexión inversa bien resuelta y reglas de seguridad revisadas.
• Host: tamaño de VM, discos, equilibrio de carga y límite de sesiones bien ajustados.
• Sesión: RDP Shortpath cuando sea posible y políticas de optimización para audio, vídeo y redirecciones.

El agente de AVD: el sospechoso habitual cuando no hay feed o el host no responde

Muchos problemas de conexión acaban en el agente. Si el servicio RDAgentBootLoader se detiene o no arranca, el host puede aparecer como no disponible y el usuario se queda mirando una pantalla sin recursos. El Visor de eventos es el primer sitio donde mirar, sobre todo los registros de aplicación y los eventos asociados a WVD-Agent, WVD-Agent-Updater, RDAgentBootLoader y MsiInstaller. Un token de registro inválido o caducado, con el evento 3277 de por medio y nombres como INVALID_REGISTRATION_TOKEN o EXPIRED_MACHINE_TOKEN, obliga a generar una clave nueva y volver a registrar el host; si el servicio se para justo después de arrancarlo, la pista del token gana enteros.

Si aparece INVALID_FORM, el agente no está llegando a los puntos de conexión del broker. Toca comprobar BrokerResourceIdURI y BrokerResourceIdURIGlobal y probar las rutas de salud correspondientes, añadiendo /api/health al final. Un firewall, un proxy o un DNS demasiado celoso pueden estar bloqueando esas URLs y provocar que el host no se registre bien. Los eventos 3703 y 3019 apuntan en la misma dirección: la puerta de enlace o las direcciones de transporte websocket no son accesibles. La lista de URLs requeridas no es un adorno; si falta una, la conexión se rompe. Herramientas como WVDAgentUrlTool.exe ayudan a localizar qué endpoint está dando guerra, y también conviene revisar cifrados TLS 1.2 o directivas que impidan al agente salir.

También hay errores que parecen de red y son de instalación. InstallationHealthCheckFailedException suele indicar que el listener de la pila no está funcionando. InstallMsiException puede venir de una directiva de grupo que bloquea msiexec, y Win32Exception de un bloqueo de cmd.exe. DownloadMsiException aparece cuando no hay espacio para el agente, MissingMethodException cuando .NET Framework está por debajo de 4.7.2 y NAME_ALREADY_REGISTERED cuando hay un nombre duplicado o un registro viejo que no se ha limpiado. Si qwinsta.exe no muestra rdp-tcp y rdp-sxs como Listen, toca revisar fReverseConnectMode, fEnableWinStation y SessionDirectoryListener. Una máquina con Windows Pro no vale para la pila en paralelo; se necesita una SKU Enterprise o Server.

Cuando los hosts se quedan en Actualizando, No disponible o Necesita asistencia, las comprobaciones de salud mandan. UrlsAccessibleCheck falla si el firewall o el archivo hosts bloquean direcciones necesarias. MetaDataServiceCheck falla si no se llega a 169.254.169.254, el endpoint de IMDS, o si el proxy no lo excluye; para eso puede hacer falta un bypass explícito con bypass-list en la configuración de WinHTTP. MonitoringAgentCheck vigila el agente Geneva, su tarea programada y, si no aparece, el archivo GenevaInstall.txt. Los arranques lentos también cuentan: si RDAgentBootLoader no llega a tiempo, se puede configurar el inicio retrasado, ampliar ServicesPipeTimeout y revisar eventos 7000 o 7011, además de antivirus, scripts de arranque e IOPS. Si el host está en el límite de conexiones, el agente no tendrá una conexión activa y rechazará nuevas sesiones.

Si el problema persiste, el plan de recuperación pasa por quitar el host del grupo, generar una clave de registro nueva, desinstalar agente, bootloader y pila, reinstalar la versión más reciente y volver a registrar. Antes de eso conviene comprobar que la clave DisableRegistryTools no esté impidiendo la instalación de la pila en paralelo y que el broker no esté dando errores de validación de configuración. No es una tarea agradable, pero suele sacar del pozo a hosts que llevan tiempo atascados.

Identidad, acceso y perfiles: fallos que parecen red pero no lo son

El usuario se autentica, pero no ve ningún icono en el feed. Ahí hay que revisar la asignación a grupos de aplicaciones, las credenciales, la caché del cliente web y el tipo de grupo de Microsoft Entra. Un grupo de distribución no sirve; AVD espera un grupo de seguridad. Si la suscripción se ha movido de tenant o un proveedor CSP la ha transferido, las asignaciones pueden quedar colgadas y toca reasignar usuarios o volver a registrar el proveedor de recursos Microsoft.DesktopVirtualization. Comandos como Get-AzRoleAssignment ayudan a confirmar que el usuario está donde debe estar, y los logs de inicio de sesión de Entra ID aclaran si el problema es de credenciales o de política.

Las políticas de acceso condicional también pueden bloquear el acceso a aplicaciones concretas de AVD o Windows 365, tanto al iniciar sesión como al conectar a un recurso. Si hay SSO con Microsoft Entra, conviene validar que la aplicación de inicio de sesión en la nube esté permitida. En entornos con AD FS, un error MSIS7102 o un fallo al enviar prompt=login puede venir de PromptLoginBehavior; para versiones compatibles, nativeSupport suele ser la configuración que evita que se traduzca en una autenticación por contraseña que el STS no admite.

Hay un caso muy concreto que despista: desde equipos unidos al dominio no se puede conectar con la Aplicación de Windows ni con el Cliente RDP, pero el cliente web funciona y desde equipos no unidos al dominio también. Ahí la red no parece la culpable; huele a credenciales, NLA, Kerberos, confianza entre dominios o a diferencias de autenticación entre clientes. Revisar los logs del cliente en %temp%/DiagOutputDir/RdClientAutoTrace y comparar el método de inicio de sesión ayuda a acotar el problema.

No olvidemos los permisos. El rol de Virtual Machine User Login en los hosts, el de Desktop Virtualization User en el grupo de aplicaciones y el de Storage File Data SMB Share Contributor para FSLogix son habituales en tickets de acceso. Si se exige MFA o hay directivas heredadas, el usuario puede autenticarse y aun así no entrar. En entornos híbridos, un fallo de sincronización de contraseñas en Entra Connect también rompe la experiencia. Los perfiles FSLogix mal montados añaden otra capa: revisar logs en %ProgramData%/FSLogix/Logs, espacio en el almacenamiento, permisos SMB y la configuración de Azure Files. Un contenedor que no monta puede parecer una conexión que se queda colgada.

Diagnóstico con Log Analytics: dejar de adivinar

La mejor forma de no ir a ciegas es enviar los diagnósticos del grupo de hosts a un workspace de Log Analytics, creándolo desde el portal o por CLI. Sin datos, cualquier teoría vale, y con datos se puede ver quién falla, cuándo, en qué host y con qué error. Hay que habilitar las categorías de Checkpoint, Error, Management, Connection, HostRegistration, AgentHealthStatus, NetworkData y ConnectionGraphicsData. Ojo, porque Azure Monitor puede tardar unos 15 minutos en mostrar los datos y la primera configuración puede necesitar unas horas.

Las tablas más útiles son WVDConnections, WVDErrors, WVDCheckpoints, WVDAgentHealthStatus, WVDConnectionNetworkData y WVDConnectionGraphicsDataPreview. Uniendo WVDConnections con WVDErrors se localizan los fallos de conexión y su código. Para conexiones lentas, se puede medir el tiempo entre Started y Connected y revisar si el equilibrador de carga o el perfil están retrasando la sesión. Para desconexiones, WVDConnectionNetworkData ofrece RTT y ancho de banda, de modo que un usuario con picos altos probablemente tenga un problema en su ruta. Para hosts enfermos, WVDAgentHealthStatus muestra estados distintos de Healthy y ayuda a priorizar.

Los códigos de error más vistos también orientan: ConnectionFailedNoHealthyRdshAvailable indica que no hay hosts sanos; ConnectionFailedClientDisconnect suele ser un corte del cliente; ConnectionFailedUserUnauthorized apunta a roles; ConnectionFailedVMNotFound avisa de una VM que ya no está. Una alerta con más de un 10% de fallos en 15 minutos puede avisar al equipo por correo o Teams antes de que el helpdesk se llene. Los diagnósticos no son gratis: un entorno de 100 usuarios puede generar entre 1 y 5 GB al mes, así que conviene ajustar retención a 30, 60 o 90 días y archivar lo antiguo si hace falta.

• Fallos: unir conexiones y errores para ver usuario, host y código.
• Lentitud: medir duración y revisar equilibrado, recursos y FSLogix.
• Desconexiones: mirar RTT, pérdida y ancho de banda por correlación.
• Salud: revisar el estado del agente y las comprobaciones del host.

Cómo ordenar el diagnóstico sin perder la cabeza

Cuando llega el ticket, lo primero es acotar el alcance: ¿falla un usuario, un host, un grupo o todo el entorno? ¿Pasa con el cliente web, con la Aplicación de Windows, con RDP o con todos? ¿Ocurre a una hora concreta? Separar red, identidad, agente y perfil evita cambios cruzados que luego no se sabe si han arreglado algo o han empeorado otra cosa. Con el diagnóstico activo, el Visor de eventos y las pruebas comparativas se puede construir una hipótesis decente en bastante menos tiempo.

En el caso de Netskope, yo empezaría por reproducir el fallo con un usuario y una sesión, revisar la versión y la configuración del cliente para VDI, comprobar si hay túneles por usuario, exclusiones de split tunnel y tiempos de inactividad. Después compararía con un host sin el cliente o con una política más permisiva. Si el patrón se repite con el primer usuario inactivo, hay que mirar cómo gestiona el cliente la sesión desconectada y si deja la pila de red en un estado que bloquea a los demás. No conviene descartar una incidencia del propio Windows multis sesión o de FSLogix, pero el orden de los síntomas apunta a esa combinación.

Para el resto de fallos, la secuencia mental es sencilla: servicio de AVD y host sanos, agente registrado y sin errores de URL, identidad y roles correctos, perfil que monta y red con latencia razonable. La mayoría de los incendios se apagan revisando esos cinco frentes y no cambiando diez cosas a la vez. Si hay que escalar, conviene llevar logs del cliente, eventos del host, resultados de las comprobaciones de URL y datos de Log Analytics; con eso el soporte puede trabajar de verdad.

Queda claro que un fallo de conexión en AVD rara vez tiene una única causa y que la paciencia, la comparación y la evidencia valen más que los manotazos de configuración. Netskope, el agente, la latencia, los permisos y los perfiles son los frentes que más quebraderos de cabeza dan, pero con diagnóstico centralizado, comprobaciones de salud y una rutina de revisión se puede pasar de apagar fuegos a anticiparse. La clave está en no quedarse con el primer mensaje de error y en entender que la experiencia del usuario final es el resultado de muchas piezas funcionando a la vez.