Convertir un PC con Windows en un thin client totalmente orientado a Escritorio Remoto es una forma muy eficiente de alargar la vida de equipos antiguos, reducir costes y centralizar la gestión. En lugar de trabajar de forma local, el usuario inicia sesión directamente contra un servidor o una infraestructura VDI y todo el procesamiento se hace en el centro de datos o en la nube.
La idea es que el dispositivo arranque, cargue automáticamente la sesión RDP (o el cliente web) y aplique políticas de sesión y seguridad bien definidas, de manera que para el usuario se parezca a encender un “terminal tonto” de toda la vida. Vamos a ver, paso a paso y con bastante detalle, cómo encajar las piezas: tecnología de cliente ligero, Servicios de Escritorio Remoto, cliente web, certificados, directivas y resolución de problemas.
Qué es un thin client y por qué tiene sentido usar Windows como terminal ligero
Un thin client es, básicamente, un dispositivo muy sencillo que depende casi por completo de un servidor remoto para ejecutar aplicaciones, almacenar datos y, en general, hacer el trabajo duro. El equipo final solo se encarga de mostrar la interfaz, gestionar teclado/ratón y poco más.
Cuando usamos un PC con Windows como thin client, lo que hacemos es reducir al mínimo el uso local de recursos y configurar el sistema para que se conecte automáticamente a una sesión RDP, a un escritorio virtual o a aplicaciones remotas publicadas.
Este enfoque tiene ventajas claras: el hardware del usuario puede ser modesto, las incidencias se resuelven en el servidor, y los datos no quedan desperdigados por cada ordenador de la oficina, sino centralizados y protegidos en el CPD o en la nube.
Además, el modelo thin client encaja perfectamente con soluciones modernas como Azure Virtual Desktop, RDS en Windows Server o VDI de terceros (Citrix, VMware, TSplus, etc.), que ya están pensadas para que muchas sesiones se sirvan desde un único entorno centralizado.
Ventajas clave de la tecnología de cliente ligero
La tecnología de cliente ligero parte de un principio muy sencillo: mover el procesamiento y los datos al servidor. Ese cambio de enfoque trae una serie de beneficios que justifican, por sí solos, el esfuerzo de montar una infraestructura de Escritorio Remoto bien diseñada.
En términos de costes, los thin clients suelen ser dispositivos más simples, con menos disco y menos potencia de CPU, por lo que consumen menos energía y tienen una vida útil más larga. Incluso un PC antiguo con Windows se puede reconvertir en terminal ligero y seguir siendo útil unos años más.
Desde el punto de vista de la seguridad, al trabajar contra servidores centrales, las aplicaciones críticas y los datos sensibles se quedan en el back-end. El riesgo de robo de información en el puesto se reduce, y es más fácil aplicar cifrado, copias de seguridad y controles de acceso desde un punto único.
En administración de TI, la ganancia es enorme: las actualizaciones, parches y cambios de configuración se ejecutan en el servidor o en las imágenes VDI, lo que permite una gestión centralizada en lugar de ir equipo a equipo. Añadir nuevos usuarios o departamentos pasa a ser cuestión de minutos.
Por último, es un entorno muy escalable: si la demanda crece, se amplían recursos de servidor o se añaden nuevas máquinas al “pool” de sesiones y los usuarios pueden conectarse desde más terminales ligeros sin grandes inversiones en puestos de trabajo.
Elegir hardware, sistema operativo y software de virtualización
Para usar Windows como thin client apoyándose en Remote Desktop, hay que pensar siempre en el servidor como el corazón del sistema. El equipo del usuario importa, pero lo que realmente marca el rendimiento es la capacidad del servidor y la red que los une.
En el servidor, conviene apostar por un procesador multinúcleo con buena frecuencia, ya que va a atender varias sesiones de usuario en paralelo. Para entornos pequeños se puede empezar con unos pocos núcleos, pero en escenarios con decenas de usuarios simultáneos, un hardware de clase servidor es casi obligatorio.
La memoria RAM es otro punto crítico: cada sesión RDP o VDI consume su parte, así que 16 GB es un mínimo razonable para entornos pequeños, mientras que en instalaciones medianas y grandes es habitual superar los 32 o 64 GB. El almacenamiento, mejor en SSD, para que las escrituras y lecturas sean ágiles y las sesiones no se sientan pesadas.
Respecto a los dispositivos thin client, se puede optar por terminales dedicados del fabricante o por PCs reutilizados con un Windows ligero. Lo importante es que dispongan de buena conectividad de red y soporte para el cliente RDP (o para el navegador moderno si se apuesta por el cliente web) y, si hace falta, compatibilidad con periféricos concretos (lectores de tarjetas, impresoras, etc.).
En cuanto al sistema operativo de servidor, lo habitual es Windows Server (2016, 2019 o posterior) con Servicios de Escritorio Remoto. También es posible combinar con entornos Linux para otras tareas, pero para RDP y Remote Desktop Services la integración natural es con Windows Server. Como software VDI adicional, muchas organizaciones incorporan Citrix Virtual Apps and Desktops, VMware Horizon o soluciones como TSplus para escenarios de publicación de aplicaciones y accesos web simplificados.
Preparación de la infraestructura de Escritorio Remoto para usar Windows como thin client
Antes de que el usuario encienda su equipo y entre directamente en su escritorio remoto, hay que tener la infraestructura de RDS bien montada. Esto pasa por desplegar y configurar los roles clásicos de Escritorio Remoto y asegurarse de que todo está correctamente certificado y licenciado.
Una implementación típica va a incluir, al menos, un servidor con el rol de Agente de conexión de Escritorio Remoto (RD Connection Broker), otro con el rol de Acceso web de RD (RD Web Access) y una Puerta de enlace de Escritorio Remoto (RD Gateway) si queremos accesos desde fuera de la red interna. En muchos entornos, uno o varios servidores actúan además como Host de Sesión de Escritorio Remoto.
Es importante que la infraestructura esté configurada para usar licencias RDS tipo CAL de usuario y no de dispositivo, porque si no podríamos consumir rápidamente todas las licencias al reutilizar equipos ligeros. Esta elección se hace en la configuración de licenciamiento de Servicios de Escritorio Remoto.
En la parte de actualizaciones, Microsoft exige que el servidor Gateway cuente con determinadas KB para que el cliente web de Escritorio Remoto funcione correctamente. Una de las más citadas es la KB4025334 en Windows 10 y sus acumulativas posteriores, que suele venir incluida en updates más recientes. Conviene revisar que el sistema está al día.
El tema de los certificados digitales no es menor: para que el acceso sea seguro y no llenemos de avisos a los usuarios, es recomendable configurar certificados de confianza pública tanto para la Puerta de enlace RD como para el Acceso web de RD. El FQDN que se utilice en la URL debe coincidir con el certificado, y el navegador tiene que confiar en esa CA.
Configuración y publicación del cliente web de Escritorio Remoto
El cliente web de Escritorio Remoto permite acceder a escritorios y aplicaciones publicadas desde un navegador moderno (Edge, Chrome, etc.), sin instalar el cliente RDP tradicional. Esto es ideal cuando queremos que el thin client simplemente abra un navegador y cargue la URL del web client, dejando el resto del trabajo al servidor.
Para configurarlo, primero hay que asegurarse de que la implementación de RDS dispone de RD Gateway, RD Connection Broker y RD Web Access sobre Windows Server 2016 o 2019. A partir de ahí, se trabaja sobre el servidor que aloja el rol de Acceso web de RD utilizando módulos PowerShell específicos.
El proceso estándar de instalación del cliente web pasa por abrir una consola de PowerShell con privilegios elevados en el servidor de RD Web Access y, en el caso de Windows Server 2016, actualizar el módulo PowerShellGet con un comando como Install-Module -Name PowerShellGet -Force para poder instalar el resto de módulos desde la galería.
Después se instala el módulo RDWebClientManagement con un comando tipo Install-Module -Name RDWebClientManagement. A continuación, se descarga la versión más reciente del paquete web usando Install-RDWebClientPackage, que se encarga de traer el contenido del cliente desde la PowerShell Gallery.
Con el paquete descargado, hay que importar el certificado del Broker RDS en el servidor de RD Web Access usando un comando como Import-RDWebClientBrokerCert <ruta del .cer>, para que el cliente web pueda confiar en el agente de conexión. Finalmente, se publica el paquete mediante Publish-RDWebClientPackage -Type Production -Latest, de forma que el cliente quede accesible en una URL con formato https://FQDN_servidor/RDWeb/webclient/index.html.
Cuando salga una nueva versión del cliente web, basta con repetir la descarga con Install-RDWebClientPackage y actualizar la publicación ejecutando Publish-RDWebClientPackage -Type Production -Latest, pudiendo usar antes el modo Test si se quiere validar la nueva versión en una URL alternativa sin afectar a todos los usuarios.
Instalación, desinstalación y escenarios sin acceso a Internet
En ocasiones puede ser necesario quitar por completo el cliente web de Escritorio Remoto, por ejemplo si se ha instalado una versión previa o de pruebas que ya no interesa mantener. Para ello, desde el servidor de RD Web Access se despublican los paquetes y se elimina toda la configuración con Uninstall-RDWebClient.
El siguiente paso es desinstalar el módulo de administración con un comando tipo Uninstall-Module -Name RDWebClientManagement. Si previamente se había usado una versión antigua del módulo y el sistema se queja de incompatibilidades, puede hacer falta reinstalar aquella versión concreta para poder ejecutar Uninstall-RDWebClient y dejar el entorno limpio antes de pasar a una nueva release.
En redes aisladas, sin capacidad de salir a Internet desde el servidor de RD Web Access, se puede preparar la instalación del cliente web desde otro equipo que sí tenga acceso a la red exterior. En esa máquina, se importa el módulo RDWebClientManagement, se guarda el paquete del cliente web en una carpeta local mediante Save-RDWebClientPackage «C:\WebClient\» y se descargan también los archivos del módulo con Find-Module -Name «RDWebClientManagement» | Save-Module -Path «C:\WebClient\».
Una vez copiado todo el contenido de esa carpeta al servidor de RD Web Access, se tienen dos opciones: importar directamente el módulo desde la ruta donde se ha copiado o mover la carpeta a una de las ubicaciones incluidas en $env:PSModulePath. Con el módulo disponible en local, se instala el paquete usando Install-RDWebClientPackage -Source «C:\WebClient\rdwebclient-x.y.z.zip» y se continúa con los pasos de publicación habituales.
De esta forma, incluso en entornos con controles de red muy estrictos, se puede disponer de un cliente web de Escritorio Remoto plenamente funcional, sin necesidad de que los servidores de producción lleguen directamente a la PowerShell Gallery.
Conexión del cliente web al Broker sin puerta de enlace en Windows Server 2019
En Windows Server 2019 existe la opción de permitir que el cliente web se conecte al Agente de Escritorio Remoto sin necesidad de una Puerta de enlace RD, algo útil en entornos internos o de laboratorio. Este escenario requiere ajustar certificados y parámetros de WebSocket en el servidor Broker y, si aplica, en el Host de Sesión.
Si el servidor del Agente de conexión no tiene todavía un certificado enlazado, desde el Administrador del servidor se entra en Servicios de Escritorio Remoto, se abre la vista de implementación, se va al menú Tareas y se elige Editar propiedades de la implementación. En la pestaña de Certificados se selecciona la entrada de Agente de conexión – Habilitar inicio de sesión único y se crea un nuevo certificado o se usa uno ya existente, de confianza pública o de la PKI corporativa.
Si ya existe un certificado enlazado, se puede reutilizar copiando su huella digital desde la consola de certificados. Con ese thumbprint, se abre PowerShell como administrador y se ejecuta un comando netsh http add sslcert ipport=0.0.0.0:3392 certhash=»<huella>» certstorename=»Remote Desktop» appid=»{GUID}», para asociar el certificado al puerto seguro 3392 que empleará el canal WebSocket.
Acto seguido, se entra en el Registro de Windows (regedit) y se localiza la clave HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Dentro de esa clave hay un valor llamado WebSocketURI que se debe fijar a https://+:3392/rdp/, indicando así la ruta que utilizará el cliente web para hablar con el Broker vía WebSocket.
Si el servidor Host de Sesión de Escritorio Remoto es diferente del Agente de conexión, hay que replicar un proceso similar en el host de sesión: crear o asignar un certificado, enlazarlo al puerto 3392 mediante netsh, y comprobar que el valor WebSocketURI en el registro coincide con https://+:3392/rdp/. Todo esto debe hacerse en servidores Windows Server 2019 con certificados públicos válidos, con el SAN configurado al FQDN de la máquina y el CN igual que el SAN.
Políticas y ajustes del cliente web: telemetría y forma de lanzar recursos
Una vez que el cliente web funciona, es posible que quieras limitar qué pueden tocar los usuarios dentro de su panel de configuración. Microsoft proporciona una serie de cmdlets para controlar el comportamiento de la interfaz, especialmente en lo referente a telemetría y forma de iniciar los recursos remotos.
Por defecto, el usuario puede decidir si envía o no datos de telemetría a Microsoft desde el panel Acerca de. Si la organización prefiere bloquear el envío de datos por política, se puede ejecutar un comando como Set-RDWebClientDeploymentSetting -Name «SuppressTelemetry» $true. Con ese valor true, la telemetría queda deshabilitada y el usuario no puede volver a activarla.
En cuanto a la forma de iniciar escritorios y aplicaciones, normalmente el cliente web permite elegir entre abrir el recurso en el propio navegador o bien descargar un archivo .rdp para usarlo con un cliente RDP local. Eso se puede fijar mediante la opción LaunchResourceInBrowser, usando Set-RDWebClientDeploymentSetting -Name «LaunchResourceInBrowser» $true o $false.
Si se establece LaunchResourceInBrowser a true, el usuario deberá lanzar siempre los recursos en el navegador, sin opción de descarga. Si se fija a false, en cambio, los recursos se iniciarán siempre descargando el archivo .rdp, pensados para clientes RDP instalados en la máquina local, algo menos habitual cuando el dispositivo se usa como thin client puro.
Si más adelante se quiere volver a la configuración por defecto, se puede utilizar Reset-RDWebClientDeploymentSetting con el parámetro -Name para cada ajuste, por ejemplo Reset-RDWebClientDeploymentSetting -Name «LaunchResourceInBrowser» o Reset-RDWebClientDeploymentSetting -Name «SuppressTelemetry». Así se devuelve el control al comportamiento original del cliente web.
Configuración de red, arranque directo y políticas de sesión para Windows como thin client
Para que un PC con Windows actúe de verdad como terminal ligero, es clave cuidar tanto la red como el propio proceso de inicio de sesión en el equipo. La idea es que el usuario apenas vea Windows y entre casi de inmediato en su sesión RDP o en el cliente web.
En la parte de red, conviene contar con una topología estable, buena calidad de switches y, si se puede, segmentación mediante VLANs para aislar el tráfico de Escritorio Remoto. Los servidores DHCP deben estar bien configurados para que los thin clients obtengan IP de forma automática y consistente, y los DNS deben resolver correctamente el FQDN del servidor RD Web y del Broker.
En el cortafuegos, tanto del perímetro como en los propios servidores, hay que abrir los puertos necesarios para RDP, RD Gateway y WebSocket (cuando aplique). Una configuración demasiado restrictiva puede hacer que los usuarios vean los iconos en “Todos los recursos” pero no puedan conectarse, o que aparezcan errores de certificado al establecer la sesión.
En el lado del dispositivo con Windows, se puede usar el Programador de tareas, scripts de inicio de sesión o directivas de grupo para que al arrancar el sistema se abra automáticamente el cliente RDP o el navegador apuntando a la URL del cliente web. Combinando esto con políticas locales o de dominio, se pueden restringir accesos al escritorio local, al Explorador de archivos o al Panel de control para que el usuario solo utilice la sesión remota.
Las políticas de sesión RDS (directivas de tiempo de inactividad, cierre de sesión tras X minutos, límites de reconexión, etc.) se pueden aplicar desde la consola de Servicios de Escritorio Remoto o mediante GPOs, de modo que el servidor controle cuántos recursos consume cada usuario y evite sesiones colgadas eternamente que penalicen el rendimiento global.
Solución de problemas frecuentes en entornos de thin client y Escritorio Remoto
En la práctica, gestionar un entorno de Windows como thin client con Remote Desktop implica lidiar con incidencias recurrentes: desde problemas de red hasta certificados caducados, pasando por errores en el cliente web. Tener un método ordenado de diagnóstico ahorra mucho tiempo y evita apagafuegos constantes.
Los problemas de conectividad suelen ser los más habituales: cortes intermitentes, sesiones que se congelan o equipos que no consiguen llegar al servidor. Ante esto, lo primero es revisar cableado, switches y routers, y usar herramientas como ping o tracert para comprobar si la ruta entre thin client y servidor es estable. También conviene asegurarse de que la latencia no es excesiva, sobre todo si los usuarios se conectan desde sedes remotas.
En algunos casos, es la configuración del firewall la que impide el buen funcionamiento: puertos RDP, HTTPS, y los específicos de Gateway y WebSocket deben estar correctamente abiertos. Una regla mal planteada puede dejar acceder a la página de RD Web Access, pero bloquear el canal de datos que usa la sesión RDP real, generando errores aparentemente inexplicables.
Otros fallos tienen que ver con compatibilidad de hardware: aunque los thin clients son sencillos, los periféricos (impresoras, escáneres, lectores de tarjetas, etc.) pueden requerir drivers específicos o redirecciones adecuadas a través de RDP. Cuando un dispositivo no es reconocido, suele ayudar revisar la documentación del fabricante y comprobar si el sistema operativo del terminal ligero está soportado.
Por último, los fallos de software tanto en el servidor como en el propio thin client pueden provocar bloqueos de aplicaciones o cierres inesperados de sesión. Mantener Windows Server, Windows 10/11 y el resto de componentes al día con los parches de seguridad y correcciones de errores es fundamental para evitar problemas ya conocidos que Microsoft haya solucionado en versiones posteriores.
Errores habituales del cliente web, certificados y registro de consola
El cliente web de Escritorio Remoto añade su propia lista de incidentes típicos. Uno de los más frecuentes es que el navegador muestre una advertencia de seguridad al intentar acceder a la URL del web client. Esto suele indicar que el rol de RD Web Access no está usando un certificado de confianza pública o de una CA reconocida por el equipo del usuario.
Si el certificado es válido pero sigue apareciendo el aviso, probablemente la URL que el usuario está usando no coincide con el nombre del certificado: por ejemplo, entrar con IP o con un alias distinto al FQDN. En ese caso, basta con asegurarse de que la dirección usa el FQDN correcto que figura en el certificado (generalmente el nombre completo del servidor).
Otro error recurrente es que el usuario vea sus escritorios y aplicaciones en “Todos los recursos”, pero al hacer clic no consiga establecer la conexión. Aquí hay que verificar, de nuevo, la configuración del certificado de la Puerta de enlace RD y las actualizaciones requeridas (como KB4025334). Además, si se muestra un mensaje sobre un certificado inesperado con una huella digital concreta, esa huella ayuda a localizar en el almacén de certificados qué certificado se está usando realmente para el rol de Agente de Escritorio Remoto.
Una vez localizado el certificado correcto, se comprueba que no haya caducado, se exporta en formato .cer y se copia al servidor de RD Web Access para volver a ejecutar Import-RDWebClientBrokerCert con la ruta adecuada. Con esto, el cliente web vuelve a confiar en el Broker correcto y desaparecen las advertencias relacionadas.
Si nada de esto resuelve el problema, el propio cliente web incorpora una función de captura de información de soporte. Desde el menú (los tres puntos), en la página Acerca de, se puede pulsar en Iniciar grabación, reproducir el problema, y luego pulsar Detener grabación. El navegador descargará un archivo de texto con el log de consola, que incluye los mensajes de error de JavaScript y del propio cliente, muy útiles para un análisis más profundo.
Además de esa herramienta integrada, siempre se puede abrir la consola de desarrollador del navegador (por ejemplo, con F12 en Microsoft Edge) y revisar directamente los errores en la pestaña Consola. Esta información complementa los logs del servidor (eventos de Remote Desktop Services, IIS, etc.) y permite tener una visión completa de lo que está fallando en la comunicación entre cliente web y backend.
Buenas prácticas, mantenimiento y herramientas de terceros
Para que un entorno de Windows como thin client sea estable a largo plazo, no basta con configurarlo una vez y olvidarse. Es necesario establecer una rutina de mantenimiento y monitorización que permita detectar problemas antes de que estallen y mantener la seguridad en niveles aceptables.
Una práctica recomendable es realizar revisiones periódicas de la plataforma: comprobar el estado de los servidores, revisar el consumo de CPU, RAM y disco, y analizar los logs en busca de patrones de error. Herramientas de monitorización de red y de rendimiento, tanto nativas como de terceros, ayudan a identificar cuellos de botella y a planificar ampliaciones de capacidad.
También es muy útil documentar bien cada cambio de configuración, actualización o nueva versión de cliente web que se despliegue. Llevar un registro detallado hace mucho más fácil volver atrás o entender qué pudo desencadenar un problema recurrente. Esto incluye escribir procedimientos para la instalación del cliente web, el manejo de certificados y la configuración de políticas.
En cuanto al soporte, además de los canales oficiales de Microsoft (como el foro de Azure Virtual Desktop en Microsoft Tech Community), existen soluciones de terceros tipo TSplus que simplifican la publicación de aplicaciones y escritorios vía web, añaden capas de seguridad y facilitan la administración de entornos con muchos usuarios remotos.
Combinando una buena base de Servicios de Escritorio Remoto con una política clara de telemetría, certificados bien gestionados, un diseño de red robusto y herramientas de gestión o VDI complementarias, un PC con Windows se convierte sin demasiadas complicaciones en un thin client fiable, fácil de administrar y preparado para crecer con las necesidades de la organización.