Solución: Sesiones RDP se cierran inmediatamente en Windows Server 2019

Cuando un servidor Windows Server 2019 en VMware desconecta las sesiones RDP tan pronto como el usuario ingresa sus credenciales, el problema suele estar en una combinación de eventos, GPO, NLA o recursos. Sigue esta guía exhaustiva para aislar y corregir la causa.

Resumen del problema

En determinados entornos virtualizados, los usuarios autenticados vía Escritorio Remoto se desconectan de forma instantánea. El comportamiento ocurre incluso con perfiles que pertenecen a Remote Desktop Users y tras reiniciar el sistema operativo invitado. El síntoma general es:

• La ventana RDP se cierra sin error visible en el cliente.
• Los ID de evento 40, 41 o 1026 aparecen en los registros de RDP o .NET sin explicación aparente.
• No existe consumo anómalo de CPU ni de memoria en la VM.

Por qué ocurre la desconexión instantánea

Una conexión RDP implica varias fases: negociación TLS, autenticación NLA (CredSSP), asignación de sesión y, por último, presentación de la shell del usuario. Si cualquiera de estos pasos falla o excede un umbral de tiempo, el host termina el canal, devolviendo al cliente un cierre inmediato. Entre los detonantes más habituales están:

1. Políticas de seguridad que imponen cifrados no compatibles.
2. Licenciamiento RDS expirado (gracia superada).
3. Credenciales Kerberos inválidas o SPN duplicado.
4. Controladores vmxnet3 obsoletos que generan retransmisiones RST en el puerto 3389/TCP.
5. Servicios auxiliares (antivirus, supervisión) que inyectan DLL y rompen la inicialización de la sesión.

Flujo de diagnóstico paso a paso

La tabla siguiente resume las áreas críticas y las acciones recomendadas. Sigue el orden de izquierda a derecha para descartar causas de forma sistemática.

Área	Acciones recomendadas	Propósito
Registros de eventos	Revisar: * Microsoft‑Windows‑RemoteDesktopServices‑RdpCoreTS/Operational * Terminal‑Services‑RemoteConnectionManager/Operational * TerminalServices‑LocalSessionManager/Operational * Windows/Security	Identificar la razón de desconexión (códigos 0xC000006D, 0xC0000234, 0xC000020D, etc.).
Red y comunicación	* ping, tracert, netsh interface ipv4 show subinterfaces * Validar IP estática y escucha en 3389/TCP. * Confirmar drivers vmxnet3 y VLAN correctas.	Averiguar si la sesión cae por latencia, pérdida o MTU incorrecto.
Recursos del servidor	* Monitorizar CPU, RAM y disco en el momento del logon. * Detener antivirus/copias para pruebas. * Ver eventvwr.msc por ID 50 “The RDP protocol component X.224 detected an error” o ID 55.	Descartar expulsión por falta de recursos.
Política de seguridad y RDP	* Editor de directivas locales → Remote Desktop Session Host ➜ Connections/Security. * Comprobar Idle session limit y nivel de cifrado. * Reiniciar gpupdate /force tras cambios.	Detectar GPO que bloquea el handshake.
Network Level Authentication (NLA)	* Desactivar NLA temporalmente en System Properties ► Remote. * Modificar HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp → UserAuthentication=0 y reiniciar servicio.	Determinar si el fallo es de CredSSP o de certificados TLS.
Otros controles útiles	* Confirmar servicio TermService iniciado. * Revisar licenciamiento RDS (ID 1128/1130). * Entrar con mstsc /admin (antiguo /console). * Instalar parches acumulativos y VM Tools recientes.	Eliminar causas como límite de licencias o incompatibilidad de versión.

Registros de eventos: interpretación detallada

Códigos de desconexión comunes

• 0xC000006D / STATUSLOGONFAILURE: credenciales incorrectas o cuenta bloqueada.
• 0xC000020D / STATUSLOGONTYPENOTGRANTED: el usuario no tiene permiso “Allow log on through Remote Desktop Services”.
• 0xC0000234 / STATUSACCOUNTLOCKED_OUT: umbral de bloqueo de cuenta excedido.
• 0xC000018B / STATUSLICENSINGTIMEOUT: el servidor no puede contactar con el servidor de licencias RDS.

Qué buscar en los canales Operational

Ordena los registros por Date and Time justo después de reproducir la desconexión. Localiza una secuencia típica:

1. ID 131 “Client connection received”
2. ID 140 (establece la capa TLS)
3. ID 24 “User authentication succeeded”
4. ID 48 o 50 con Error Code → aquí se corta la sesión

El valor Win32ExitCode revela la causa exacta; anótalo para la fase siguiente.

Diagnóstico de red y pila TCP

Aunque la desconexión parece “instantánea”, un trace RTT alto o paquetes fragmentados pueden disparar timeouts de pre‑autenticación. Ejecución recomendada:

ping -n 20 -l 1472 <IPServidor>
tracert -d <IPServidor>
netsh trace start capture=yes tracefile=c:\temp\rdp.etl

Después, analiza el archivo ETL con Microsoft Message Analyzer (o netsh trace convert) para detectar RST o retransmisiones. Si usas VMware, edita la tarjeta vmxnet3 y verifica que Large Receive Offload no cause fragmentación.

Validación de recursos locales

