Boot WS2012 da Thin Client diskless (via PXE)

[gnappoman]

Buongiorno a tutti

ecco il mio progetto EDIT (aggiustato!)

1- Server centrale con Debian
2- Su Debian virtualizzo (con virtualbox) Windows Server 2012 r2
3- Da alcuni Thin Client senza hard disk faccio il boot via PXE e mi collego via RDP all'immagine di WS2012

I punti 1 e 2 vanno bene, ho qualche dubbio per il 3 invece....


se non capisco male con questo dovrei cavarmela http://anywherets.com/products/anywherets/screenshots
anche se preferirei di gran lunga che tale software girasse su debian ...

Avete qualche link o consiglio?

Grazie,
Pino

[the_best_hacker]

Scusa, non vorrei essere banale. Perché non sfruttare direttamente Linux come desktop!? Tra l'altro penso sia un bel casino configurare virtialbox in modo che si colleghi direttamente con l'esterno (se non erro va ad emulare una scheda di rete per consentire la connessione, ma poi questa scheda non ha un IP)

Inviato dal mio LG-D802 utilizzando Tapatalk

[gnappoman]

innanzitutto grazie per la risposta immediata.

Nel mio scenario ho un server piuttosto grosso e una quarantina di client piccolini (una scuola), potrebbero risparmiare l'80% degli attuali costi (tra manutenzione e acquisto di hw/sw) se ce la facciamo.:fiufiu:

[TRUTEN]

Non ho capito: vuoi servire Server 2012 a tutti i thin client?
A naso non credo proprio si possa fare una roba del genere per l'EULA.

[gnappoman]

Non ho capito: vuoi servire Server 2012 a tutti i thin client?
A naso non credo proprio si possa fare una roba del genere per l'EULA.

Il tuo naso si sbaglia perchè si può fare, avendo acquistato le licenze Terminal Server

[malatodihardware]

Si ma non devi servire WS2012, devi solo dare l'accesso via RDP!

[the_best_hacker]

innanzitutto grazie per la risposta immediata.

Nel mio scenario ho un server piuttosto grosso e una quarantina di client piccolini (una scuola), potrebbero risparmiare l'80% degli attuali costi (tra manutenzione e acquisto di hw/sw) se ce la facciamo.:fiufiu:

Iniziativa ottima! Tra l'altro l'idea mi intriga troppo.. magari potrei riprodurre la cosa a casa mia xD
Purtroppo non saprei come risolvere i dubbi di cui parlavo prima.. cmq resto presente nel thread e se ho modo di aiutare sono pronto a farlo, in caso contrario resto in disparte ad imparare

Inviato dal mio LG-D802 utilizzando Tapatalk

[TRUTEN]

Il tuo naso si sbaglia perchè si può fare, avendo acquistato le licenze Terminal Server

Si ma le licenze terminal server servono a far connettere client al server fornendo OS guest: non è che dai 40 copie di server 2012.

Tra l'altro se hai comprato le terminal non vedo il senso di mettersi ad usare ubuntu e tutto l'ambardam della guida.
Cioè hai pagato la licenza di server 2012, hai comprato le terminal e poi ti metti ad usare linux per fare il boot quando hai già pagato per degli strumenti che fanno molto bene la stessa cosa?

[Shinobi]

