Boot WS2012 da Thin Client diskless (via PXE)

[gnappoman]

grazie delle info!

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

[x9drive9in]

Originariamente inviato da gnappoman

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]

Originariamente inviato da 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

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.

[x9drive9in]

Originariamente inviato da 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.

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/tles...loyment-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]

Originariamente inviato da 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/tles...loyment-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]

Originariamente inviato da 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...

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]

Originariamente inviato da 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/

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