Windows come thin client: configurazione dei criteri di sessione e Desktop remoto

  • Windows può essere riutilizzato come thin client connettendosi direttamente al Desktop remoto o al VDI, centralizzando i dati e l'elaborazione sul server.
  • Un'infrastruttura RDS ben progettata (Broker, Gateway, RD Web, certificati validi e CAL per utente) è fondamentale per la stabilità e la sicurezza.
  • Il client Web Desktop remoto consente l'accesso tramite browser, è gestito con PowerShell e supporta la messa a punto della telemetria e l'avvio delle risorse.
  • La combinazione di buone policy di sessione, una rete solida e un monitoraggio continuo garantisce un ambiente thin client efficiente e di facile manutenzione.

Windows come thin client

Convertire un PC Windows in un thin client completamente orientato a Desktop remoto È un modo altamente efficiente per prolungare la durata di vita delle apparecchiature più vecchie, ridurre i costi e centralizzare la gestione. Invece di lavorare localmente, l'utente accede direttamente a un server o a un'infrastruttura VDI e tutta l'elaborazione viene eseguita nel data center o nel cloud.

L'idea è che il dispositivo si avvii, carichi automaticamente la sessione RDP (o client web) e applichi policy di sessione e sicurezza ben definitein modo che per l'utente sia come accendere un tradizionale "terminale stupido". Vedremo, passo dopo passo e in modo molto dettagliato, come mettere insieme i pezzi: tecnologia thin client, Servizi Desktop remoto, client web, certificati, policy e risoluzione dei problemi.

Cos'è un thin client e perché ha senso utilizzare Windows come terminale sottile?

Un thin client è fondamentalmente un dispositivo molto semplice che Dipende quasi interamente da un server remoto per eseguire applicazioni, archiviare dati e, in generale, svolgere il lavoro più pesante. L'hardware dell'utente finale è responsabile solo della visualizzazione dell'interfaccia, della gestione di tastiera e mouse e di poco altro.

Quando utilizziamo un PC Windows come thin client, ciò che facciamo è ridurre al minimo l'uso locale delle risorse e configurare il sistema per connettersi automaticamente a una sessione RDP, a un desktop virtuale o ad applicazioni remote pubblicate.

Questo approccio ha chiari vantaggi: l'hardware dell'utente può essere modesto, i problemi vengono risolti sul server e i dati Non sono sparsi su ogni computer dell'ufficioma centralizzati e protetti nel data center o nel cloud.

Inoltre, il modello thin client si adatta perfettamente alle soluzioni moderne come Azure Virtual Desktop, RDS su Windows Server o VDI di terze parti (Citrix, VMware, TSplus, ecc.), che sono già progettati in modo che molte sessioni possano essere gestite da un unico ambiente centralizzato.

Principali vantaggi della tecnologia thin client

La tecnologia thin client si basa su un principio molto semplice: spostare l'elaborazione e i dati sul serverQuesto cambiamento di approccio comporta una serie di vantaggi che, da soli, giustificano lo sforzo di impostare un'infrastruttura di Desktop remoto ben progettata.

In termini di costi, i thin client sono solitamente dispositivi più semplici, con meno spazio su disco e meno potenza della CPU, quindi Consumano meno energia e hanno una durata maggioreAnche un vecchio PC Windows può essere convertito in un terminale leggero e continuare a essere utile per qualche anno.

Dal punto di vista della sicurezza, quando si lavora contro server centrali, Le applicazioni critiche e i dati sensibili rimangono nel back-endSi riduce il rischio di furto di informazioni sulla postazione di lavoro ed è più facile implementare crittografia, backup e controlli di accesso da un unico punto.

Nell'amministrazione IT, il guadagno è enorme: gli aggiornamenti, le patch e le modifiche alla configurazione vengono eseguiti sul server o sulle immagini VDI, consentendo un gestione centralizzata invece di procedere per teamAggiungere nuovi utenti o reparti diventa questione di minuti.

Infine, è un ambiente altamente scalabile: se la domanda cresce, le risorse del server vengono ampliate o nuove macchine vengono aggiunte al pool di sessioni e Gli utenti possono connettersi da terminali più sottili senza grandi investimenti in posti di lavoro.

