Problema

En entornos con Windows Server que ofrecen Remote Desktop Services (RDS), es frecuente que un usuario experimente una desconexión limpia y, al intentar reconectar, reciba el código de error 0x904 sin mensaje adicional. El síntoma típico es:

  • La sesión aparece como Disconnected en el listado de sesiones.
  • No se pueden iniciar nuevas sesiones con ese mismo usuario.
  • Otros usuarios pueden conectarse sin problemas.
  • No aparecen eventos relevantes en los logs de Terminal Services, System o Application.

Este patrón suele aparecer cuando el servidor está alojado en una máquina virtual (por ejemplo, bajo Proxmox, Hyper‑V o VMware) y el cliente accede a través de una VPN basada en IKEv2. La combinación de una sesión RDP “zombie” y una caché de credenciales corrupta puede bloquear al usuario de forma persistente hasta que el servidor se reinicia.

Causa

El error 0x904 no tiene una documentación oficial clara, pero en la práctica se ha vinculado a varios factores que comparten un mismo denominador: estado inconsistente del canal de sesión RDP. Las causas más habituales son:

  1. Token de seguridad de la sesión corrupto
    Cuando el cliente se desconecta de forma abrupta (corte de VPN, pérdida de red momentánea), el token que Windows usa para validar la reconexión puede quedar dañado. El servidor lo reconoce como inválido y devuelve 0x904.

  2. Licencia de RDS atascada
    En entornos con licencias de acceso de cliente (CAL) temporales, una sesión que no se libera correctamente puede consumir una licencia y bloquear la reconexión del mismo usuario.

  3. Configuración de red conflictiva
    Un túnel IKEv2 que mantiene la misma dirección IP para el cliente pero cambia el puerto de origen puede provocar que el servidor interprete la reconexión como una nueva sesión que colisiona con la anterior.

  4. Problemas de la capa de virtualización
    En Hyper‑V/Proxmox, la desincronización de los contadores de tiempo o la pérdida de paquetes entre el host y la VM pueden dejar el driver de RDP en un estado “half‑closed”.

  5. Políticas de grupo que modifican la caché de credenciales
    GPO que habilitan “Network security: Do not store LAN Manager hash value” o que cambian la duración del ticket Kerberos pueden interferir con la revalidación del token.

En la mayoría de los casos, el problema se resuelve al forzar la limpieza del estado de sesión y/o resetear el listener RDP sin necesidad de reiniciar todo el servidor.

Solución

A continuación se describe un proceso genérico que cubre las causas más comunes. Se pueden aplicar de forma independiente o en cadena hasta que el usuario recupere la capacidad de iniciar sesión.

1. Eliminar la sesión “zombie”

# Listar sesiones RDP
qwinsta /server:localhost

# Identificar el ID de la sesión del usuario afectado (ej. 3) y cerrarla
rwinsta 3 /server:localhost

qwinsta muestra el estado de cada sesión; rwinsta fuerza su terminación. Esta acción libera el token y la licencia asociada.

2. Resetear el listener RDP

# Detener el servicio de Remote Desktop Services
net stop TermService

# Borrar la configuración de listener (se regenerará al iniciar)
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /f

# Iniciar el servicio nuevamente
net start TermService

El borrado de la clave del listener obliga a Windows a recrear la configuración con valores por defecto, eliminando cualquier corrupción de caché.

3. Verificar y renovar tickets Kerberos

# En el cliente Windows 11
klist purge
klist tickets

Si el cliente está fuera del dominio, forzar la renovación del ticket puede evitar que el servidor rechace la autenticación por un ticket expirado.

4. Revisar la configuración de la VPN

  • Asegúrate de que la política de re‑keying de IKEv2 no cambie la dirección IP del cliente mientras la sesión RDP está activa.
  • Si la VPN usa split‑tunneling, verifica que el tráfico RDP (puerto 3389) siempre salga por el túnel.

5. Comprobar el estado de las licencias RDS

En el servidor terminal, abre Remote Desktop Licensing Manager y verifica que no haya licencias “orphaned”. Si aparecen, ejecuta:

# Desde PowerShell con privilegios de administrador
Remove-RDLicense -LicenseId <ID> -Force

Esto libera cualquier licencia que haya quedado atrapada por la sesión corrupta.

6. Aplicar parches y actualizaciones de Hyper‑V/Proxmox

Mantener el host y la VM al día suele eliminar bugs de sincronización de tiempo que provocan estados inconsistentes en RDP.

Cuándo aplicar esta solución

Aplica este flujo cuando:

  • Un solo usuario recibe el error 0x904 mientras que el resto funciona.
  • No aparecen eventos en los logs de Terminal Services.
  • La sesión del usuario aparece como “Disconnected” y no se puede reconectar.
  • Reiniciar el servidor es una opción costosa o interrumpe servicios críticos.

No es necesario si:

  • El error afecta a todos los usuarios simultáneamente (probable problema de licencia o de servicio global).
  • Los logs indican fallos de hardware o de red a nivel de host.

Código

# Paso completo: cerrar sesión, resetear listener y reiniciar servicio
qwinsta /server:localhost | findstr /i "username"
rwinsta <ID> /server:localhost
net stop TermService
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /f
net start TermService

Reemplaza <ID> por el número de sesión obtenido en el primer comando.


## Verificación
1. **Reintentar conexión RDP** desde el cliente. La sesión debe iniciarse sin error.  
2. **Comprobar el estado de la sesión** con `qwinsta`. El usuario debería aparecer como **Active**.  
3. **Revisar el visor de eventos** (System, Application, TerminalServices‑RemoteConnectionManager) para asegurarse de que no se generen nuevos eventos de error.  
4. **Ejecutar `klist tickets`** en el cliente para confirmar que el ticket Kerberos es válido y tiene una vida razonable.  
5. **Monitorear la VPN** durante 30 min para detectar reconexiones automáticas que puedan volver a generar el error.

## Notas adicionales
* En entornos con múltiples servidores RDS detrás de un balanceador, el mismo token corrupto puede propagarse; aplica los mismos pasos en cada nodo.  
* Si el problema persiste después de varios intentos, considera habilitar el registro de depuración de RDP (`HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Debug\LogLevel`) para obtener más información.  
* Algunas configuraciones de GPO que deshabilitan la caché de credenciales pueden evitar que el token se corrompa, pero aumentan la latencia de inicio de sesión. Evalúa el impacto antes de cambiar la política.  
* En Proxmox, la opción “IO thread” para la VM de terminal puede reducir la pérdida de paquetes y mejorar la estabilidad de RDP.  

Con este enfoque podrás diagnosticar y resolver el error 0x904 sin necesidad de reiniciar todo el servidor, manteniendo la disponibilidad de los usuarios y reduciendo el tiempo de inactividad.