Windows como thin client: configurar Remote Desktop y políticas de sesión

Inicio » Tutoriales » Windows como thin client: configurar Remote Desktop y políticas de sesión

Convertir Windows en un thin client para conectarse por Escritorio remoto es una forma muy práctica de reciclar equipos, centralizar la gestión y simplificar la vida al departamento de TI. En lugar de mantener decenas de PCs completos, puedes hacer que arranquen directamente contra un servidor RDS o un entorno VDI y que el usuario vea un escritorio remoto como si fuera el suyo de siempre.

Configurar Remote Desktop, el cliente web RDP y las políticas de sesión requiere hilar fino: certificados, roles de Servicios de Escritorio remoto, licenciamiento, opciones del navegador, políticas de seguridad, etc. En las próximas secciones verás, con bastante detalle y en castellano de la calle, cómo aprovechar Windows como thin client, qué necesitas a nivel de servidor, cómo automatizar el inicio de sesión RDP y cómo controlar la experiencia del usuario con directivas y ajustes avanzados.

Conceptos básicos: Windows como thin client y tecnología de cliente ligero

La idea de usar Windows como thin client se apoya en la computación basada en servidor: el procesamiento duro, el almacenamiento y las aplicaciones viven en uno o varios servidores centrales, mientras que el dispositivo del usuario funciona solo como un terminal de acceso. Ese terminal puede ser un thin client dedicado, un miniPC barato o incluso un equipo viejo con Windows al que le pedimos poco más que arrancar y abrir un Escritorio remoto.

Un thin client, dicho en plata, es un ordenador “minimalista” que no guarda datos sensibles ni ejecuta aplicaciones pesadas de forma local. Depende de la conexión a red para abrir un escritorio o apps remotas. Esto reduce drásticamente el hardware necesario en el puesto, facilita el mantenimiento y desplaza casi toda la complejidad al servidor o al clúster de servidores.

Los principales beneficios de la tecnología de cliente ligero giran en torno a tres ejes: costes, seguridad y gestión. Al consumir menos energía y requerir hardware modesto, los costes operativos bajan. Al tener datos y aplicaciones centralizados, los riesgos de fuga de información en el puesto final se reducen. Y al poder actualizar y parchear en el servidor, el esfuerzo de administración cae en picado frente al modelo clásico de PC individual.

Desde el punto de vista de negocio, los clientes ligeros permiten escalar más fácilmente: incorporar nuevos usuarios suele implicar sumar licencias y recursos de servidor, no comprar estaciones potentes. Para entornos con muchos puestos, turnos o kioscos, o para organizaciones que quieren controlar su seguridad al milímetro, el enfoque de thin client encaja como un guante.

En el contexto concreto de Windows como thin client, el objetivo típico es que el usuario encienda el equipo, se autentique (o incluso se salte ese paso si procede) y aterrice directamente en una sesión de Escritorio remoto o en el cliente web RD, sin tener que ver el escritorio local de Windows más de lo estrictamente necesario.

Elegir hardware, servidor y software para un entorno de thin client

La pieza clave de la infraestructura es el servidor (o granja) de Escritorio remoto, ya sea un RDS on‑premise, un entorno VDI o, como se menciona en algunos casos, un despliegue futuro en Azure Virtual Desktop. Ese servidor es el que soportará el peso del procesamiento de todos los usuarios concurrentes y donde residirán los escritorios y aplicaciones.

A nivel de CPU, te interesa un procesador multinúcleo potente, sobre todo si vas a tener muchos usuarios simultáneos. No hay una cifra mágica, pero para entornos medianos es habitual apostar por procesadores de varios núcleos físicos con hyper‑threading, de forma que puedas repartir sesiones sin que el equipo se ahogue.

En memoria RAM, arrancar por debajo de 16 GB para RDS suele ser demasiado justo para algo serio. Cada sesión de usuario consume RAM adicional, así que conviene dimensionar partiendo de un mínimo razonable y añadir colchón según las aplicaciones que se vayan a usar (ofimática, navegadores con muchas pestañas, apps gráficas, etc.).