Come ti hanno detto avendo comprato la licenza di Windows Server 2012 r2 e le linceze terminal server la via maestra è utilizzarlo per l'appunto come terminal server facendo connettere i dispositivi degli utenti (nel tuo caso thin client) al server stesso.
Attenzione che pur essendo un server unico le licenze dei programmi installati (ad esempio Office) devono essere congrui al numero di utenze che accedereanno al terminal server.
Attenzione anche nel verificare la portabilità di licenze eventualmente in uso sul terminal server: se ad esempio ora le 40 postazioni hanno 40 pc fisici con licenze OEM (che quindi si legano all'hardware con cui vengono vendute) allora tali licenze non saranno riutilizzabili con il terminal server.

Ti faccio queste precisazioni perchè ho letto della percentuale di risparmio rispetto alla situazione attuale (80%) e non vorrei che tu avessi dimenticato qualche cosa :asd:

[gnappoman]

ok, grazie per le risposte ragazzi, ho cambiato la domanda, perchè mi sono reso conto che con iSCSI ad ogni boot i thin client senza hard disk avrebbero dovuto ri-scaricare l'intera immagine del SO...

ora la mia domanda è diventata:

1- installo debian e ci metto virtualbox
2- virtualizzo windows server (lo faccio per sicurezza e comodità nel caso di migrazione hardware)
3- installo un programmino che permetta ai client PXE di connettersi in RDP

chiaramente il problema è il punto 3

se non capisco male con questo dovrei cavarmela http://anywherets.com/products/anywherets/screenshots
anche se preferirei di gran lunga che tale software girasse su debian ...

[Dane]

ok, grazie per le risposte ragazzi, ho cambiato la domanda, perchè mi sono reso conto che con iSCSI ad ogni boot i thin client senza hard disk avrebbero dovuto ri-scaricare l'intera immagine del SO...


Riscaricare al boot l'immagine non è per forza uno svantaggio. Immaginati di trovare un problema in ciò che i client caricano al boot. Dovresti farti il giro di 40 pc.
Certamente, il fatto di avere 40 pc che partono tutti insieme può essere un problema, che risolvi striminzendo il più possibile l'immagine al boot, oppure investendo sulla rete, oppure inventandoti qualcosa per limitare il problema.
Più che via iSCSI (lascialo perdere, non ti serve a 'na mazza, a meno di metterlo in read only) è più indicato usare tftp per scaricare l'iso o mettere direttamente / dei client su NFS (dove puoi gestire mountpoint in ro o rw ;-)). In quest'ultimo caso i client caricano da tftp il kernel e initramfs, tutto il resto da nfs condiviso ;-)

Immagino vorrai usare linux based per i thinclient.
AnywhereTS da quel che ho capito è un applicazione che gira su windows che ti prepara una iso per i client. Che a questo punto immagino sia software basato su linux.
Comunque, dovrebbe andar bene qualsiasi cosa che usa rdesktop o freerdp.
Ci sono diverse distro che fanno queste cose, non impuntarti su una in particolare. Alla fine tutto si riduce al client rdp.

Preparati ad aver noie con tastiere, audio, microfoni, smartcard, performance video, ecc ecc. Tutta roba superabile, a costo del tuo tempo.

ora la mia domanda è diventata:

1- installo debian e ci metto virtualbox
2- virtualizzo windows server (lo faccio per sicurezza e comodità nel caso di migrazione hardware)
3- installo un programmino che permetta ai client PXE di connettersi in RDP

chiaramente il problema è il punto 3

se non capisco male con questo dovrei cavarmela http://anywherets.com/products/anywherets/screenshots
anche se preferirei di gran lunga che tale software girasse su debian ...

Le tue ragioni sul migrare facilmente WS sono corrette, ma io non mi sognerei mai di far girare 40 utenti in un WS virtualizzato, per giunta in virtualbox. Vabbhè che il budget non sarà altissimo e quindi sarà probabilmente accettabile che le performance siano "così così", ma è inutile farsi del male aggratis.

Punto 3
Per fare il boot da PXE devi configurare il dhcp (va benissimo quello di windows, ma se preferisci dnsmasq ha integrato anche un server tftp), sulla rete (dominio di broadcast, ma possibilmente una scheda di rete, o ancora meglio: più schede di rete per distribuire un po' il traffico). La scheda di rete si prenderà le informazioni PXE dal Dhcp, che gli dirà cosa caricarsi (probabilmente finirai su pxelinux), e da lì gli dirai cosa fare (pxelinux non è tanto differente da isolinux ;-) )

buon divertimento!

[gnappoman]

Dunque stavo pensando di usare anywherets per far connettere appunto i client in RDP.
Scarto l'ipotesi dell'iSCSI e tftp perchè la rete è gigabit (il server ha due schede di rete gigabit) e non credo proprio che i thin client in questione riescano a tirarsi su in tempi accettabili il SO, oltretutto hanno poca ram..

RDP dal punto di vista dell'uso della banda è già meglio.

Per quanto riguarda invece la virtualizzazione, in effetti forse è meglio evitarla, sono molto indeciso, il server è piuttosto potente, ma mi sa che il collo di bottiglia come al solito sono i dischi, e non vorrei che alla prima applicazione un po' pesantuccia si pianti tutto..

[TRUTEN]

Ma Windows sui client siete costretti ad usarlo?

[gnappoman]

si

[stufillaro]

Buongiorno,
Io l'ho fatto
1 Hyper-v server 2012 R2 con
una VM domain controller e il software di boot
1 terminal server 2012 R2 (remote desktop services)

minimo 30 client costituiti da pc 32 bit da riciclare, desktop normali, portatili sia wired sia wireless.

I pc NON utilizzano il disco anche se lo posseggono in quanto 'staccati' dall'impianto vengono utilizzati come normali PC.
I PC ricevono il boot tramite PXE dal domain controller ed quanto basta solo per attivare il client Microsoft RDP Windows 7 concesso anche gratuitamente se lo si utilizza per riciclare macchine obsolete.
Il boot è molto piccolo in dimensioni (200/300MB) e su macchine con soli 512 MB funziona bene.
La rete gira sia 1 Gb sia a 100 Mb.
La connessione wireless si avvale di un router specifico che consente il boot PXE da WIFI.
Il server DC e il RD Server utilizzano più schede di rete.

[x9drive9in]

Buongiorno,
Io l'ho fatto
1 Hyper-v server 2012 R2 con
una VM domain controller e il software di boot
1 terminal server 2012 R2 (remote desktop services)

minimo 30 client costituiti da pc 32 bit da riciclare, desktop normali, portatili sia wired sia wireless.

I pc NON utilizzano il disco anche se lo posseggono in quanto 'staccati' dall'impianto vengono utilizzati come normali PC.
I PC ricevono il boot tramite PXE dal domain controller ed quanto basta solo per attivare il client Microsoft RDP Windows 7 concesso anche gratuitamente se lo si utilizza per riciclare macchine obsolete.
Il boot è molto piccolo in dimensioni (200/300MB) e su macchine con soli 512 MB funziona bene.
La rete gira sia 1 Gb sia a 100 Mb.
La connessione wireless si avvale di un router specifico che consente il boot PXE da WIFI.
Il server DC e il RD Server utilizzano più schede di rete.
Che immagine hai distribuito sui thin client?

Inviato dal mio SM-G928F utilizzando Tapatalk

[stufillaro]

@x9drive9in

Una immagine costruita con WinPE ridotto all'osso e con all'interno lo stretto indispensabile per attivare una sessione di remote desktop (client Windows 7 32 bit).
PS:
Tempo di caricamento su pc obsoleti dall'accensione al logon 10/30 sec
su pc attuali quasi immediato
su portatili immediato

[x9drive9in]

@x9drive9in

Una immagine costruita con WinPE ridotto all'osso e con all'interno lo stretto indispensabile per attivare una sessione di remote desktop (client Windows 7 32 bit).
PS:
Tempo di caricamento su pc obsoleti dall'accensione al logon 10/30 sec
su pc attuali quasi immediato
su portatili immediato

Perfetto, giusto l'idea che avevo avuto io

[gnappoman]

quindi scusa sui client c'è un hd se pur piccolo oppure no?

che sistema hai usato per fare il boot da pxe?

[stufillaro]

@gnappoman
Ci sono due sistemi di boot
1) PXE
2) Windows client 7 x86 limited edition su disco per garantire l'utilizzo di alcuni PC quando l'aula NON lo può utilizzare tramite PXE.

