Cuando el asistente de Agregar roles y características detiene la instalación de Remote Desktop Services con un error “indeterminado”, casi siempre se trata de un problema de servicios subyacentes: el Firewall está deshabilitado, el DNS no resuelve correctamente o faltan componentes base como .NET Framework.
Escenario típico y síntomas
El administrador prepara un nuevo servidor Windows Server para actuar como Host de Sesión de Escritorio Remoto o Connection Broker. Inicia el asistente, selecciona la colección adecuada y, al pulsar Instalar, recibe un mensaje genérico: “La instalación no se completó correctamente”. No aparece un código de error evidente y el registro indica simplemente Deployment failed. A menudo el Event Viewer registra el Id. 1297 o 3609 en el canal de RDS. El primer instinto es culpar al DNS, porque el mensaje sugiere que el servidor no puede ponerse en contacto con el Controlador de Dominio. Sin embargo, el 90 % de los casos se resuelven activando el servicio de Firewall antes de reiniciar la instalación.
Diagnóstico rápido: ¿Firewall, DNS o dependencias?
Para acotar la causa basta con tres comprobaciones de un minuto cada una:
- Servicios: ¿Windows Defender Firewall está Running y configurado en Automatic? Si está en Disabled, la instalación no puede crear sus reglas y falla en la fase de pre-validación.
- Nombre de host: ¿el FQDN responde a ping servidor.dominio.local? Un problema de DNS impedirá que se registren los roles de RDS en el catálogo de servicios.
- .NET y dependencias: ¿.NET Framework 4.x, el rol de Servicios de Licencias y la característica de Autenticación de Windows están instalados? Si faltan, el instalador aborta silenciosamente.
Procedimiento recomendado paso a paso
Verificar y arrancar el Firewall
RDS necesita crear reglas entrantes y salientes en la lista de políticas locales. Para confirmar su estado sin GUI:
Get-Service -Name 'MpsSvc' | Select-Object Status, StartType
Si el servicio aparece como Stopped o Disabled, arráncalo y cámbialo a Automatic:
Set-Service -Name 'MpsSvc' -StartupType Automatic
Start-Service -Name 'MpsSvc'
Reintentar la implementación desde Server Manager
Con el Firewall activo, vuelve a Inicio → Server Manager → Manage → Add Roles and Features. Selecciona la opción Remote Desktop Services Installation, elige el despliegue Standard y sigue el asistente. En la fase Confirmation, observa que la verificación previa ya no muestra advertencias sobre el Firewall.
Forzar habilitación RDP con PowerShell
Si el asistente sigue fallando—tal vez porque una GPO corporativa reinstala configuraciones—habilita RDP y crea las reglas manualmente:
$tss = Get-WmiObject -Namespace root\cimv2\terminalservices `
-Class Win32_TerminalServiceSetting
$tss.SetAllowTSConnections(1,0) # 1 = habilitar RDP, 0 = reglas por defecto
Esto llama internamente a Enable-NetFirewallRule para los perfiles Domain y Private, añade TCP 3389 y registra el endpoint en la ACL. Tras ejecutar el comando, repite el asistente o instala RDS con:
Install-WindowsFeature -Name RDS-RD-Server -IncludeManagementTools
Comprobaciones avanzadas que evitan falsos positivos de DNS
El Firewall era la causa —el instalador lo necesita para abrir puertos—; no obstante, conviene descartar fallos en el DNS que podrían manifestarse más adelante, cuando el Connection Broker intente balancear sesiones:
- Registros SRV: Desde el servidor, ejecuta nslookup -type=SRV ldap.tcp.dc._msdcs.dominio.local. Debes ver al menos un DC.
- Cache limpia: Borra la caché de resolución con ipconfig /flushdns y repite el ping al FQDN.
- Tiempo de replicación: Si creaste zonas o registros hace minutos, espera a que el período de replicación de AD los propague.
- Alias CNAME: RDS no tolera bien instalarse sobre un alias; usa siempre el nombre del equipo real.
Puertos críticos y cómo probarlos
La tabla siguiente resume los puertos indispensables para una instalación simple y cómo validarlos antes de invocar el asistente:
Puerto / Protocolo | Función | Comando de prueba | Consecuencia si está bloqueado |
---|---|---|---|
TCP 3389 | RDP a Host de Sesión | Test-NetConnection -ComputerName servidor -Port 3389 | No se abren sesiones y el asistente no valida el RDSH. |
TCP 5985 / 5986 | WinRM / PowerShell Remoting | winrm id -r:servidor | El instalador no puede gestionar servicios remotamente. |
TCP 443 | RD Gateway (opcional) | Test-NetConnection -ComputerName servidor -Port 443 | Acceso externo vía HTTPS no funcionará. |
Registro de eventos: tu caja negra
Nunca intentes depurar “a ciegas”. Abre Event Viewer → Applications and Services Logs → Microsoft → Windows → RemoteDesktopServices‑Deployment. Filtra por nivel Error. Los Id. 3609 (Error al configurar los servicios de Escritorio Remoto) y 1297 (Tarea detenida debido a servicios deshabilitados) son los más frecuentes cuando el Firewall está inactivo. Anota la hora exacta; compara con los registros de System para ver si se cambió alguna GPO en la misma marca temporal.
Buenas prácticas para evitar el problema en futuros servidores
Implementar Estas directrices en la imagen maestra o plantilla de tu hipervisor evita casi todos los incidentes de despliegue:
- Prepárate con componentes base: Agrega .NET Framework 4.8, la característica de Autenticación de Windows y el rol Licensing al VHD o al Template antes de unirlo al dominio.
- GPO de arranque de servicios críticos: Aplica una directiva que establezca Windows Defender Firewall y Remote Registry en Automatic.
- Scripts de pre-validación: Un script de PowerShell que ejecute Test-ComputerSecureChannel, valide puertos con Test-NetConnection y compruebe DNS reduce sorpresas.
- Documenta desviaciones: Si tu organización deshabilita el Firewall por defecto, documenta qué roles requieren activarlo temporalmente.
Tabla resumida de comprobaciones
Comprobación | Qué revisar | Por qué ayuda |
---|---|---|
DNS | FQDN y registros SRV resuelven entre servidor y DC | Sin resolución correcta, el Connection Broker no registra servicios. |
Roles previos | .NET Framework 4.x, Servicios de Licencias, Autenticación | Componentes base que RDS invoca durante la instalación. |
Puertos | TCP 3389, 5985/5986 y 443 abiertos | Bloqueo impide validación de conectividad. |
Firewall | Servicio MpsSvc iniciado en Automático | Permite creación automática de reglas. |
Eventos | Logs de RDS‑Deployment sin Id. 1297 ni 3609 | Aíslan la causa raíz y comprueban que la instalación completó. |
FAQ: preguntas frecuentes del equipo técnico
¿Puedo desactivar el Firewall después de instalar RDS?
No lo recomiendes. Varias actualizaciones de seguridad de Microsoft vuelven a validar reglas y pueden fallar si el servicio no está activo.
¿La resolución inversa PTR afecta a RDS?
No de forma directa, pero los asistentes de diagnóstico de red de Server Manager marcan advertencias si la IP carece de registro PTR; conviene configurarlo para evitar alertas.
¿Cómo sé que la licencia de RDS se aplicó?
Abre RD Licensing Diagnoser. Si ves la advertencia “El servidor de licencias no se ha activado”, usa slmgr.vbs /dlv para verificar el canal.
Instalé RDS pero los usuarios reciben error de perfil temporal
Confirma que el servidor tenga acceso al DFS de perfiles y que el User Profile Disk está en línea. Reasigna permisos NTFS si migraste la carpeta.
¿Puedo instalar Gateway, Web Access y Connection Broker en el mismo host?
Para entornos de laboratorio sí. En producción usa al menos dos hosts: uno para Gateway + Web Access en zona DMZ y otro interno para Connection Broker y RDSH.
Conclusión
El error genérico al desplegar Remote Desktop Services casi siempre se debe a la desactivación del Windows Defender Firewall. Habilitarlo, reiniciar la instalación y validar DNS, puertos y dependencias soluciona nueve de cada diez casos. Con las comprobaciones y scripts de esta guía podrás desplegar RDS de forma reproducible y sin sorpresas.