Scelta dell'hardware, del sistema operativo e del software di virtualizzazione

Per utilizzare Windows come thin client con Desktop remoto, è necessario considerare sempre il server come il cuore del sistema. La macchina dell'utente è importante, ma Ciò che determina realmente le prestazioni è la capacità del server. e la rete che li unisce.

Per il server, è consigliabile optare per un processore multi-core con una buona velocità di clock, poiché sarà gestire più sessioni utente in paralleloPer ambienti di piccole dimensioni, è possibile iniziare con pochi core, ma in scenari con decine di utenti simultanei, l'hardware di classe server è quasi obbligatorio.

La RAM è un altro punto critico: ogni sessione RDP o VDI consuma la sua quota, quindi 16 GB sono un minimo ragionevole per piccoli ambienti, mentre Nelle installazioni di medie e grandi dimensioni è comune superare i 32 o 64 GBL'archiviazione è ottimale su SSD, in modo che le scritture e le letture siano veloci e le sessioni non risultino lente.

Per quanto riguarda i dispositivi thin client, è possibile scegliere tra terminali dedicati del produttore o PC riadattati con una versione leggera di Windows. La cosa importante è che Devono disporre di una buona connettività di rete e di supporto client RDP. (o per il browser moderno se si opta per il client web) e, se necessario, compatibilità con periferiche specifiche (lettori di schede, stampanti, ecc.).

Per quanto riguarda il sistema operativo server, Windows Server (2016, 2019 o versioni successive) con Servizi Desktop remoto è la scelta più comune. È anche possibile combinarlo con ambienti Linux per altre attività, ma Per RDP e Servizi Desktop remoto, l'integrazione naturale è con Windows Server.Molte organizzazioni integrano come software VDI aggiuntivo Citrix Virtual Apps and Desktops, VMware Horizon o soluzioni come TSplus per semplificare la pubblicazione delle applicazioni e gli scenari di accesso al Web.

Preparazione dell'infrastruttura Desktop remoto per utilizzare Windows come thin client

Prima che l'utente accenda il computer e acceda direttamente al desktop remoto, l'infrastruttura RDS deve essere configurata correttamente. Ciò comporta Distribuisci e configura i ruoli classici di Desktop remoto e assicurarsi che tutto sia adeguatamente certificato e autorizzato.

Un'implementazione tipica includerà, almeno, un server con il ruolo di Gestore di connessione desktop remoto, un altro con il ruolo di Accesso Web RD e Gateway Desktop remoto (RD Gateway) Se desideriamo accedere dall'esterno della rete interna, in molti ambienti uno o più server fungono anche da host di sessione Desktop remoto.

È importante che l'infrastruttura sia configurata per utilizzare licenze CAL RDS utente e non licenze CAL dispositivo, perché altrimenti Potremmo consumare rapidamente tutte le licenze riutilizzando attrezzature leggere.Questa scelta viene effettuata nelle impostazioni di licenza dei Servizi Desktop remoto.

Per quanto riguarda gli aggiornamenti, Microsoft richiede che il server Gateway disponga di determinati file KB installati affinché il client Web Desktop remoto funzioni correttamente. Uno dei più frequentemente citati è KB4025334 in Windows 10 e successivi aggiornamenti cumulativiche di solito è incluso negli aggiornamenti più recenti. È una buona idea verificare che il sistema sia aggiornato.

La questione dei certificati digitali non è di poco conto: per garantire un accesso sicuro ed evitare di sommergere gli utenti di notifiche, è consigliabile configurare Certificati di attendibilità pubblica sia per RD Gateway che per RD Web AccessIl nome di dominio completo (FQDN) utilizzato nell'URL deve corrispondere al certificato e il browser deve considerare attendibile tale CA.

Configurazione e pubblicazione del client Web Desktop remoto

Il client web Remote Desktop consente l'accesso ai desktop e alle applicazioni pubblicate da un browser moderno (Edge, Chrome, ecc.) senza installare il client RDP tradizionale. Questa è la soluzione ideale quando si desidera un client leggero. Basta aprire un browser e caricare l'URL del client web.lasciando il resto del lavoro al server.

