Windows com thin client: configurar Remote Desktop i polítiques de sessió

  • Windows es pot reutilitzar com a thin client connectant directament a Escriptori Remot o VDI, centralitzant dades i processament al servidor.
  • Una infraestructura RDS ben dissenyada (Broker, Gateway, RD Web, certificats vàlids i CAL per usuari) és clau per a estabilitat i seguretat.
  • El client web d'Escriptori Remot permet accés via navegador, es gestiona amb PowerShell i admet ajustaments fins de telemetria i llançament de recursos.
  • La combinació de bones polítiques de sessió, xarxa robusta i monitorització continua garanteix un entorn de thin client eficient i fàcil de mantenir.

Windows com thin client

Convertir un PC amb Windows en un thin client totalment orientat a escriptori Remot és una manera molt eficient d'allargar la vida d'equips antics, reduir costos i centralitzar-ne la gestió. En lloc de treballar de manera local, l'usuari inicia sessió directament contra un servidor o una infraestructura VDI i tot el processament es fa al centre de dades o al núvol.

La idea és que el dispositiu arrenqui, carregueu automàticament la sessió RDP (o el client web) i apliqui polítiques de sessió i seguretat ben definides, de manera que per a l'usuari s'assembli a encendre un “terminal ximple” de tota la vida. A veure, pas a pas i amb força detall, com encaixar les peces: tecnologia de client lleuger, Serveis d'Escriptori Remot, client web, certificats, directives i resolució de problemes.

Què és un thin client i per què té sentit utilitzar Windows com a terminal lleuger

Un thin client és, bàsicament, un dispositiu molt senzill que depèn gairebé del tot d'un servidor remot per executar aplicacions, emmagatzemar dades i, en general, fer la feina dura. L'equip final només s'encarrega de mostrar la interfície, gestionar teclat/ratolí i poca cosa més.

Quan fem servir un PC amb Windows com a thin client, el que fem és reduir al mínim l'ús local de recursos i configurar el sistema perquè es connecti automàticament a una sessió RDP, a un escriptori virtual oa aplicacions remotes publicades.

Aquest enfocament té avantatges clars: el maquinari de lusuari pot ser modest, les incidències es resolen al servidor, i les dades no queden escampats per cada ordinador de l'oficina, sinó centralitzats i protegits al CPD o al núvol.

A més, el model thin client encaixa perfectament amb solucions modernes com Azure Virtual Desktop, RDS al Windows Server o VDI de tercers (Citrix, VMware, TSplus, etc.), que ja estan pensades perquè moltes sessions se serveixin des d'un únic entorn centralitzat.

Avantatges clau de la tecnologia de client lleuger

La tecnologia de client lleuger parteix d'un principi molt senzill: moure el processament i les dades al servidor. Aquest canvi d‟enfocament porta una sèrie de beneficis que justifiquen, per si sols, l‟esforç de muntar una infraestructura d‟Escriptori Remot ben dissenyada.

En termes de costos, els thin clients solen ser dispositius més simples, amb menys disc i menys potència de CPU, per la qual cosa consumeixen menys energia i tenen una vida útil més llarga. Fins i tot un PC antic amb Windows es pot reconvertir en terminal lleuger i continuar sent útil uns anys més.

Des del punt de vista de la seguretat, en treballar contra servidors centrals, les aplicacions crítiques i les dades sensibles es queden al back-end. El risc de robatori dinformació en el lloc es redueix, i és més fàcil aplicar xifrat, còpies de seguretat i controls daccés des dun punt únic.

En administració de TI, el guany és enorme: les actualitzacions, pegats i canvis de configuració s'executen al servidor oa les imatges VDI, cosa que permet una gestió centralitzada en lloc d'anar equip a equip. Afegir nous usuaris o departaments passa a ser qüestió de minuts.

Finalment, és un entorn molt escalable: si la demanda creix, s'amplien recursos de servidor o s'afegeixen noves màquines al “pool” de sessions i els usuaris poden connectar-se des de més terminals lleugers sense grans inversions en llocs de treball.

