Te ha pasado seguro. Instalas el rol de RDS, configuras todo, y a los dos días te aparece el mensaje en la bandeja del sistema: «Establezca el modo de licencia del servidor host de sesión de escritorio». Lleva saliendo desde Windows Server 2008 y no parece haberse solucionado.
El problema es sencillo: el sistema no sabe a qué servidor de licencias tiene que pedir las CALs ni en qué modo tiene que funcionar. Windows te da 120 días de cortesía para que lo configures. Si no lo haces, cuando se acabe el plazo, adiós RDP para más de dos sesiones.
La solución es la misma desde hace años, pero hay una novedad con Windows Server 2022 que si trabajas en workgroup te va a dar guerra. Voy al lío.
Lo rápido: GPEDIT
Si tienes el servidor con interfaz gráfica, esto es lo más rápido.
Abres gpedit.msc y navegas hasta:
Configuración del equipo > Plantillas administrativas > Componentes de Windows > Servicios de Escritorio remoto > Host de sesión de Escritorio remoto > Licencias
Ahí tocas dos políticas:
Usar los servidores de licencias de Escritorio remoto específicos. La habilitas y pones el nombre del servidor donde tengas el rol de licencias. Si el license server está en la misma máquina, te vale 127.0.0.1.
Establecer el modo de licencia de Escritorio remoto. La habilitas y eliges «Por usuario» o «Por dispositivo». Tiene que coincidir con el tipo de CAL que compraste. Si no sabes cuál elegir: en un dominio te vale cualquiera. En workgroup sin Active Directory, solo «Por dispositivo». El modo «Por usuario» no se puede rastrear sin AD.
Ejecutas gpupdate /force desde una consola, o reinicias. Abres lsdiag.msc para comprobar que ya no ve errores.
PowerShell: el mismo cambio, pero por comandos
Si trabajas con Server Core o simplemente te da pereza abrir GPEDIT, se puede hacer con WMI. Esto funciona en todas las versiones de Windows Server.
Los comandos usan la clase Win32_TerminalServiceSetting del espacio de nombres Root/CIMV2/TerminalServices. Es la misma clase que usa el sistema internamente cuando configuras las políticas. Los he visto explicados en varios sitios, pero el que mejor los desarrolla es el blog de woshub.com (enlace al artículo) con la parte de PowerShell y también la de registro.
$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting
# Para ver si ya hay un servidor configurado
$obj.GetSpecifiedLicenseServerList()
# Para configurarlo
$obj.SetSpecifiedLicenseServerList("nombre-del-license-server")
# Para poner el modo: 4 = Por usuario, 2 = Por dispositivo
$obj.ChangeMode(4)GetSpecifiedLicenseServerList() te devuelve los servidores que están configurados actualmente. SetSpecifiedLicenseServerList() los sobreescribe con los que le pases. ChangeMode() acepta 4 (Per User) o 2 (Per Device). Si pones 5, lo deja sin configurar, que es lo que causa el error.
Sin módulos adicionales que instalar, sin dependencias.
Aviso: estos scripts modifican la configuración del servicio de licencias de RDS. Si pones un servidor de licencias que no existe o escribes mal el nombre, el servicio se quedará sin servidor configurado. Ejecútalos bajo tu responsabilidad. No me hago responsable de los daños que puedan causar.
El artículo de woshub.com tiene también una sección con Set-RDLicenseConfiguration, que es el cmdlet oficial de Microsoft para entornos con Connection Broker. Si tu despliegue tiene Connection Broker, ese cmdlet (documentación en Microsoft Learn) es la forma más correcta de hacerlo. Si no, el WMI te sirve igual.
Por registro: la ruta más corta
GPEDIT y PowerShell al final escriben en el registro. Puedes ir directamente.
Antes de tocar el registro, haz una copia de seguridad. Un error aquí puede dejar el servidor en un estado inconsistente. En regedit, exporta la rama
HKLMSYSTEMCurrentControlSetControlTerminal ServeroHKLMSYSTEMCurrentControlSetServicesTermService. Si algo sale mal, restauras el archivo .reg y reinicias.
# Modo de licencia
Set-ItemProperty "HKLM:SYSTEMCurrentControlSetControlTerminal ServerRCMLicensing Core" `
-Name "LicensingMode" -Value 4
# Servidor de licencias
New-Item "HKLM:SYSTEMCurrentControlSetServicesTermServiceParametersLicenseServers" -Force
New-ItemProperty "HKLM:SYSTEMCurrentControlSetServicesTermServiceParametersLicenseServers" `
-Name SpecifiedLicenseServers -Value "nombre-del-license-server" -PropertyType "MultiString"Los valores de LicensingMode:
- 2 — Per Device (CALs asignadas al dispositivo)
- 4 — Per User (CALs asignadas al usuario)
- 5 — Sin configurar (el que causa el error)
Aviso: modificar el registro puede tener consecuencias graves si no sabes lo que haces. Asegúrate de tener una copia de seguridad antes de cambiar nada.
Reinicia el servidor o el servicio TermService para que los cambios tengan efecto. Después abre lsdiag.msc para confirmar que ya no hay errores.
CVE-2024-38099: esto solo pasa en workgroup
Hasta Windows Server 2019, si tenías el license server y el session host en un workgroup, todo funcionaba sin problema. Con una actualización de seguridad de 2024, Microsoft metió un cambio: ahora el license server exige que el session host se autentique.
Si tienes Active Directory, esto no te afecta. El problema es para los que tenemos servidores en workgroup, que es bastante común en homelabs o entornos pequeños sin dominio.
Te vas a encontrar con que has seguido todos los pasos, lsdiag muestra errores, y no hay manera. Esa es la causa.
Para solucionarlo:
En el license server, abres lusrmgr.msc y creas un usuario normal. Yo lo llamo svc-rdscal o algo que se reconozca. Contraseña que no expire.
Luego, en cada session host, necesitas abrir una consola como el usuario NT AUTHORITYNETWORK SERVICE (que es con el que corre el servicio de RDS). La forma más cómoda es con PsExec de Microsoft:
psexec.exe -i -u "NT AUTHORITYNETWORK SERVICE" cmd.exeDesde esa consola, añades las credenciales:
cmdkey /add:<nombre-del-license-server> /user:<nombre-del-license-server>svc-rdscal /passTe pide la contraseña, la pones, y ya.
Esto está documentado por Microsoft en el artículo de configuración de licencias RDS para workgroups (enlace).
Puedes deshabilitar la autenticación en el license server con una entrada de registro:
HKLMSYSTEMCurrentControlSetServicesTermServLicensingParameters
DisableWorkgroupAuthEnforcement = 1 (DWORD)No lo recomiendo para producción porque en futuras versiones puede que Microsoft lo elimine, pero para laboratorios o entornos controlados, funciona.
Las CALs y las versiones
Cada vez que sale una versión nueva de Windows Server, la misma pregunta: ¿sirven las CALs viejas? Pues no. Es así desde siempre. Las de 2016 no sirven para 2019, las de 2019 no sirven para 2022, las de 2022 no sirven para 2025.
Si tu session host es WS2025, necesitas CALs de WS2025. Las de WS2022 no valen.
Lo único que funciona en ambas direcciones es tener un license server moderno. Un license server en WS2025 puede gestionar CALs de cualquier versión anterior. Pero uno en WS2022 no puede ni instalar CALs de WS2025. El instalador ni te las muestra.
Mi consejo: si vas a comprar CALs nuevas, cómpralas de la versión más moderna que tengas. Las de WS2025 funcionan con WS2022, WS2019 y anteriores. Y si el día de mañana actualizas el host, no tienes que recomprar.
Los puertos
Se me olvidaba. El session host necesita poder hablar con el license server. Si tienes firewall, estos puertos tienen que estar abiertos:
- TCP 135, 139, 445
- UDP 137, 138
- TCP 49152-65535 (RPC dinámico)
Resumen
| Tu caso | Solución |
| Servidor en dominio | GPEDIT, configurar license server + modo, reiniciar |
| Servidor en workgroup | GPEDIT + las credenciales del CVE-2024-38099 |
| Server Core | PowerShell con WMI o registro directamente |
| Error persistente | Comprueba que el license server es de la misma versión o superior que las CALs |