Per configurarlo, devi prima assicurarti che l'implementazione di RDS disponga di RD Gateway, RD Connection Broker e RD Web Access in esecuzione su Windows Server 2016 o 2019. Da lì, puoi lavorare sul server che ospita il ruolo RD Web Access. utilizzando moduli PowerShell specifici.

Il processo di installazione standard del client Web prevede l'apertura di una console PowerShell con privilegi elevati sul server Accesso Web Desktop remoto e, nel caso di Windows Server 2016, aggiornare il modulo PowerShellGet con un comando come Install-Module -Name PowerShellGet -Force per poter installare il resto dei moduli dalla galleria.

Quindi il modulo RDWebClientManagement viene installato con un comando come Install-Module -Name RDWebClientManagementSuccessivamente, la versione più recente del pacchetto Web viene scaricata tramite Install-RDWebClientPackage, che è responsabile del trasferimento del contenuto client dalla PowerShell Gallery.

Dopo aver scaricato il pacchetto, è necessario importare il certificato RDS Broker nel server RD Web Access utilizzando un comando come Importa-RDWebClientBrokerCertCiò consente al client web di fidarsi dell'agente di connessione. Infine, il pacchetto viene pubblicato utilizzando `Publish-RDWebClientPackage -Type Production -Latest`, rendendo il client accessibile a un URL nel formato https://FQDN_server/RDWeb/webclient/index.html.

Quando viene rilasciata una nuova versione del client Web, è sufficiente ripetere il download con Install-RDWebClientPackage e aggiornare la pubblicazione eseguendo Pubblica-RDWebClientPackage -Tipo Produzione -UltimoPuoi prima utilizzare la modalità Test se vuoi convalidare la nuova versione su un URL alternativo senza influire su tutti gli utenti.

Installazione, disinstallazione e scenari senza accesso a Internet

A volte potrebbe essere necessario rimuovere completamente il client Web Desktop remoto, ad esempio se è stata installata una versione precedente o di prova che non è più necessaria. Per farlo, accedere al server Accesso Web Desktop remoto. I pacchetti non sono più pubblicati e tutta la configurazione è stata rimossa. con Uninstall-RDWebClient.

Il passo successivo è disinstallare il modulo di amministrazione con un comando come Disinstalla-Modulo -Nome RDWebClientManagementSe in precedenza è stata utilizzata una versione precedente del modulo e il sistema segnala incompatibilità, potrebbe essere necessario reinstallare quella versione specifica per eseguire Uninstall-RDWebClient e ripulire l'ambiente prima di passare a una nuova versione.

Nelle reti isolate, senza accesso a Internet dal server RD Web Access, l'installazione del client Web può essere preparata da un altro computer che ha accesso alla rete esterna. Su tale computer, il modulo RDWebClientManagement viene importato e il pacchetto del client Web viene salvato in una cartella locale utilizzando Salva-RDWebClientPackage «C:\WebClient\» e i file del modulo vengono scaricati anche con Find-Module -Name "RDWebClientManagement" | Save-Module -Path "C:\WebClient\".

Una volta che tutto il contenuto di quella cartella è stato copiato sul server RD Web Access, hai due opzioni: importare il modulo direttamente dal percorso in cui è stato copiato o spostare la cartella in una delle posizioni incluse in $env:PSModulePathCon il modulo disponibile localmente, il pacchetto viene installato tramite Install-RDWebClientPackage -Source "C:\WebClient\rdwebclient-xyzzip" e si prosegue con i consueti passaggi di pubblicazione.

In questo modo, anche in ambienti con controlli di rete molto rigidi, è possibile avere un client Web Desktop remoto completamente funzionale, senza che i server di produzione debbano accedere direttamente alla PowerShell Gallery.

Connessione di un client Web a un broker senza gateway su Windows Server 2019