Il sistema che si avvale del boot PXE va bene per il caso che Le interessa in quanto architettonicamente coerente, ma non è l'unica via per usufruire di applicazioni remote, in quanto non esiste solo RDP e/o quel modo di utilizzare RDP.
Per architettura il sistema RDS Microsoft qualora sia abbia bisogno anche solo di un browser bisogna avere PRIMA un sistema operativo che contenga eventualmente tutto ciò POI serve al browser, sistema operativo che contenga tra le varie applicazioni, driver, componenti anche un browser e quello nativamente previsto è Internet Explorer : non è previsto per ora un OS limitato al solo browser (In Microsoft) e/o nativamente differente da Internet Explorer
Di conseguenza o si carica tramite PXE un sistema operativo (WinPE) limitato alle sole cose indispensabili (driver video, tastiera, mouse, client RDP e in caduta del resto che serve) o non fa nulla (Nell'architettura Microsoft a cui ha affermato di non poter rinunciare).
Le consiglio di studiare bene la questione licenze per non avere amare 'sorprese'.
Non sottostimi che nella mia sintesi precedente io ho omesso di elencare tutto il sw e l'infrastruttura necessaria perché l'azione sia compiuta appieno.
Non è sufficiente avere un domain controller, devono esser installati roles, services role, features ulteriori, poi si deve personalizzare il sistema ,creare delle poicy, ottimizzare.
Il server TFTP è perfettamente funzionante nel mondo Microsoft ma NON è nativo.
Il tutto richiede una impegnativa progettazione, strumentazione e realizzazione che non si deve dare per scontato!
Buon lavoro

[gnappoman]

grazie delle info!

i tuoi client hanno un hard disk seppur piccolo con qualcosa caricato su, oppure no?

[x9drive9in]

grazie delle info!

i tuoi client hanno un hard disk seppur piccolo con qualcosa caricato su, oppure no?

Penso sia questo:
2) Windows client 7 x86 limited edition su disco per garantire l'utilizzo di alcuni PC quando l'aula NON lo può utilizzare tramite PXE.
Io ho provato ccboot per fare il boot pxe su client diskless da un'immagine vhd ma oltre alla configurazione iniziale non proprio immediata ho anche avuto problemi su pc (quei pochi che ho a casa) con la scheda madre che non veniva riconosciuta subito bloccando quindi il boot. L'ideale sarebbe che il thin client si scaricasse l'immagine in locale al momento del boot e farla fuori allo spegnimento in modo che continui a funzionare senza crash se cade per un attimo la connessione senza riavviare tutto.