Triar maquinari, sistema operatiu i programari de virtualització

Per utilitzar Windows com a thin client recolzant-se a Remote Desktop, cal pensar sempre en el servidor com el cor del sistema. L'equip de l'usuari importa, però el que realment marca el rendiment és la capacitat del servidor i la xarxa que els uneix.

Al servidor, convé apostar per un processador multinucli amb bona freqüència, ja que va a atendre diverses sessions d'usuari en paral·lel. Per a entorns petits es pot començar amb uns quants nuclis, però en escenaris amb desenes dusuaris simultanis, un maquinari de classe servidor és gairebé obligatori.

La memòria RAM és un altre punt crític: cada sessió RDP o VDI en consumeix la part, així que 16 GB és un mínim raonable per a entorns petits, mentre que en instal·lacions mitjanes i grans és habitual superar els 32 o 64 GB. L'emmagatzematge, millor a SSD, perquè les escriptures i lectures siguin àgils i les sessions no se sentin pesades.

Pel que fa als dispositius thin client, es pot optar per terminals dedicats del fabricant o per PCs reutilitzats amb un Windows lleuger. L'important és que disposin de bona connectivitat de xarxa i suport per al client RDP (o per al navegador modern si s'aposta pel client web) i, si cal, compatibilitat amb perifèrics concrets (lectors de targetes, impressores, etc.).

Pel que fa al sistema operatiu de servidor, el que és habitual és Windows Server (2016, 2019 o posterior) amb Serveis d'Escriptori Remot. També és possible combinar amb entorns Linux per a altres tasques, però per a RDP i Remote Desktop Services la integració natural és amb Windows Server. Com a programari VDI addicional, moltes organitzacions incorporen Citrix Virtual Apps and Desktops, VMware Horizon o solucions com ara TSplus per a escenaris de publicació d'aplicacions i accessos web simplificats.

Preparació de la infraestructura d'Escriptori Remot per utilitzar Windows com a thin client

Abans que l'usuari encengui el seu equip i entri directament al vostre escriptori remot, cal tenir la infraestructura de RDS ben muntada. Això passa per desplegar i configurar els rols clàssics d'Escriptori Remot i assegurar-se que tot està correctament certificat i llicenciat.

Una implementació típica inclourà, almenys, un servidor amb el rol de Agent de connexió d'Escriptori Remot (RD Connection Broker), un altre amb el rol de Accés web de RD (RD Web Access) i una Porta d'enllaç d'Escriptori Remot (RD Gateway) si volem accessos des de fora de la xarxa interna. En molts entorns, un o diversos servidors actuen a més com a Host de Sessió d'Escriptori Remot.

És important que la infraestructura estigui configurada per fer servir llicències RDS tipus CAL d'usuari i no de dispositiu, perquè si no podríem consumir ràpidament totes les llicències en reutilitzar equips lleugers. Aquesta elecció es fa a la configuració de llicenciament de Serveis d'Escriptori Remot.

A la part d'actualitzacions, Microsoft exigeix ​​que el servidor Gateway tingui determinades KB perquè el client web d'Escriptori Remoto funcioni correctament. Una de les més citades és la KB4025334 a Windows 10 i les seves acumulatives posteriors, que sol venir inclosa en updates més recents. Convé revisar que el sistema és al dia.

El tema dels certificats digitals no és menor: perquè l'accés sigui segur i no omplim els usuaris avisos, és recomanable configurar certificats de confiança pública tant per a la Porta d'enllaç RD com per a l'Accés web de RD. El FQDN que s'utilitzi a la URL ha de coincidir amb el certificat, i el navegador ha de confiar en aquesta CA.

Configuració i publicació del client web d'Escriptori Remot