Windows Server 2019 offre la possibilità di consentire al client Web di connettersi all'agente Desktop remoto senza richiedere un gateway Desktop remoto, il che è utile in ambienti interni o di laboratorio. Questo scenario richiede Regola i certificati e i parametri WebSocket sul server Broker e, se applicabile, sull'host di sessione.

Se il server Connection Broker non dispone ancora di un certificato associato, da Server Manager, accedere a Servizi Desktop remoto, aprire la Visualizzazione distribuzione, accedere al menu Attività e scegliere Modifica proprietà distribuzione. Nella scheda Certificati, selezionare la voce per Agente di connessione: abilita l'accesso singolo e viene creato un nuovo certificato o ne viene utilizzato uno esistente, proveniente da un ente pubblico o dalla PKI aziendale.

Se esiste già un certificato associato, è possibile riutilizzarlo copiandone l'identificazione personale dalla Console dei certificati. Con tale identificazione personale, aprire PowerShell come amministratore ed eseguire il comando `netsh http add sslcert ipport=0.0.0.0:3392 certhash="` » certstorename=»Desktop remoto» appid=»{GUID}», per associare il certificato alla porta sicura 3392 che utilizzerà il canale WebSocket.

Successivamente, apri il Registro di sistema di Windows (regedit) e individua la chiave HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. All'interno di quella chiave, c'è un valore chiamato WebSocketURI che deve essere impostato su https://+:3392/rdp/indicando così il percorso che il client web utilizzerà per comunicare con il Broker tramite WebSocket.

Se il server host della sessione Desktop remoto è diverso dal Connection Broker, è necessario replicare un processo simile sull'host della sessione: creare o assegnare un certificato, associarlo alla porta 3392 tramite netsh e verificare che il valore WebSocketURI nel registro corrisponda a https://+:3392/rdp/. Tutto ciò deve essere fatto sui server Windows Server 2019 con certificati pubblici validi, con la SAN configurata sul FQDN della macchina e il CN uguale alla SAN.

Criteri e impostazioni del client Web: telemetria e come avviare le risorse

Una volta che il client web è attivo e funzionante, potrebbe essere necessario limitare l'accesso degli utenti al pannello delle impostazioni. Microsoft fornisce una serie di cmdlet per controllare il comportamento dell'interfaccia, in particolare per quanto riguarda... telemetria e come avviare risorse remote.

Per impostazione predefinita, gli utenti possono decidere se inviare o meno i dati di telemetria a Microsoft dal pannello Informazioni. Se l'organizzazione preferisce bloccare la trasmissione dei dati tramite policy, è possibile utilizzare un comando come Set-RDWebClientDeploymentSetting -Name "SuppressTelemetry" $trueImpostando questo valore su true, la telemetria è disabilitata e l'utente non può riattivarla.

Per quanto riguarda l'avvio di desktop e applicazioni, il client web in genere consente di scegliere tra l'apertura della risorsa nel browser stesso o il download di un file .rdp da utilizzare con un client RDP locale. Questa opzione può essere configurata utilizzando l'opzione Avvia RisorsaNelBrowser, utilizzando Set-RDWebClientDeploymentSetting -Name “LaunchResourceInBrowser” $true o $false.

Se LaunchResourceInBrowser è impostato su true, l'utente dovrà avviare sempre le risorse nel browser, senza un'opzione di download. Se impostato su false, tuttavia, le risorse inizieranno sempre scaricando il file .rdp, destinato ai client RDP installati sulla macchina locale, il che è meno comune quando il dispositivo viene utilizzato come thin client puro.

Se in seguito si desidera ripristinare le impostazioni predefinite, è possibile utilizzare Reset-RDWebClientDeploymentSetting con il parametro -Name per ciascuna impostazione, ad esempio Reset-RDWebClientDeploymentSetting -Nome "LaunchResourceInBrowser" oppure Reset-RDWebClientDeploymentSetting -Name "SuppressTelemetry". In questo modo viene ripristinato il controllo sul comportamento originale del client Web.

Configurazione di rete, avvio diretto e criteri di sessione per Windows come thin client