[gnappoman]

@gnappoman
Ci sono due sistemi di boot
1) PXE
2) Windows client 7 x86 limited edition su disco per garantire l'utilizzo di alcuni PC quando l'aula NON lo può utilizzare tramite PXE.

Il sistema che si avvale del boot PXE va bene per il caso che Le interessa in quanto architettonicamente coerente, ma non è l'unica via per usufruire di applicazioni remote, in quanto non esiste solo RDP e/o quel modo di utilizzare RDP.
Per architettura il sistema RDS Microsoft qualora sia abbia bisogno anche solo di un browser bisogna avere PRIMA un sistema operativo che contenga eventualmente tutto ciò POI serve al browser, sistema operativo che contenga tra le varie applicazioni, driver, componenti anche un browser e quello nativamente previsto è Internet Explorer : non è previsto per ora un OS limitato al solo browser (In Microsoft) e/o nativamente differente da Internet Explorer
Di conseguenza o si carica tramite PXE un sistema operativo (WinPE) limitato alle sole cose indispensabili (driver video, tastiera, mouse, client RDP e in caduta del resto che serve) o non fa nulla (Nell'architettura Microsoft a cui ha affermato di non poter rinunciare).
Le consiglio di studiare bene la questione licenze per non avere amare 'sorprese'.
Non sottostimi che nella mia sintesi precedente io ho omesso di elencare tutto il sw e l'infrastruttura necessaria perché l'azione sia compiuta appieno.
Non è sufficiente avere un domain controller, devono esser installati roles, services role, features ulteriori, poi si deve personalizzare il sistema ,creare delle poicy, ottimizzare.
Il server TFTP è perfettamente funzionante nel mondo Microsoft ma NON è nativo.
Il tutto richiede una impegnativa progettazione, strumentazione e realizzazione che non si deve dare per scontato!
Buon lavoro

che configurazione / software hai utilizzato sul server per fare il boot da pxe?

[stufillaro]

@gnappoman
Pensavo di esser stato chiaro.
Io ho utilizzato due sistemi di boot intendendo o uno o l'altro: non tutti e due insieme.
Il PXE va bene dove c'è il boot HW PXE: non tutti i device lo hanno, lì è impossibile usarlo e non si può, ma solo lì, che avvalersi di un sistema operativo locale NON caricato tramite PXE ma alternativo al PXE.
Il sistema operativo locale può trovarsi su un device collegato al computer
hard disk, eprom residente, uefi bios, usb, cd/dvd rom al limite ISCSI remoto.
Io ho preferito utilizzare lo stesso hard disk del pc in quanto quei pc NON vengono utilizzati solo per il remote desktop service ma anche alternativamente come semplici e normali workstation in quel momento NON client RDP.
Negli altri device (NON PC) che vengono utilizzati dove non c'è il doppio uso utilizzo solo il PXE anche perché, alcuni non possiedono affatto un hard disk.
Questi sono Table, smartphone, notebook, netbook, terminali client, pc senza hd e così via.
Per la configurazione dell'ambiente non ho a disposizione 4 regole tipo premi lì, inserisci cos', scarica questo perché il lavoro è lungo, complesso e da professionisti intendendo chi lo fa per mestiere.
Se si vuole provare io ho fatto riferimento alla guida online WDS di Microsoft abbinata alla situazione specifica.
Poi ho generato un WinPE modificato escludendo ciò che ho dovuto stabilire che non serviva e arbitrariamente decidere così.
Poi ho costruito l'infrastruttura che prevede switch, router se ci sono più reti, (nel mio caso 8) e soprattutto la convivenza contemporanea con altri utilizzi della rete incompatibili con questo.
Un boot PXE richiede, per capirci, TFTP, DHCP configurati diversamente da DHCP ad utilizzo 'normale' e se nella stessa rete insistono contemporaneamente devono esistere regole che impediscano che chi non ne ha bisogno si trovi ad utilizzarlo.
Questo purtroppo non è riducibile a poche operazioni semplicizzate.
Ma se ci sono riuscito io ...

[x9drive9in]

Seguendo questa guida abbinata a ccboot si può creare un'immagine di centos da distribuire via pxe ai client. Una volta fatto ciò i client possono essere configurati per l'accesso a rdp da centos ma si risolve il problema di distribuzione dell'immagine e di quale immagine usare
http://www.ccboot.com/wiki-create-linux-boot-image.htm

[stufillaro]

@gnappoman
Buongiorno,
la via consigliata dall'utente @x9drive9in è una possibile alternativa.
Ne esistono altre anche più semplici da realizzare
La provai tre anni orsono e la scartai perché preferii avere un solo sistema operativo che faccia tutto coerentemente all'architettura totale.
Se l'ambiente è LINUX tutto sotto LINUX, server, client.
Se l'ambiente è WINDOWS tutto sotto WINDOWS, server, client.
In più non mi piaceva l'idea di un altro strato parallelo e precedente come l'ISCSI.
Terzo, se devo accedere ad un RDS che è un prodotto Windows debbo essere nelle condizioni di poter lavorare da lì in poi nell'ambiente Windows reale non in una sua imitazione.
RDS non è solo accesso ad un server che svolge il ruolo di terminal e basta, è l'integrazione tra componenti che ha una sua coerenza architettonica.
Le stampanti ribaltate ad esempio non possono essere a loro volta remotizzate ulteriormente se non dentro Windows, proprio perché il client RDP Windows già lo prevede dal boot.
Così dicasi dell'accesso alle nuove features (SMB 3, cluster di più dischi senza hw dedicato, data deduplication, Direct Access etc.)
Come faccio a stampare se il terminal server è a 100 Km dal client RDP e il client RDP non può avere una stampante collegata ?
debbo ribaltare la stampante ad un altro server a cui accedo tramite il terminal non tramite il client e assoggettandomi alle policy di gestione che sono nell'Active Directory, ergo la mia sessione deve essere anche come quella di un client Active Directory
Poi ci sono le licenze che valgono con dovute cautele per client nativi Windows e non valgono affatto per client LINUX.
Poi c'è l'integrazione Active Directory specifica (OU, Gruppi Universali, policy etc.): non è sufficiente il logon.
Ci sono le applicazioni remotizzate singole(Remote App).
Ci sono i desktop virtuali (VDI)
Tutti impossibili tramite client differenti da Windows o se possibili con particolari limitazioni.
La versione Windows server 2012 R2 rende notevolmente più semplice la creazione, gestione dell'intera architettura permettendo anche macchine virtuali come RDS in un server contenitore senza GUI.
Il problema è il costo elevato, molto elevato.
Per sperimentare, le versioni trial consentono tre periodi gratuiti di 180 giorni eppoi si può ripartire da capo.
Non è concesso l'uso al posto di licenze regolari.

[gnappoman]

Vi ringrazio molto delle risposte.
Se non capisco male le vostre soluzioni non inizializzano una sessione RDP dopo il boot da pxe , ma si basano su una installazione locale (minimale) sui client, che poi inizializza RDP.

Quello che stavo cercando è una soluzione completamente diskless, che non carichi via pxe un intero ambiente operativo, ma una semplice sessione RDP.:mc:

[x9drive9in]

Vi ringrazio molto delle risposte.
Se non capisco male le vostre soluzioni non inizializzano una sessione RDP dopo il boot da pxe , ma si basano su una installazione locale (minimale) sui client, che poi inizializza RDP.

Quello che stavo cercando è una soluzione completamente diskless, che non carichi via pxe un intero ambiente operativo, ma una semplice sessione RDP.:mc:

Entrambe si basavano sul boot via pxe di un sistema minimale linux o windows dal quale poi poter usare app minimali (es. un browser) o iniziare una sessione rdp. Tale sistema può risiedere anche sull'hdd del client senza usare il pxe

[stufillaro]

@gnappoman
Buongiorno,
concordo con quanto ha scritto l'utente @x9drive9in.
Forse è meglio che studi il meccanismo PXE come agisce indipendentemente dalla sua specifica necessità.
Le risulteranno molto più chiare tante cose.
I terminal client venduti da anni a 50$ il disco rigido non lo hanno proprio.
Per niente: non c'è alcun controller disco sulla loro motherboard
Utilizzano SOLO il boot PXE.
Se fa una ricerca in Internet troverà anche gli schemi fisici di centinaia di modelli.
Il sistema operativo minimale (WinPE o Centos minimale o altre decine di tipi) viene localizzato (copiato ed espanso) nella RAM del terminal (o PC) tramite il boot che utilizza il PXE SOLO nel momento del boot.
Poi (il sistema operativo) cancella dalla RAM la parte di codice che non gli serve più(potrebbe non farlo ma è per risparmiare memoria).
Eppoi...
Mi scusi ma in un post precedente Le avevo risposto che
NON
può fare a meno di un sistema operativo (ambiente operativo per Lei) per quanto limitato, in quanto l'RDP è l'ultima cosa che avviene dopo che ne sono state avvenute tantissime altre.
Tutte in uno spazio limitatissimo di memoria (WinPE anche solo 300 MB, Centos o LINUX based penso ancor meno).
A meno di non servirsi di un chip embedded e relative eprom che al proprio interno hanno già quello che fa la differenza.
E' sempre un sistema operativo in questo caso residente cioè né su disco locale (IDE; SCSI, etc.) , né su disco remoto (ISCSI, PXE, SMB etc.) ma una parte sul chip custom e una parte nella ram.
Esistono mother board per processori INTEL che lo hanno nell'UEFI BIOS (il portatile da cui sto scrivendo).
Le tablet e alcuni smartphone sono un altro esempio ma vanno programmati.

Buon lavoro

[x9drive9in]

A grandi linee questa guida serve a fare quello che cerchiamo come dice @stufillaro avendo windows sia lato server che lato client
https://www.interworks.com/blog/tlester/2014/08/25/deploying-windows-thin-pc-windows-deployment-server
L'ho letta velocemente, conto di testarla in macchina virtuale nei prossimi giorni

[pinc0]

discussione interessante....
in passato ho usato pxe per caricare os su pc che non avevano cd/dvd, o che non supportavano immagini superiori di 700mb.
@stuffilaro
parlavi si switch dedicati e con caratteristiche necessarie al pxe.
potresti dire che switch hai usato?

[x9drive9in]

A grandi linee questa guida serve a fare quello che cerchiamo come dice @stufillaro avendo windows sia lato server che lato client
https://www.interworks.com/blog/tlester/2014/08/25/deploying-windows-thin-pc-windows-deployment-server
L'ho letta velocemente, conto di testarla in macchina virtuale nei prossimi giorni
Testata ieri sera e lasciata a metà ma ho capito il funzionamento ed è utile solo per la distribuzione di immagini di Windows personalizzate attraverso il sysprep usando il WDS integrato in windows server. Probabilmente giocando con questo tool si può fare qualcosa (so che funziona anche per ripristinare i backup nei pc active directory). Altrimenti l'alternativa rimane ccboot (pacchetto che crea una SAN iscsi e usa gpxe per il boot) o etherboot se (come me in macchina virtuale) si vuole usare una San iscsi separata. Voglio comunque approfondire il WDS

Inviato dal mio SM-G928F utilizzando Tapatalk

[stufillaro]

@x9drive9in
Buongiorno,
come avrà capito il procedimento è a beneficio di PC che dopo una prima installazione non hanno più bisogno di ripeterla, da quel momento in poi vivono di quello che hanno avuto la prima volta.
C'è un' overhead difficilmente calcolabile, oltre alla gestione degli stages (client iscritti in active directory precedentemente al loro materiale esserci) quei client NON possono cambiare MAC ADDRESS, non possono essere aggiornati, rispondono a policy Active Directory minimali che condizionano il loro utilizzo quando diventano RDP.
Soprattutto NON possono essere macchine da 'riciclare' in quanto seguendo gli aggiornamenti Windows prima o poi avranno poca memoria RAM a disposizione in quanto il sistema operativo THIN Client anche esso è soggetto ad ulteriori espansioni di RAM nel tempo NON prevedibili.
Cosa succede allora quando si ha OUT OF RAM ?
Indietro non si può tornare avanti nemmeno ...
La soluzione è un sistema operativo che abbia il minimo indispensabile per lavorare solo in RDP e non un sistema operativo normale che casualmente, mentre non utilizza gli altri pezzi che intanto HA in memoria, utilizzi solo l'RDP.
Ci metta poi che le attività temporanee che comunque per quanto limitate anche il cliente RDP esegue (creazione, stream, file, temp, virtual memory etc.) nel caso di un supporto fisico tipo hard disk contano sullo stato di salute dell'impianto nascosto dietro 'l'hard disk'.
Nel caso di un OS scaricato dal PXE boot solo in memoria i problemi possono intervenire solo se la RAM fallisce o se la rete cade.
Se il disco rigido si rovina si deve rifare una macchina non basta riaccenderla...

[x9drive9in]

@x9drive9in
Buongiorno,
come avrà capito il procedimento è a beneficio di PC che dopo una prima installazione non hanno più bisogno di ripeterla, da quel momento in poi vivono di quello che hanno avuto la prima volta.
C'è un' overhead difficilmente calcolabile, oltre alla gestione degli stages (client iscritti in active directory precedentemente al loro materiale esserci) quei client NON possono cambiare MAC ADDRESS, non possono essere aggiornati, rispondono a policy Active Directory minimali che condizionano il loro utilizzo quando diventano RDP.
Soprattutto NON possono essere macchine da 'riciclare' in quanto seguendo gli aggiornamenti Windows prima o poi avranno poca memoria RAM a disposizione in quanto il sistema operativo THIN Client anche esso è soggetto ad ulteriori espansioni di RAM nel tempo NON prevedibili.
Cosa succede allora quando si ha OUT OF RAM ?
Indietro non si può tornare avanti nemmeno ...
La soluzione è un sistema operativo che abbia il minimo indispensabile per lavorare solo in RDP e non un sistema operativo normale che casualmente, mentre non utilizza gli altri pezzi che intanto HA in memoria, utilizzi solo l'RDP.
Ci metta poi che le attività temporanee che comunque per quanto limitate anche il cliente RDP esegue (creazione, stream, file, temp, virtual memory etc.) nel caso di un supporto fisico tipo hard disk contano sullo stato di salute dell'impianto nascosto dietro 'l'hard disk'.
Nel caso di un OS scaricato dal PXE boot solo in memoria i problemi possono intervenire solo se la RAM fallisce o se la rete cade.
Se il disco rigido si rovina si deve rifare una macchina non basta riaccenderla...

Nel frattempo ho completato i test e WDS è utile solo per la distribuzione. Tuttavia ho trovato su youtube diversi tutorial che usando il server dhcp integrato in windows server insieme ad un iscsi target permettono di fare quello che cerchiamo usando un client diskless. Procedimento un po' lunghetto che mi riservo di testare appena ho qualche giorno di vacanza a scuola

[gnappoman]

io invece sto usando una soluzione con vrdp (virtualbox remote desktop protocol)

in sostanza ho windows virtualizzato su debian e il client si connette direttamente a windows via vrdp...

ps
in un'altra installazione invece avevo usato questo
http://openthinclient.org/en/open-thinclient/

[x9drive9in]

io invece sto usando una soluzione con vrdp (virtualbox remote desktop protocol)

in sostanza ho windows virtualizzato su debian e il client si connette direttamente a windows via vrdp...

ps
in un'altra installazione invece avevo usato questo
http://openthinclient.org/en/open-thinclient/

Avevo guardat openthinclient ma come suggeriva stufillaro è meglio avere sempre lo stesso sistema (server windows e client windows o server linux e client windows) perchè alcune funzioni (es. il VDI) non sono supportate.

[x9drive9in]

Torno sulla vicenda per postare la mia soluzione. Ho smanettato in questi giorni creando un ambiente virtuale con windows server 2012 r2 essentials + ccboot (software tftp e iscsi target, consiglio di guardare dei tutorial su youtube ce ne sono una miriade e ben fatti) + windows thin pc e tutto funziona in base a quello che cercavamo. Avviata la macchina e fatto il boot via pxe, parte un'immagine di windows thin pc dal vhd salvato nella macchina con windows server (tutto via rete).
Appena ho più spazio sul disco proverò a simulare un vero ambiente di thin client quindi magari qualche macchina in più con windows tpc che si collega a più utenze di windows server