El client web d'Escriptori Remot permet accedir a escriptoris i aplicacions publicades des d'un navegador modern (Edge, Chrome, etc.), sense instal·lar el client RDP tradicional. Això és ideal quan volem que el thin client simplement obriu un navegador i carregueu la URL del web client, deixant la resta de la feina al servidor.

Per configurar-lo, primer cal assegurar-se que la implementació de RDS disposa de RD Gateway, RD Connection Broker i RD Web Access sobre Windows Server 2016 o 2019. A partir d'aquí, es treballa sobre el servidor que allotja el rol d'accés web de RD utilitzant mòduls PowerShell específics.

El procés estàndard d'instal·lació del client web passa per obrir una consola de PowerShell amb privilegis elevats al servidor de RD Web Access i, en el cas del Windows Server 2016, actualitzar el mòdul PowerShellGet amb una ordre com Install-Module -Name PowerShellGet -Force per poder instal·lar la resta de mòduls des de la galeria.

Després s'instal·la el mòdul RDWebClientManagement amb una ordre tipus Mòdul d'instal·lació -Nom RDWebClientManagement. A continuació, es baixa la versió més recent del paquet web usant Install-RDWebClientPackage, que s'encarrega de portar el contingut del client des de la PowerShell Gallery.

Amb el paquet descarregat, cal importar el certificat del Broker RDS al servidor de RD Web Access usant una ordre com Import-RDWebClientBrokerCert, perquè el client web pugui confiar en lagent de connexió. Finalment, es publica el paquet mitjançant Publish-RDWebClientPackage -Type Production -Latest, de manera que el client quedi accessible en una URL amb format https://FQDN_servidor/RDWeb/webclient/index.html.

Quan surti una nova versió del client web, només cal repetir la descàrrega amb Install-RDWebClientPackage i actualitzar la publicació executant Publish-RDWebClientPackage -Type Production -Latest, podent utilitzar abans el mode Test si es vol validar la nova versió en una URL alternativa sense afectar tots els usuaris.

Instal·lació, desinstal·lació i escenaris sense accés a Internet

De vegades pot ser necessari treure completament el client web d'Escriptori Remot, per exemple si s'ha instal·lat una versió prèvia o de proves que ja no interessa mantenir. Per això, des del servidor de RD Web Access es despublicen els paquets i s'elimina tota la configuració amb Uninstall-RDWebClient.

El pas següent és desinstal·lar el mòdul d'administració amb una ordre tipus Uninstall-Module -Name RDWebClientManagement. Si prèviament s'havia fet servir una versió antiga del mòdul i el sistema es queixa d'incompatibilitats, pot fer falta reinstal·lar aquella versió concreta per poder executar Uninstall-RDWebClient i deixar l'entorn net abans de passar a un nou release.

En xarxes aïllades, sense capacitat de sortir a Internet des del servidor de RD Web Access, es pot preparar la instal·lació del client web des d'un altre equip que sí que tingui accés a la xarxa exterior. En aquesta màquina, importa el mòdul RDWebClientManagement, es desa el paquet del client web en una carpeta local mitjançant Save-RDWebClientPackage C:\WebClient\ i es descarreguen també els fitxers del mòdul amb Find-Module -Name «RDWebClientManagement» | Save-Module -Path C:\WebClient\.

Un cop copiat tot el contingut d'aquesta carpeta al servidor de RD Web Access, es tenen dues opcions: importar directament el mòdul des de la ruta on s'ha copiat o moure la carpeta a una de les ubicacions incloses a $env:PSModulePath. Amb el mòdul disponible en local, s'instal·la el paquet usant Install-RDWebClientPackage -Source C:\WebClient\rdwebclient-xyzzip i es continua amb els passos de publicació habituals.

D'aquesta manera, fins i tot en entorns amb controls de xarxa molt estrictes, es pot disposar de un client web d'Escriptori Remot plenament funcional, sense necessitat que els servidors de producció arribin directament a la PowerShell Gallery.

Connexió del client web al Broker sense porta d'enllaç al Windows Server 2019