El almacenamiento en el servidor debería ser SSD o al menos una capa rápida dentro de una cabina SAN/NAS. El acceso ágil al perfil de usuario, a los documentos y a las máquinas virtuales (en caso de VDI) marca una diferencia notable en la percepción de rendimiento del usuario final.

En cuanto a los dispositivos thin client propiamente dichos, cualquier terminal con procesador de bajo consumo, memoria modesta y almacenamiento local mínimo puede servir si es capaz de ejecutar el cliente RDP de Microsoft o un navegador moderno compatible con el cliente web de Escritorio remoto. Muchos fabricantes ofrecen sistemas operativos específicos de thin client, pero un Windows ligero debidamente configurado también se puede comportar como tal.

La elección del sistema operativo de servidor condiciona mucho el diseño de la solución. Windows Server (2016 o posterior) es la opción natural cuando quieres usar Remote Desktop Services, RD Web y la integración completa con Active Directory. Linux, por su parte, puede jugar como servidor de escritorio remoto vía VNC, RDP de terceros u otras soluciones, pero si lo que buscas es exprimir al máximo el ecosistema Windows, lo habitual es ir a por Windows Server.

Encima de ese sistema operativo de servidor puedes montar distintas tecnologías: RDS puro, VDI de fabricantes como Citrix Virtual Apps and Desktops o VMware Horizon, o Azure Virtual Desktop si te vas a la nube. Todas comparten la filosofía thin client, aunque difieren en licenciamiento, herramientas de gestión y características avanzadas.

Preparar la infraestructura de Escritorio remoto para usar Windows como thin client

Para que tus “Windows‑thin‑clients” se conecten correctamente, necesitas una implementación de Servicios de Escritorio remoto bien montada. A nivel de roles, para el cliente web oficial de Microsoft se pide disponer, como mínimo, de un Agente de conexión de RD (RD Connection Broker), un Host de sesión de Escritorio remoto (RD Session Host), un Acceso web de RD (RD Web Access) y una Puerta de enlace de RD (RD Gateway) funcionando en Windows Server 2016 o 2019.

El licenciamiento RDS debe estar configurado por usuario y no por dispositivo cuando pretendes usar puestos tipo thin client que pueden ser “intercambiables”. Si se configura por dispositivo, corres el riesgo de quemar rápidamente todas las CAL disponibles si hay rotación de equipos o reutilización de terminales.

En la Puerta de enlace de Escritorio remoto basada en Windows 10 o Windows Server se requiere tener instalada la actualización KB4025334, o alguna acumulativa posterior que ya la incluya. Esta actualización es necesaria para soportar correctamente ciertas funciones del cliente web y del canal de comunicación seguro.

Los certificados de confianza pública son imprescindibles para el rol de Puerta de enlace RD y para RD Web Access. El navegador del usuario y el cliente RDP deben ver esos certificados como de confianza, sin advertencias. Lo habitual es usar certificados expedidos por una entidad pública y asegurarse de que el FQDN del servidor coincida con lo que figura en el certificado.

Los equipos a los que se conecten los usuarios (los servidores de sesión o máquinas VDI) han de ejecutar Windows 10 o posterior, o Windows Server 2016 o posterior. Con estas versiones, la experiencia con RDP y con el cliente web es notablemente mejor: más rendimiento, mejor compatibilidad con los gráficos y con la compresión de tráfico.

Configurar y publicar el cliente web de Escritorio remoto

El cliente web de Escritorio remoto permite acceder a escritorios y apps RDS desde un navegador compatible, sin necesidad de instalar el cliente RDP tradicional. Para un entorno de thin client basado en Windows, es muy útil: puedes planear que al iniciar sesión se abra el navegador a una URL fija de RD Web Client y, desde ahí, el usuario lance sus recursos remotos.

Antes de instalar el cliente web por primera vez, debes exportar el certificado que usa el Agente de conexión a Escritorio remoto para las conexiones RDP. En ese servidor, localiza el certificado correspondiente, expórtalo en formato .cer y cópialo al servidor donde reside el rol de Acceso web de RD, porque lo necesitarás para que el cliente web confíe en el Broker.