Abre Performance Monitor y crea un Data Collector Set que incluya:

• \Processor(_Total)\% Processor Time
• \Memory\Commit Limit y \Memory\% Committed Bytes In Use
• \LogicalDisk(_Total)\Avg. Disk Queue Length

Dispara la conexión RDP y observa si hay picos superiores al 90 %. Un script antivirus consumiendo CPU puede retrasar la carga de la shell, provocando que el servidor cierre la sesión por “handshake incompleto”.

Revisión de directivas de seguridad

Dirígete a gpedit.msc:

Configuración de equipo ⇒ Plantillas administrativas ⇒
Componentes de Windows ⇒ Servicios de Escritorio remoto ⇒
Host de sesión de Escritorio remoto ⇒ Conexiones

Los valores más conflictivos suelen ser:

• “Establecer nivel de cifrado del cliente” → deja “Compatible” durante pruebas.
• “Limitar número de conexiones” → define un valor suficiente para pruebas (999999 equivale a ilimitadas).
• “Permitir conexiones únicamente desde equipos con NLA” → deshabilita para descartar CredSSP.

Network Level Authentication (NLA) y CredSSP

NLA añade una capa de seguridad, pero introduce dependencias en:

1. Resolución de SPN TERMSRV/servidor via DNS.
2. Coherencia de fecha/hora para los tickets Kerberos.
3. Actualización de parches CredSSP (2018‑05 y posteriores).

Si el log muestra Event ID 4625 con tipo 3 y subestado 0xC0000192, la autenticación TLS es correcta, pero falla la NLA por certificado. Deshabilita temporalmente NLA y repite: si la sesión permanece, reemite un nuevo certificado Computer (Enhanced Key Usage: Server Authentication).

Impacto del licenciamiento RDS

Un servidor con el rol Remote Desktop Session Host dispone de 120 días de gracia. Al expirar, genera Event IDs 1128 (Advertencia) y 1130 (Error). Si el ID 1128 aparece justo antes de la desconexión, reactiva o migra tu servidor de licencias. Para una prueba rápida, usa:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM" /v GracePeriod /t REG_DWORD /d 0xFFFFFF /f

Reinicia el servicio TermService – solo con fines de diagnóstico; vuelve a un modelo de licencias válido lo antes posible.

Pruebas específicas en VMware vSphere

Actualizar VMware Tools y controlador vmxnet3

Versiones antiguas de vmxnet3 en Windows Server 2019 pueden exponer problemas de checksum offload incorrecto en TLS. Actualiza VMware Tools y habilita la opción Hardware accelerated graphics si tu edición de licencia lo permite. Comprueba también:

• El adaptador utiliza la VLAN correcta (vSwitch o DVS).
• No hay “Traffic Shaping” restrictivo en la política de puerto.
• No existe regla de firewall distribuido que limite 3389/TCP → Session Timeout < 30 s.

Instant Clone y cambios de SID

Si la VM se aprovisiona con clon instantáneo o plantilla Sysprep → SID duplicados pueden afectar a CredSSP. Ejecuta sysprep /oobe /generalize o usa New‑SID para regenerar. Aun así, lo recomendable es mantener una plantilla limpia y recién Sysprep para desplegar nuevos hosts.

Escenarios especiales y soluciones rápidas

• Group Policy objeto huérfano: Borra %windir%\System32\GroupPolicy\Machine, reinicia gpupdate /force y el servicio gpsvc.
• Antivirus con filtro de red: Deshabilita el módulo Web proxy/SSL Scanning y prueba.
• Modo FIPS: Si está habilitado, deja solo TLS 1.2 y RSA 2048 bits; clientes sin soporte se expulsarán.
• Conexiones RDP Gateway: Revisa que la autoridad de certificación no haya revocado el certificado del Gateway.
• Escaneo de puertos agresivo: Herramientas de inventario que abren/cierran 3389 provocan saturación; agrega intervalos o filtros.

Uso de herramientas de terceros

Cuando el visor de eventos no basta, RDPDiag o Wireshark permiten capturar la secuencia TLS ClientHello, ServerHello, Encrypted Extensions. Un cierre con FIN,ACK después de ServerHelloDone suele indicar fallo en la validación de certificado o incompatibilidad en cipher suite. Filtra por tcp.port == 3389 y colorea RST,ACK para identificar el punto exacto.

Buenas prácticas tras restablecer el servicio

1. Vuelve a habilitar NLA y fuerza TLS 1.2+ modificando HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
2. Aplica un GPO que limite los grupos autorizados a Remote Desktop Users y Administrators.
3. Activa auditoría de inicio de sesión (éxito y error) para vigilar intentos fallidos.
4. Programa parches mensuales y actualiza VMware Tools junto con los Compatibility Updates de hardware.
5. Documenta la causa raíz en tu sistema de tickets para evitar re‑introducir el error.

Conclusión

Una desconexión RDP inmediata en Windows Server 2019 rara vez es un “fallo misterioso”; casi siempre hay una pista clara en los registros o en los contadores de rendimiento. Siguiendo el flujo de análisis —eventos, red, recursos, políticas y NLA— podrás aislar rápidamente el componente defectuoso y restaurar la conectividad. Mantén tu entorno actualizado, aplica configuraciones coherentes y monitorea de forma proactiva para que la experiencia de Escritorio Remoto sea estable y segura.