Al Windows Server 2019 hi ha l'opció de permetre que el client web es connecti a l'Agent d'Escriptori Remot sense necessitat d'una Porta d'enllaç RD, útil en entorns interns o de laboratori. Aquest escenari requereix ajustar certificats i paràmetres de WebSocket al servidor Broker i, si escau, al Host de Sessió.

Si el servidor de l'Agent de connexió encara no té un certificat enllaçat, des de l'Administrador del servidor s'entra a Serveis d'Escriptori Remot, s'obre la vista d'implementació, se'n va al menú Tasques i es tria Edita propietats de la implementació. A la pestanya de Certificats se selecciona l'entrada de Agent de connexió – Habilitar inici de sessió únic i es crea un nou certificat o se n'usa un de ja existent, de confiança pública o de la PKI corporativa.

Si ja hi ha un certificat enllaçat, es pot reutilitzar copiant la seva empremta digital des de la consola de certificats. Amb aquest thumbprint, s'obre PowerShell com a administrador i s'executa una ordre netsh http add sslcert ipport=0.0.0.0:3392 certhash=» » certstorename=»Remote Desktop» appid=»{GUID}», per associar el certificat al port segur 3392 que emprarà el canal WebSocket.

Tot seguit, s'entra al Registre de Windows (regedit) i es localitza la clau HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Dins d'aquesta clau hi ha un valor anomenat WebSocketURI que cal fixar a https://+:3392/rdp/, indicant així la ruta que utilitzarà el client web per parlar amb el Broker via WebSocket.

Si el servidor Host de Sessió d'Escriptori Remot és diferent de l'Agent de connexió, cal replicar un procés similar al host de sessió: crear o assignar un certificat, enllaçar-lo al port 3392 mitjançant netsh, i comprovar que el valor WebSocketURI al registre coincideix amb https://+:3392/rdp/. Tot això s'ha de fer a servidors Windows Server 2019 amb certificats públics vàlids, amb el SAN configurat al FQDN de la màquina i el CN ​​igual que el SAN.

Polítiques i ajustaments del client web: telemetria i forma de llançar recursos

Quan el client web funciona, és possible que vulguis limitar què poden tocar els usuaris dins del panell de configuració. Microsoft proporciona una sèrie de cmdlets per controlar el comportament de la interfície, especialment pel que fa a telemetria i forma d'iniciar els recursos remots.

Per defecte, l'usuari pot decidir si envia o no dades de telemetria a Microsoft des del panell Sobre. Si l'organització prefereix bloquejar l'enviament de dades per política, es pot executar una ordre com Set-RDWebClientDeploymentSetting -Name «SuppressTelemetry» $true. Amb aquest valor true, la telemetria queda deshabilitada i l'usuari no la pot tornar a activar.

Quant a la forma d'iniciar escriptoris i aplicacions, normalment el client web permet escollir entre obrir el recurs al propi navegador o bé descarregar un fitxer .rdp per utilitzar-lo amb un client RDP local. Això es pot fixar mitjançant lopció LaunchResourceInBrowser, usant Set-RDWebClientDeploymentSetting -Name LaunchResourceInBrowser $true o $false.

Si establiu LaunchResourceInBrowser a true, l'usuari haurà de llançar sempre els recursos al navegador, sense opció de descàrrega. Si es fixa a false, en canvi, els recursos s'iniciaran sempre descarregant el fitxer .rdp, pensats per a clients RDP instal·lats a la màquina local, una mica menys habitual quan el dispositiu s'usa com a thin client pur.

Si més endavant voleu tornar a la configuració per defecte, podeu utilitzar Reset-RDWebClientDeploymentSetting amb el paràmetre -Name per a cada ajustament, per exemple Reset-RDWebClientDeploymentSetting -Name LaunchResourceInBrowser o Reset-RDWebClientDeploymentSetting -Name «SuppressTelemetry». Així es torna el control al comportament original del client web.