En el servidor RD Web Access, abre una consola de PowerShell con privilegios elevados. En Windows Server 2016 conviene actualizar el módulo PowerShellGet, porque la versión que viene de serie no soporta correctamente la instalación del módulo RDWebClientManagement. Para ello, se ejecuta un comando del estilo de Install-Module -Name PowerShellGet -Force.

A continuación se instala el módulo RDWebClientManagement desde la galería de PowerShell, mediante Install-Module -Name RDWebClientManagement. Este módulo proporciona los cmdlets necesarios para descargar, instalar, publicar, actualizar y quitar el cliente web de Escritorio remoto.

Con el módulo en su sitio, descargas el paquete más reciente del cliente web utilizando Install-RDWebClientPackage. Después, importas el certificado del Agente de conexión con Import-RDWebClientBrokerCert, indicando la ruta al .cer que exportaste en pasos previos. Este vínculo de confianza asegura que el navegador pueda validar el certificado del Broker cuando se establece la sesión.

El último paso de la primera instalación es publicar el cliente para producción, con un comando tipo Publish-RDWebClientPackage -Type Production -Latest. A partir de ahí, el cliente web queda expuesto en una URL del estilo https://FQDN_servidor/RDWeb/webclient/index.html, donde FQDN_servidor debe coincidir exactamente con el nombre que figuran los certificados de RD Web.

Una vez que compruebas que la URL de acceso funciona bien en un navegador moderno, puedes facilitarla a los usuarios o integrarla en el arranque de tus Windows‑thin‑clients. Basta con que los equipos arranquen, se logueen automáticamente (si la política de seguridad lo permite) y abran el navegador apuntando a esa dirección.

Actualización, desinstalación e instalación offline del cliente web

Cuando Microsoft lanza una nueva versión del cliente web de Escritorio remoto, es recomendable actualizar para obtener mejoras de rendimiento, nuevas funciones o correcciones de seguridad. La actualización se realiza desde PowerShell, otra vez en el servidor de RD Web Access, usando Install-RDWebClientPackage para bajar la última versión disponible.

Si quieres probar la versión nueva antes de dársela a todos los usuarios, puedes publicarla como tipo Test mediante Publish-RDWebClientPackage -Type Test -Latest. Esa versión quedará disponible en una URL de pruebas, generalmente similar a https://FQDN_servidor/RDWeb/webclient-test/index.html, de modo que un grupo reducido pueda verificar que todo va fino.

Cuando estés satisfecho con el comportamiento de la versión de prueba, la publicas en producción con Publish-RDWebClientPackage -Type Production -Latest, y así reemplazas el cliente que usan todos los usuarios. El cambio se aplicará en cuanto recarguen la página del cliente web en el navegador.

Si en algún momento necesitas quitar por completo el cliente web del servidor RD Web Access, dispones del cmdlet Uninstall-RDWebClient. Este comando se encarga de despublicar las versiones de prueba y de producción, eliminar los paquetes locales y borrar la configuración asociada.

Tras eso, también puedes eliminar el módulo RDWebClientManagement ejecutando Uninstall-Module -Name RDWebClientManagement. Esto deja el servidor limpio de restos de la implementación previa del cliente web, por si deseas reinstalar desde cero o no seguir usándolo.

En entornos sin acceso directo a Internet, el despliegue del cliente web se hace en dos fases. En una máquina con Internet, instalas e importas el módulo RDWebClientManagement, luego guardas el paquete del cliente web con Save-RDWebClientPackage en una carpeta (por ejemplo C:\WebClient\) y guardas el propio módulo con Find-Module … | Save-Module en el mismo directorio. Posteriormente copias esa carpeta al servidor RD Web Access aislado.

Dentro del servidor sin conexión, vuelves a importar o ubicar el módulo RDWebClientManagement, ya sea copiando su carpeta a una ruta incluida en $env:PSModulePath o ampliando esa variable para que apunte al directorio donde lo colocaste. Finalmente, instalas el paquete local del cliente web con Install-RDWebClientPackage -Source «C:\WebClient\rdwebclient-1.0.1.zip» (o el nombre de fichero correspondiente) y sigues el proceso habitual de publicación.

