Un Terminal Server è fondamentalmente lo stesso del normale sistema operativo Windows Server, tranne che negli ambienti Terminal Server, i componenti chiave sono stati aggiunti o modificati per fornire supporto a più utenti simultanei.
Microsoft Windows è sempre stato un sistema operativo “multiutente”, nel senso che più utenti potrebbero essere collegati a un singolo server in un dato momento. Tuttavia, questi utenti erano connessi ai servizi di file o ai servizi di stampa sui server. Eseguivano le loro interfacce Windows locali sui loro computer locali e il server supportava solo un’interfaccia desktop tramite tastiera, mouse e monitor locali. La differenza principale con Terminal Server è che più utenti possono eseguire le proprie sessioni desktop di Windows sul server. Quindi Terminal Server è “multiutente” nel senso che supporta più interfacce desktop. Ad alcune persone piace pensare a questo come un ambiente di “controllo remoto”, tranne che il Terminal Server può ospitare molti utenti “controllo remoto” allo stesso tempo, con ogni utente che fa qualcosa di completamente diverso.
Affinché Terminal Server supportasse più sessioni utente, è stato necessario apportare alcune modifiche dal normale software Microsoft Windows Server. Ci sono due differenze fondamentali tra un normale server Windows e uno con Terminal Server installato:
- Quando Terminal Server è installato su un server Windows 2003, alcuni componenti principali del sistema operativo Windows vengono modificati per supportare più interfacce utente simultanee. Ad esempio, il gestore memoria virtuale e il gestore oggetti vengono modificati per supportare più interfacce desktop simultanee senza confondersi. Queste sono modifiche importanti, che richiedono di riavviare il sistema dopo l’installazione di Terminal Server.
- Quando è installato Terminal Server vengono aggiunti nuovi servizi e componenti che consentono al server di supportare più sessioni utente. Il più importante di questi è il servizio “Terminal Server”. Questo servizio, eseguito in profondità all’interno del server, è responsabile dell’interfacciamento delle sessioni utente multiple con il sistema operativo. È anche responsabile di funzioni come la creazione di sessioni, la ricezione di utenti e la fine delle sessioni.
Terminal Server Components
Anche se sembra che il Terminal Server sia fondamentalmente un sistema pcAnywhere glorificato, in realtà è un sistema complesso costituito da diversi componenti, sottosistemi e interfacce. Un diagramma più completo dei componenti Terminal Server è mostrato in Figura 2.1. Fare riferimento ad esso come si legge attraverso le prossime sezioni che descrivono ogni componente che compone Windows 2003 Terminal Server.
Figura 2.1: Terminal Server 2003 components
Il Kernel di Windows Server 2003
Si ricorderà che un componente chiave di qualsiasi ambiente di calcolo basato su server è un sistema operativo multiutente. In Windows Server 2003, questo sistema è controllato dal kernel.
Windows Server 2003 ha bisogno di un modo per distanziare i componenti critici del sistema operativo da tutti gli utenti pazzi. Per ottenere ciò, i processi Windows operano in una delle due modalità: modalità utente o modalità kernel. Ripensando alla tua formazione di Windows NT, ti ricorderai che un’applicazione in modalità utente non può scrivere direttamente nella memoria del sistema operativo. Invece, ha pieno accesso al proprio spazio di memoria 4GB. Un componente del sistema operativo chiamato Virtual memory manager (che a sua volta viene eseguito in modalità kernel) controlla tutto questo e scrive nella memoria di sistema per conto dell’applicazione in modalità utente.
Negli ambienti Terminal Server, la separazione delle applicazioni in modalità utente e modalità kernel consente al sistema di separare e isolare gli utenti. L’arresto anomalo dell’applicazione di un utente non abbatterà l’intero sistema. (Ovviamente stai pensando che un crash dell’applicazione possa abbattere un sistema, tuttavia, di solito è legato ai driver di periferica che vengono eseguiti in modalità kernel.)
Negli ambienti Windows “standard” (cioè server non terminale) in cui solo un singolo utente accede in modo interattivo, tutti i processi in modalità kernel vivono felicemente insieme in un’area di memoria e nello spazio dei nomi. In ambienti multiutente come Terminal Server, tuttavia, questa condivisione non funzionerà poiché le richieste provenienti da sessioni di utenti diversi potrebbero entrare in conflitto tra loro. Il kernel su un Terminal Server è di conseguenza multi-sessione consapevole; mantiene separata la sessione di ogni utente con processi e memoria isolati. Windows Server 2003 apporta alcune modifiche al kernel quando viene installato il componente Terminal Server.
In primo luogo, il server inserisce parte dello spazio degli indirizzi di memoria del kernel nella memoria virtuale. Ciò consente che le richieste in conflitto in un ambiente a singolo utente vengano elaborate correttamente nell’ambiente multiutente e che più istanze di driver di periferica in modalità kernel vengano caricate e utilizzate da più utenti (il motivo per cui un utente può tecnicamente mandare in crash l’intero sistema).
Alcuni processi di sistema non sono specifici della sessione, il che significa che tutti gli utenti in tutte le sessioni avranno bisogno di accedervi. Questi processi sono memorizzati in una singola area di memoria (globale) condivisa da tutti gli utenti.
Un effetto collaterale della condivisione di processi come questo in un ambiente Terminal Server è che a volte ti imbatterai in processi che non sono “consapevoli della sessione.”Un potenziale (e un po’ divertente) risultato può essere messaggi di errore che vengono visualizzati sulla console del server da applicazioni in esecuzione all’interno della sessione di un utente. Poiché di solito non c’è nessuno nella stanza del server per riconoscere il messaggio, c’è il potenziale per impedire all’applicazione di un utente di continuare.
Il Servizio Terminal Services
“Il servizio Terminal Services” si riferisce a un normale servizio Windows (Start | Strumenti di amministrazione | Servizi) chiamato “Terminal Services.”Nel mondo reale, le persone di solito si riferiscono ad esso come” Servizio terminale “e usano il termine” Terminal Server ” quando si fa riferimento a un server Windows che esegue il servizio terminale.
Se il kernel multiutente è il fondamento del calcolo basato su server in Windows Server 2003, il Servizio Terminal è la pietra angolare. Questo servizio (caricato tramite termserv.dll) viene caricato subito dopo che il kernel è online. Dopo aver caricato la console del server (driver per tastiera, video e mouse), il Servizio Terminale avvia il sottosistema Gestione sessioni (SMS).exe) responsabile della gestione e del monitoraggio di tutte le sessioni utente sul server.
Sessioni Terminal Server
Ogni volta che un utente accede a Terminal Server viene creata una nuova sessione. Una sessione consiste essenzialmente in un desktop virtuale da cui l’utente può eseguire applicazioni e con cui può interagire proprio come con una workstation. Una sessione del server non deve essere confusa con la console del server, poiché una sessione non è un controllo remoto della console, ma in realtà un nuovo desktop separato dalla console.
Ogni volta che un utente si connette a un Terminal Server e crea questo “desktop virtuale”, viene creato un numero ID sessione univoco per differenziare l’utente (e quindi i processi dell’utente) da tutte le altre sessioni e utenti. Gli ID sessione consentono inoltre al server di mantenere la memoria separata per la sessione di ogni utente. Quando un utente si disconnette da un client Terminal Services, la sessione utilizzata viene eliminata e i processi e la memoria avviati e utilizzati da tale sessione vengono rimossi. Ogni Terminal Server tiene traccia dei propri ID di sessione e gestisce l’attività di emissione, tracciamento e rimozione.
Poiché le sessioni del server sono “virtuali” (e la memoria e i processi sono tenuti separati tra le sessioni), un arresto anomalo o un blocco dell’applicazione in una sessione non dovrebbe influire su altre sessioni utente, anche se altri utenti utilizzano la stessa applicazione.
Tuttavia, la frase chiave qui è “non dovrebbe” influenzare altri utenti. Anche se le sessioni utente sono separate su un server, condividono comunque le risorse del server e alcuni segmenti di codice. Se un utente invoca un processo che causa la schermata blu del server, ciò avrà ovviamente un effetto sugli altri utenti. D’altra parte, semplici occorrenze come un’applicazione appesa a una richiesta di timeout o l’arresto anomalo di Microsoft Word quando un utente apre un documento corrotto non saranno viste dagli altri utenti (all’interno delle proprie sessioni) sul sistema.
Stati di sessione
Poiché una sessione è in realtà il desktop di un utente, ci sono volte in cui una sessione può trovarsi in vari stati diversi, proprio come una normale workstation. Ad esempio, se un utente si allontana dalla propria workstation per un periodo di tempo, la workstation non si spegne. Piuttosto, è semplicemente inattivo, in attesa dell’input dell’utente. Le sessioni di Terminal server si comportano allo stesso modo e possono trovarsi in uno di diversi stati a seconda dell’attività (o inattività) dell’utente, della connettività tra client e server e delle impostazioni di timeout della sessione.
Figura 2.2: Ogni Terminal Server mantiene molte sessioni utente separate
Tutte le sessioni utente su un Terminal Server devono trovarsi in uno dei seguenti sei stati:
- Active è un utente attivo e attivo. L’utente sta interagendo con la sessione Terminal Server e non ha avuto un periodo di inattività o una disconnessione di rete dal server. Questo è lo stato “normale” di una sessione.
- Idle è lo stato in cui una sessione entra quando non vi è alcun input da parte dell’utente per un periodo di tempo specificato.
- Le sessioni disconnesse si verificano quando i processi e i programmi di una sessione “live” sono in esecuzione ma nessun client RDC è connesso. (Se hai saltato il primo capitolo, “Client RDC” è il nuovo nome per il client RDP.) La causa comune è una disconnessione di rete o quando un utente fa clic sulla “X” nell’angolo in alto a destra del proprio software client RDC. Un utente può riconnettersi alla sua sessione disconnessa per riportarla a uno stato” attivo ” (e riprendere con il suo lavoro da dove si era interrotto). Pensa a una sessione disconnessa come una workstation bloccata, tranne che l’utente può “sbloccare” la sua workstation da qualsiasi computer nell’edificio.
- Le sessioni connnected sono in uno stato in cui un dispositivo client è connesso a una sessione server, ma nessun utente è connesso, proprio come il prompt CTRL+ALT+CANC su una workstation.
- Down è uno stato temporaneo in cui una sessione viene terminata e i processi all’interno della sessione vengono uccisi. Down è lo stato finale di una sessione prima che finisca.
- Listen è uno stato visualizzato solo sulle porte listener pronte ad accettare connessioni in entrata. Questo stato non si applica alle sessioni regolari. Piuttosto, si applica ai processi in esecuzione sul server che attendono (ascoltano) nuove richieste di connessione alla sessione.
Nella maggior parte degli ambienti, gli amministratori configurano sessioni con vari timeout. È possibile limitare il tempo di apertura di una singola sessione oppure convertire automaticamente una sessione inattiva in una sessione disconnessa. I timeout aiutano a limitare la quantità di tempo che il server impiega per eseguire i processi per gli utenti che in realtà non funzionano sul server. Tratteremo le tecniche e le strategie esatte per la configurazione di questi più avanti in questo libro.
Porte di connessione e Listener
Ogni sessione RDP dell’utente si connette al Terminal Server tramite una porta di connessione. Una porta di connessione (comunemente indicata solo come “connessione”) è una porta virtuale sul server associata a una specifica combinazione di scheda di rete e protocollo.
Una porta di connessione Terminal Server viene creata automaticamente quando il componente Terminal Server è installato. Per impostazione predefinita, consente a qualsiasi utente del gruppo “utenti desktop remoti” di connettersi alle sessioni di Terminal Server sul server tramite qualsiasi scheda di rete. Tuttavia, anche se la porta di connessione predefinita funziona con qualsiasi scheda di rete con TCP / IP installato, le porte di connessione Terminal Server sono realmente specifiche della scheda di rete. È possibile configurare un server con più schede di rete per avere più porte di connessione Terminal Server, una per ogni scheda. In effetti, ogni connessione può avere proprietà e autorizzazioni completamente diverse.
Figura 2.3: Un Terminal Server con più porte di connessione
Connessioni Terminal Server e relativi listener associati può essere configurato in due posizioni. Il primo è tramite il Terminal Services Configuration (TSC) MMC snap-in. È possibile utilizzare TSC per configurare le opzioni per le connessioni Terminal Server basate su RDP, ad esempio impostazioni, autorizzazioni e su quale scheda di rete è valida una connessione. Il secondo modo per configurare le connessioni Terminal Server è tramite un oggetto Criteri di gruppo Active Directory (GPO) all’interno di un dominio Windows 2003. Questa funzionalità consente di assegnare connessioni per più server contenuti con una OU in Active Directory.
Listener
Ogni porta di connessione Terminal Server ha un sottocomponente chiamato “listener.”Il componente listener “ascolta” su una specifica combinazione di scheda di rete e protocollo per la quale è configurata la porta di connessione. Quando un utente desidera stabilire una nuova sessione sul server, utilizza il software client RDC per contattare il server. Il listener del server preleva la richiesta del client e la inoltra al gestore della sessione. L’ascoltatore torna quindi all’ascolto per ulteriori richieste di connessione.
Canali virtuali
Come abbiamo discusso in precedenza, il protocollo RDP di Microsoft in esecuzione su TCP/IP è il protocollo effettivo che collega gli utenti alle sessioni del server. Abbiamo anche detto che questo protocollo può supportare più di semplici desktop virtuali puri. RDP consente di canalizzare l’audio della sessione remota dal server agli altoparlanti del dispositivo client. Consente inoltre ai dispositivi collegati alle porte seriali del client di apparire come se fossero collegati al server. Questi “extra” sono disponibili tramite i canali virtuali di RDP. Un canale virtuale è semplicemente un meccanismo per spostare i dati avanti e indietro tra una sessione Terminal Server e un client. Per impostazione predefinita, il protocollo RDP su Terminal Server 2003 contiene diversi canali virtuali.
- Audio: Gli eventi sonori generati sulla sessione del server vengono reindirizzati attraverso il protocollo RDP al dispositivo client RDC, dove vengono riprodotti sugli altoparlanti del client.
- Unità client: le unità disco locali sul dispositivo client vengono rese disponibili al server, in modo che gli utenti possano accedere sia alle unità server che alle unità del dispositivo client locale all’interno delle sessioni remote.
- Stampanti: le stampanti disponibili per il dispositivo client prima dell’avvio di una sessione su un Terminal Server vengono rese disponibili agli utenti all’interno delle sessioni del server. Gli utenti possono quindi stampare sulle stampanti Windows standard, incluse le stampanti direttamente collegate ai dispositivi client.
- Porte seriali: Il canale virtuale della porta seriale consente ai dispositivi collegati alla porta seriale di un dispositivo client di accedere tramite le sessioni remote Terminal Server.
- Appunti di Windows: Per integrare le applicazioni locali con le sessioni remote Terminal Server, il canale virtuale degli appunti di Windows sincronizza il contenuto degli appunti di Remote Terminal Server con il contenuto degli appunti del dispositivo client. Gli utenti possono facilmente tagliare e incollare tra applicazioni locali e remote.
Se i canali virtuali predefiniti non soddisfano le tue esigenze, MSDN e gli SDK di Windows Server 2003 contengono informazioni sulla scrittura dei tuoi canali virtuali personalizzati. Un canale virtuale è una combinazione di due componenti: un componente lato client e un componente lato server. Entrambi possono inviare e ricevere dati tramite il canale virtuale, consentendo una o due vie di comunicazione. I canali virtuali possono anche essere indipendenti RDP, il che significa che è possibile personalizzare il proprio ambiente senza aggiornare o modificare il software client o server effettivo.
Perché tutta l’attenzione sui canali virtuali? Anche se questo non è un libro per sviluppatori e probabilmente non svilupperai mai il tuo canale virtuale, è fondamentale che tu capisca come funzionano. Quasi ogni prodotto aggiuntivo di terze parti per Terminal Server fa uso di canali virtuali. Capire come funzionano i canali virtuali ti aiuterà a risolvere i problemi dei prodotti di terze parti che incontrerai senza dubbio nella tua carriera di Terminal Server.
Detto questo, diamo uno sguardo finale all’architettura di un canale virtuale. Fare riferimento alla figura 2.4.
Figura 2.4: Terminal Server 2003’s virtual channel architecture
Il componente del canale virtuale lato server è solitamente un eseguibile in esecuzione sul Terminal Server. Questo componente deve essere un componente in modalità utente, poiché il server utilizza l’ID di sessione per determinare a quale sessione lato client deve trasmettere e ricevere dati.
Il componente del canale virtuale lato client è solitamente una DLL fornita da Microsoft, il fornitore di software di terze parti o scritta su misura dagli sviluppatori. La DLL deve essere caricata sul computer client quando viene avviato il programma client RDC e inizia la connessione al server. Nella maggior parte dei casi questo è script o fatto a livello di codice a livello di client.
Come tutti questi componenti si incastrano
Ora che hai capito ciascuno dei vari componenti del Terminal Server, vediamo come si incastrano tutti insieme. Seguire il processo che avviene quando viene effettuata una connessione client, facendo riferimento alla Figura 2.5.
Figura 2.5: Viene stabilita una nuova sessione
- Prima che accada qualcosa, gli ascoltatori sul Terminal Server guardano determinate schede di rete, indirizzo IP e combinazioni di porte TCP per le richieste in entrata per avviare le sessioni.
- Un utente decide di utilizzare un’applicazione remota, quindi lancia il suo client RDC e richiede una connessione a ” server1.”Il suo client RDC controlla per vedere quali DLL di canali virtuali sono installate.
- In questo ambiente, il nome “server1” si riferisce all’indirizzo IP 192.168.14.42 (che sembra essere NIC #1 in questo server). Il client RDC dell’utente invia una richiesta di connessione di sessione a 192.168.14.42.
- Il listener del server preleva la richiesta e la passa al gestore della sessione. Quando il gestore di sessioni prende il sopravvento, l’ascoltatore riprende l’ascolto per più sessioni.
- Il server negozia con il client richiedente per il suo livello di crittografia e le capacità del canale virtuale.
- L’utente viene quindi autenticato al dominio e i suoi diritti vengono controllati per l’accesso alla connessione.
- Le licenze Microsoft sono verificate. Viene verificata prima la licenza di accesso client server, quindi viene verificata la licenza di accesso client Terminal Server. (La licenza è dettagliata nel Capitolo 4.)
- A questo punto, la sessione utente è pronta per iniziare. Gli script di accesso vengono eseguiti e il desktop viene caricato.
In Windows Server 2003, una porta listener è associata a una ” connessione.”In realtà, i due termini sono quasi intercambiabili. Si configurano le proprietà per una connessione e la porta listener della connessione viene modificata in modo appropriato.
Ora che abbiamo coperto tutti i componenti che compongono un server terminal di Windows 2003, passare ai requisiti.