Affinché un PC Windows funzioni davvero come un terminale sottile, è fondamentale ottimizzare sia la rete che il processo di accesso stesso. L'obiettivo è che l'utente non veda quasi per niente Windows. accedi quasi immediatamente alla tua sessione RDP o al client web.

Sul lato rete, si consiglia una topologia stabile, switch di buona qualità e, se possibile, la segmentazione VLAN per isolare il traffico Desktop remoto. I server DHCP devono essere configurati correttamente per i thin client. ottenere indirizzi IP in modo automatico e coerentee il DNS deve risolvere correttamente l'FQDN del server Web RD e del Broker.

Il firewall, sia sul perimetro che sui server stessi, deve aprire le porte necessarie per RDP, RD Gateway e WebSocket (ove applicabile). Una configurazione eccessivamente restrittiva può causare... Gli utenti vedono le icone in "Tutte le risorse" ma non possono connettersio che si verifichino errori di certificato quando si stabilisce la sessione.

Sul lato dispositivo Windows, è possibile utilizzare l'Utilità di pianificazione, gli script di accesso o i Criteri di gruppo per aprire automaticamente il client RDP o il browser che punta all'URL del client web all'avvio del sistema. Combinando questo con i criteri locali o di dominio, È possibile limitare l'accesso al desktop locale, a Esplora file o al Pannello di controllo. in modo che l'utente utilizzi solo la sessione remota.

I criteri di sessione RDS (criteri di tempo di inattività, disconnessione dopo X minuti, limiti di riconnessione, ecc.) possono essere applicati dalla console Servizi Desktop remoto o tramite GPO, in modo che il server controlli quante risorse consuma ciascun utente e Evita sessioni che si bloccano indefinitamente che penalizzano le prestazioni complessive.

Risoluzione dei problemi comuni negli ambienti thin client e desktop remoto

Nella pratica, gestire un ambiente Windows come thin client con Desktop Remoto implica la gestione di problematiche ricorrenti: dai problemi di rete ai certificati scaduti, fino agli errori del client web. Avere un metodo di diagnostica strutturato è essenziale. Si risparmia molto tempo ed si evita di dover continuamente intervenire per spegnere gli incendi..

I problemi di connettività sono solitamente i più comuni: interruzioni intermittenti, sessioni bloccate o dispositivi che non riescono a connettersi al server. Il primo passo è controllare cavi, switch e router e utilizzare strumenti come ping o tracert per risolvere il problema. se il percorso tra thin client e server è stabileÈ inoltre consigliabile assicurarsi che la latenza non sia eccessiva, soprattutto se gli utenti si connettono da postazioni remote.

In alcuni casi, è la configurazione del firewall a impedirne il corretto funzionamento: le porte RDP, HTTPS, Gateway e WebSocket devono essere correttamente aperte. Una regola configurata in modo errato potrebbe consentire l'accesso alla pagina di Accesso Web Desktop remoto, ma bloccare il canale dati utilizzato dalla sessione RDP effettivagenerando errori apparentemente inspiegabili.

Altri problemi sono legati alla compatibilità hardware: sebbene i thin client siano semplici, le periferiche (stampanti, scanner, lettori di schede, ecc.) potrebbero richiedere driver specifici o un corretto reindirizzamento RDP. Quando un dispositivo non viene riconosciuto, spesso è utile consultare la documentazione del produttore e verificare se il sistema operativo del terminale sottile è supportato.

Infine, guasti software sia sul server che sul thin client stesso possono causare crash delle applicazioni o chiusure impreviste delle sessioni. La manutenzione di Windows Server, Windows 10/11 e degli altri componenti è essenziale. aggiornato con patch di sicurezza e correzioni di bug Ciò è essenziale per evitare problemi noti che Microsoft ha già risolto nelle versioni successive.

Errori comuni nel client Web, nei certificati e nella registrazione della console

Il client web di Desktop remoto presenta un elenco di problemi tipici. Uno dei più frequenti è la visualizzazione di un avviso di sicurezza da parte del browser quando si tenta di accedere all'URL del client web. Questo di solito indica che il ruolo Accesso Web Desktop remoto non è supportato. Non utilizza un certificato pubblicamente attendibile o un certificato di una CA riconosciuta dal team dell'utente.