Conexión del cliente web RDP sin Puerta de enlace en Windows Server 2019

En algunos escenarios de laboratorio o redes internas controladas, puede interesarte permitir que el cliente web se conecte directamente al Agente de Escritorio remoto sin usar un rol de Puerta de enlace RD. En Windows Server 2019 esto se puede habilitar mediante WebSockets sobre un puerto seguro, ajustando certificados y registro.

Si el servidor del Agente de conexión aún no tiene certificado enlazado, debes ir al Administrador del servidor, sección de Servicios de Escritorio remoto, y en la parte de Información general de implementación entrar en las propiedades de la implementación. Desde la pestaña de Certificados, puedes crear o asignar un certificado para “Agente de conexión a Escritorio remoto – Habilitar inicio de sesión único”.

En el caso de que ya exista un certificado enlazado al Agente, abre ese certificado y copia su huella digital. Después, desde una consola de PowerShell con privilegios elevados, usas netsh http add sslcert para asociar ese certificado al puerto 3392 en todas las IP, indicando la huella y el almacén de certificados adecuado (por ejemplo, “Remote Desktop”).

El siguiente paso es modificar el registro de Windows en la clave HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, ajustando el valor WebSocketURI a algo como https://+:3392/rdp/. Esto habilita el punto de conexión WebSocket seguro que el cliente web usará para hablar con el Agente.

Si el Host de sesión RD está en un servidor distinto del Agente, debes repetir un esquema similar: emitir un certificado para el host de sesión, enlazarlo al puerto 3392 mediante netsh http add sslcert y configurar de nuevo la entrada WebSocketURI en el registro para que apunte a https://+:3392/rdp/.

Es importante que tanto el Host de sesión como el Agente de conexión ejecuten Windows Server 2019, que los certificados sean de confianza pública y que el Nombre Alternativo del Sujeto (SAN) coincida con el FQDN de cada máquina. El nombre común (CN) igualmente debe corresponder con ese FQDN para evitar problemas de validación en los clientes.

Configurar políticas de despliegue y ajustes del cliente web RDP

Una vez que el cliente web está publicado, te interesará controlar qué pueden tocar los usuarios y cómo se comporta la experiencia web. Para eso existen una serie de cmdlets que permiten fijar opciones a nivel de implementación, afectando así a todos los usuarios que entren por el cliente web.

El primer ajuste habitual es la supresión de telemetría. Por defecto, cada usuario puede decidir si permite o no el envío de datos de uso a Microsoft desde el panel de configuración del cliente web. Si, por motivos de seguridad o cumplimiento, quieres deshabilitar esa opción para todos, puedes establecer la configuración de “SuppressTelemetry” a true mediante Set-RDWebClientDeploymentSetting.

Cuando este valor está a false, el comportamiento es el estándar: el usuario ve la opción y puede activarla o desactivarla a voluntad. Al ponerlo en true, se bloquea el envío de telemetría y se impide que el usuario la active. Este tipo de control es muy útil en entornos regulados o con políticas internas estrictas.

Otro ajuste clave es el método de inicio de los recursos remotos. El cliente web permite, por defecto, que el usuario decida si abrir los recursos directamente en el navegador o descargarlos como un fichero .rdp para que los maneje el cliente local de Escritorio remoto instalado en el equipo. Con el parámetro “LaunchResourceInBrowser”, puedes forzar un comportamiento u otro a nivel global.

Si estableces LaunchResourceInBrowser a true, obligas a que todos los recursos remotos se ejecuten dentro del navegador. Si lo pones a false, fuerzas la descarga de archivos .rdp y su uso con el cliente RDP tradicional. Esto permite estandarizar la experiencia según lo que más convenga a tu organización o a tu estrategia de seguridad.

Si más adelante necesitas restaurar los ajustes de despliegue a sus valores por defecto, puedes usar cmdlets como Reset-RDWebClientDeploymentSetting indicando el nombre de cada parámetro que quieras devolver a la configuración original, por ejemplo para las opciones de telemetría o de lanzamiento en el navegador.