Configuració de xarxa, arrencada directa i polítiques de sessió per a Windows com thin client

Perquè un PC amb Windows actuï de veritat com a terminal lleuger, és clau tenir cura tant de la xarxa com del procés d'inici de sessió a l'equip. La idea és que l'usuari només vegi Windows i entre gairebé immediatament a la sessió RDP o al client web.

A la part de xarxa, convé comptar amb una topologia estable, bona qualitat de switches i, si es pot, segmentació mitjançant VLANs per aïllar el trànsit d'Escriptori Remot. Els servidors DHCP han d'estar ben configurats perquè els clients obtinguin IP de forma automàtica i consistent, i els DNS han de resoldre correctament el FQDN del servidor RD Web i del Broker.

Al tallafocs, tant del perímetre com als propis servidors, cal obrir els ports necessaris per a RDP, RD Gateway i WebSocket (quan apliqui). Una configuració massa restrictiva pot fer que els usuaris vegin les icones a “Tots els recursos” però no puguin connectar-se, o que apareguin errors de certificat en establir la sessió.

Al costat del dispositiu amb Windows, es pot fer servir el Programador de tasques, scripts d'inici de sessió o directives de grup perquè en arrencar el sistema s'obri automàticament el client RDP o el navegador apuntant a la URL del client web. Combinant això amb polítiques locals o de domini, es poden restringir accessos a l'escriptori local, a l'Explorador de fitxers o al Tauler de control perquè l'usuari només faci servir la sessió remota.