Se il certificato è valido ma l'avviso continua a comparire, l'URL utilizzato dall'utente probabilmente non corrisponde al nome del certificato: ad esempio, l'accesso avviene con un indirizzo IP o un alias diverso dall'FQDN. In tal caso, è sufficiente... Assicurati che l'indirizzo utilizzi il nome di dominio completo corretto che appare nel certificato (solitamente il nome completo del server).

Un altro errore ricorrente è che l'utente visualizza i propri desktop e applicazioni in "Tutte le risorse", ma cliccandoci sopra non riesce a stabilire una connessione. In questo caso, è necessario verificare nuovamente le impostazioni del certificato di RD Gateway e gli eventuali aggiornamenti necessari (come KB4025334). Inoltre, se viene visualizzato un messaggio relativo a un certificato inaspettato con un'impronta digitale specifica, Questa impronta digitale aiuta a individuare nell'archivio certificati quale certificato è effettivamente utilizzato per il ruolo di agente Desktop remoto.

Una volta individuato il certificato corretto, questo viene controllato per verificare che non sia scaduto, esportato in formato .cer e copiato sul server RD Web Access per eseguire nuovamente Import-RDWebClientBrokerCert con il percorso appropriato. In questo modo, Il cliente web si fida di nuovo del broker giusto. e gli avvisi correlati scompaiono.

Se nessuna di queste soluzioni risolve il problema, il client web include una funzione di acquisizione delle informazioni di supporto. Dal menu (i tre puntini), nella pagina Informazioni, è possibile fare clic su Avvia registrazione, riprodurre il problema e quindi fare clic su Interrompi registrazione. Il browser scaricherà un file di testo contenente il registro della console, che Ciò include sia i messaggi di errore JavaScript che quelli lato client., molto utile per un'analisi più approfondita.

Oltre a questo strumento integrato, è sempre possibile aprire la console per sviluppatori del browser (ad esempio, con F12 in Microsoft Edge) e rivedere direttamente gli errori nella scheda Console. Queste informazioni integrano i log del server (eventi da Servizi Desktop remoto, IIS, ecc.) e Ti permette di avere una visione completa di ciò che sta fallendo nella comunicazione tra client web e backend.

Buone pratiche, manutenzione e strumenti di terze parti

Affinché un ambiente thin client Windows sia stabile a lungo termine, non è sufficiente configurarlo una volta e dimenticarsene. È necessario stabilire una routine di manutenzione e monitoraggio. ti permettono di rilevare i problemi prima che esplodano e mantenere la sicurezza a livelli accettabili.

Si consiglia di eseguire revisioni periodiche della piattaforma: verifica dello stato del server, verifica dell'utilizzo di CPU, RAM e disco e analisi dei log per individuare eventuali errori. Strumenti di monitoraggio di rete e prestazioni, sia nativi che di terze parti, Aiutano a identificare i colli di bottiglia stanno già pianificando espansioni di capacità.

È inoltre molto utile documentare dettagliatamente ogni modifica alla configurazione, aggiornamento o nuova versione del client web implementata. Tenere un registro dettagliato semplifica notevolmente il rollback o il ripristino delle versioni precedenti. per capire cosa potrebbe aver innescato un problema ricorrenteCiò include la scrittura di procedure per l'installazione del client Web, la gestione dei certificati e la configurazione delle policy.

Per quanto riguarda il supporto, oltre ai canali ufficiali Microsoft (come il forum Azure Virtual Desktop nella Microsoft Tech Community), esistono soluzioni di terze parti come TSplus che Semplificano la pubblicazione di applicazioni e desktop tramite il webAggiungono livelli di sicurezza e facilitano la gestione di ambienti con molti utenti remoti.

Combinando una buona base di Servizi Desktop remoto con una chiara politica di telemetria, certificati ben gestiti, una progettazione di rete robusta e strumenti di gestione o VDI complementari, un PC Windows può essere trasformato senza troppi problemi in un thin client affidabile e facile da gestire, pronto a crescere con le esigenze dell'organizzazione.