Configurar Windows para que actúe como thin client frente a RDP

Hasta ahora hemos visto sobre todo la parte de servidor y del cliente web; falta el toque final: conseguir que Windows, en el puesto, se comporte como un thin client de verdad, arrancando y yendo directo a la sesión RDP o al portal web sin que el usuario tenga que navegar por un escritorio local completo.

Una forma clásica es configurar el inicio automático de sesión en Windows con una cuenta dedicada, muy restringida mediante políticas, y usar el inicio automático de una aplicación al entrar en el sistema. Esa aplicación puede ser el cliente RDP tradicional apuntando a una conexión definida, o bien un navegador que cargue la URL del cliente web RD que has publicado.

En equipos dedicados exclusivamente a actuar como thin client, suele ser buena idea bloquear el acceso a configuraciones, paneles de control y aplicaciones locales innecesarias mediante Directivas de grupo (GPO) o ajustes locales. La idea es que el usuario encienda, vea un entorno mínimo y, tras uno o dos clics, ya esté dentro de su escritorio remoto corporativo.

Si en el futuro piensas migrar a un escenario VDI en la nube, como Azure Virtual Desktop, la lógica es muy similar: el thin client Windows seguirá apuntando a una URL concreta o a un feed RDP, solo que ahora el backend ya no será tu granja on‑premise, sino la infraestructura alojada en Azure. Esto te permite ir haciendo pruebas en laboratorio on‑premise antes de dar el salto definitivo.

En algunos dispositivos thin client comerciales, como modelos Wyse TX0, la filosofía es la misma aunque la interfaz sea distinta: conectas el dispositivo, lo arrancas, entras con una cuenta de administración, configuras un perfil que establece la conexión RDP a un servidor remoto (IP, FQDN, puerto, credenciales o SSO) y guardas esa configuración para que la sesión RDP se inicie de forma automática cada vez que el usuario enciende el terminal.

La meta común en todos estos casos es que el escritorio remoto se perciba como “el PC” por parte del usuario, mientras que el sistema local (Windows, un firmware propietario de thin client, etc.) queda en segundo plano, casi invisible y únicamente al servicio de la conexión.

Acceso a aplicaciones y recursos, mantenimiento y monitorización

Una vez que tus thin clients Windows se conectan sin problemas al servidor RDS o a la solución de VDI, toca organizar bien los escritorios y las apps remotas. Desde el servidor, puedes exponer escritorios completos o solo aplicaciones concretas, dependiendo de si quieres dar a cada usuario un entorno de trabajo completo o centrarte en unas cuantas aplicaciones empresariales.

La configuración de los escritorios virtuales o sesiones se hace a través del software de virtualización o de los propios Servicios de Escritorio remoto. Allí defines qué recursos están disponibles, con qué permisos, qué impresoras y unidades se redirigen y qué políticas se aplican a cada grupo de usuarios.

Las aplicaciones deben estar instaladas y actualizadas en el servidor, no en los thin clients. De ese modo, al desplegar una versión nueva o aplicar un parche, todo el mundo lo recibe de golpe porque se conecta al mismo backend. Esto es uno de los grandes puntos fuertes de la computación basada en servidor.

El mantenimiento y la monitorización del entorno se vuelven más sencillos, pero no por ello menos importantes. Hay que seguir aplicando parches de seguridad al sistema operativo del servidor, al cliente web, a las aplicaciones y a cualquier componente intermedio. Además, conviene usar herramientas de monitorización para vigilar el rendimiento, la carga de CPU, la RAM utilizada y la latencia de red.

En los clientes ligeros Windows, la rutina de mantenimiento suele limitarse a garantizar que el sistema arranca correctamente, el cliente RDP o el navegador están operativos y no hay problemas de hardware (ventilación, cableado, periféricos). Gracias a que casi todo se ejecuta en el servidor, el impacto de fallos de software en el puesto es mucho menor que en un PC tradicional.

Problemas típicos, diagnóstico y buenas prácticas