Les polítiques de sessió RDS (directives de temps d'inactivitat, tancament de sessió després de X minuts, límits de reconnexió, etc.) es poden aplicar des de la consola de Serveis d'Escriptori Remot o mitjançant GPOs, de manera que el servidor controli quants recursos consumeix cada usuari i eviteu sessions penjades eternament que penalitzin el rendiment global.

Solució de problemes freqüents en entorns de thin client i Escriptori Remot

A la pràctica, gestionar un entorn de Windows com a thin client amb Remote Desktop implica bregar amb incidències recurrents: des de problemes de xarxa fins a certificats caducats, passant per errors al client web. Tenir un mètode ordenat de diagnòstic estalvia molt de temps i evita apagafocs constants.

Els problemes de connectivitat solen ser els més habituals: talls intermitents, sessions que es congelen o equips que no aconsegueixen arribar al servidor. Davant d'això, el primer és revisar cablejat, switches i routers, i fer servir eines com ping o tracert per comprovar si la ruta entre thin client i servidor és estable. També cal assegurar-se que la latència no és excessiva, sobretot si els usuaris es connecten des de seus remotes.

En alguns casos, és la configuració del tallafocs la que impedeix el bon funcionament: ports RDP, HTTPS, i els específics de Gateway i WebSocket han d'estar correctament oberts. Una regla mal plantejada pot deixar accedir a la pàgina de RD Web Access, però bloquejar el canal de dades que utilitza la sessió RDP real, generant errors aparentment inexplicables.

Altres errors tenen a veure amb compatibilitat de maquinari: encara que els thin clients són senzills, els perifèrics (impressores, escàners, lectors de targetes, etc.) poden requerir drivers específics o redireccions adequades a través de RDP. Quan un dispositiu no és reconegut, acostuma a ajudar revisar la documentació del fabricant i comprovar si el sistema operatiu del terminal lleuger està suportat.

Finalment, les fallades de programari tant al servidor com al mateix thin client poden provocar bloquejos d'aplicacions o tancaments inesperats de sessió. Mantenir Windows Server, Windows 10/11 i la resta de components al dia amb els pegats de seguretat i correccions d'errors és fonamental per evitar problemes ja coneguts que Microsoft hagi solucionat en versions posteriors.

Errors habituals del client web, certificats i registre de consola

El client web d'Escriptori Remot afegeix la vostra llista d'incidents típics. Un dels més freqüents és que el navegador mostri una advertència de seguretat en intentar accedir a la URL del web client. Això sol indicar que el rol de RD Web Access no utilitzeu un certificat de confiança pública o d'una CA reconeguda per l'equip de l'usuari.

Si el certificat és vàlid però continua apareixent l'avís, probablement l'URL que l'usuari està usant no coincideix amb el nom del certificat: per exemple, entrar amb IP o amb un àlies diferent de l'FQDN. En aquest cas, n'hi ha prou amb assegurar-se que la direcció utilitza el FQDN correcte que figura al certificat (generalment el nom complet del servidor).

Un altre error recurrent és que l'usuari vegi els seus escriptoris i aplicacions a “Tots els recursos”, però en fer clic no aconsegueixi establir la connexió. Aquí cal verificar, novament, la configuració del certificat de la Porta d'enllaç RD i les actualitzacions requerides (com KB4025334). A més, si es mostra un missatge sobre un certificat inesperat amb una empremta digital concreta, aquesta empremta ajuda a localitzar al magatzem de certificats quin certificat s'està usant realment per al rol d'agent d'escriptori remot.

Un cop localitzat el certificat correcte, es comprova que no hagi caducat, s'exporta en format .cer i es copia al servidor de l'RD Web Access per tornar a executar Import-RDWebClientBrokerCert amb la ruta adequada. Amb això, el client web torna a confiar en el Broker correcte i desapareixen els advertiments relacionats.

Si res d'això resol el problema, el client web mateix incorpora una funció de captura d'informació de suport. Des del menú (els tres punts), a la pàgina Quant a, es pot prémer a Iniciar enregistrament, reproduir el problema, i després prémer Aturar enregistrament. El navegador descarregarà un fitxer de text amb el log de consola, que inclou els missatges d'error de JavaScript i del client, molt útils per a una anàlisi més profunda.

A més d'aquesta eina integrada, sempre es pot obrir la consola de desenvolupador del navegador (per exemple, amb F12 a Microsoft Edge) i revisar directament els errors a la pestanya Consola. Aquesta informació complementa els logs del servidor (esdeveniments de Remote Desktop Services, IIS, etc.) i permet tenir una visió completa del que falla a la comunicació entre client web i backend.

Bones pràctiques, manteniment i eines de tercers

Perquè un entorn de Windows com thin client sigui estable a llarg termini, no n'hi ha prou de configurar-lo una vegada i oblidar-se. Cal establir una rutina de manteniment i monitorització que permeti detectar problemes abans que esclatin i mantenir la seguretat en nivells acceptables.

Una pràctica recomanable és fer revisions periòdiques de la plataforma: comprovar l'estat dels servidors, revisar el consum de CPU, RAM i disc, i analitzar els logs a la recerca de patrons d'error. Eines de monitorització de xarxa i de rendiment, tant natives com de tercers, ajuden a identificar colls d'ampolla ia planificar ampliacions de capacitat.

També és molt útil documentar bé cada canvi de configuració, actualització o nova versió de client web que es desplega. Portar un registre detallat fa molt més fàcil tornar enrere o entendre què va poder desencadenar un problema recurrent. Això inclou escriure procediments per a la instal·lació del client web, el maneig de certificats i la configuració de polítiques.

Pel que fa al suport, a més dels canals oficials de Microsoft (com el fòrum d'Azure Virtual Desktop a Microsoft Tech Community), hi ha solucions de tercers tipus TSplus que simplifiquen la publicació d'aplicacions i escriptoris via web, afegeixen capes de seguretat i faciliten l'administració d'entorns amb molts usuaris remots.

Combinant una bona base de Serveis d'Escriptori Remot amb una política clara de telemetria, certificats ben gestionats, un disseny de xarxa robust i eines de gestió o VDI complementàries, un PC amb Windows es converteix sense gaires complicacions a un thin client fiable, fàcil d'administrar i preparat per créixer amb les necessitats de lorganització.