• En cualquier entorno de thin client apoyado en Escritorio remoto, los dolores de cabeza más habituales se relacionan con la conectividad, la compatibilidad de hardware, los fallos de software y las advertencias de seguridad en el navegador o en el propio RDP. La clave es tener un enfoque sistemático para ir descartando causas.
• Si el usuario no consigue ni siquiera cargar el cliente web o ve avisos de certificado poco tranquilizadores, revisa que el rol de Acceso web de RD tenga un certificado de confianza pública correctamente asignado y que la URL que usa el usuario incluya el FQDN del servidor que aparece en dicho certificado. De lo contrario, el navegador mostrará alertas y la experiencia será poco amigable.
• Cuando el usuario ve sus recursos en el portal pero no puede conectarse a ellos, conviene comprobar que la Puerta de enlace RD está bien configurada con un certificado público y que tiene instaladas las actualizaciones necesarias (en particular, la KB4025334 o sus sucesoras). Si el error hace referencia a un certificado de autenticación de servidor inesperado, suele mostrar la huella digital, lo que permite localizar rápidamente el certificado implicado en el servidor Broker.
• En ese caso, revisa en el administrador de certificados del servidor que el certificado correspondiente esté vigente, asociado al rol correcto de Agente de Escritorio remoto y exportado adecuadamente en formato .cer al servidor de RD Web Access. Si hace falta, vuelves a importar este certificado con Import-RDWebClientBrokerCert para que el cliente web confíe en él.
• Para problemas más sutiles o intermitentes, el cliente web ofrece una opción de captura de información de soporte. Desde los tres puntos de la esquina superior derecha accedes a la página “Acerca de” y allí puedes iniciar una grabación de la consola del navegador. Realizas las acciones que generan el problema, detienes la grabación y descargas un archivo de texto con los logs de consola de esa sesión, que luego puedes analizar o remitir a soporte.
• También puedes acceder directamente a las herramientas de desarrollo del navegador (por ejemplo, F12 en Microsoft Edge y luego la pestaña “Consola”) para ver errores de JavaScript, problemas de carga de recursos o cualquier otra anomalía durante el uso del cliente web. Esa información suele ser muy útil para identificar fallos de configuración o incompatibilidades del lado del navegador.
• Más allá del cliente web, hay que cuidar la red y la seguridad. Si hay desconexiones aleatorias o lentitud, empieza por revisar el cableado, los switches y la configuración de VLANs y firewalls. Usa herramientas como ping y traceroute para localizar dónde se produce la pérdida de paquetes o la alta latencia. Verifica también que los puertos RDP y los de la Puerta de enlace estén correctamente abiertos en todos los saltos de red.
• La compatibilidad de periféricos en thin clients puede dar guerra de vez en cuando, sobre todo con impresoras, escáneres o dispositivos USB especiales. Asegúrate de que el sistema operativo del thin client los reconoce, de que tienes los drivers adecuados y de que la redirección de dispositivos en RDP está habilitada según sea necesario y acorde a tus políticas de seguridad.
• Como medida de prevención, resulta muy útil establecer revisiones periódicas del estado general de la infraestructura: comprobar actualizaciones, revisar registros de eventos, validar la integridad del hardware y formar a los usuarios para que sepan cómo actuar ante problemas pequeños. Un poco de pedagogía puede ahorrarte muchas incidencias triviales convertidas en tickets urgentes.
• Existen soluciones de terceros como TSplus que añaden una capa adicional sobre RDS para simplificar aún más el despliegue y la publicación de aplicaciones, mejorar la experiencia de acceso remoto y ofrecer herramientas de administración centralizada. Para organizaciones que quieren ir un paso más allá en flexibilidad y control, este tipo de productos puede encajar en su estrategia de cliente ligero.

Usar Windows como thin client para Remote Desktop te permite alargar la vida del hardware, unificar el entorno de trabajo y reforzar la seguridad, siempre que dediques algo de tiempo a configurar correctamente la infraestructura RDS, el cliente web, los certificados y las políticas de sesión. Con una buena base y un poco de mimo en la documentación y el soporte, el resultado suele ser un entorno muy estable, fácil de operar y con usuarios que apenas notan que en realidad están trabajando “a distancia”.