The Desktop FilesAvvio da rete in Windows

Wes Miller

Indice

Funzionamento di PXE
Esplorazione di RIS
WDS: gli esordi
Altri componenti in gioco
Conclusioni

Nei prossimi pochi mesi intendo parlare dei Servizi di Distribuzione di Windows (WDS), disponibili per Windows Server 2003 e creati in Windows Server 2008. WDS può essere un componente molto importante nella vostra infrastruttura di distribuzione, quindi desidero accertarmi che disponiate di buone basi per la discussione. Questo

primo articolo esplorerà a fondo l'architettura di Pre-boot eXecution Environment (PXE; pronunciato pixie), la cronologia dei Servizi di installazione remota (RIS) e le altre tecnologie correlate a PXE utilizzate in Microsoft.

Quando sono passato al gruppo OS principale di Windows nel 2001, RIS era una delle tecnologie che ho ereditato (ed ero piuttosto terrorizzato di possederla, a causa della sua complessità e dipendenza dalle implementazioni di BIOS e dall'hardware). Ma era, oltre a Windows® PE, una delle tecnologie che ho apprezzato di più nel mio ruolo di Program Manager.

Ricordo quando ho installato per la prima volta Windows 3.0, utilizzando una serie di dischetti da 3,5". Con il tempo, l'installazione è diventata più semplice grazie ai CD avviabili (inclusi in alcune versioni di Windows 98). Ma il problema era che l'installazione richiedeva sempre dei supporti locali di qualche tipo e di un disco fisso locale.

Con il passare degli anni, la capacità di eseguire un avvio da rete in Windows, ovvero la possibilità di avviare tale sistema completamente sulla rete senza che fosse necessario un disco fisso, è stata una richiesta frequente dei clienti. A differenza di alcune versioni iniziali di Windows, Windows NT® non ha mai posseduto questa capacità. E mentre le versioni attuali di Windows Server® 2003 e Windows Server 2008 possono essere avviate tramite un initiator iSCSI, il processo è abbastanza diverso nel senso che non è realmente locale, ma comporta una dipendenza continua su un unità remota come l'unità di avvio.

Gestione dei client

• Valutazione del processo di gestione client RIS
• Pianificazione di un miglioramento della sicurezza di rete utilizzando client gestiti
• Gestione di computer client
• Installazione remota di un sistema operativo

A partire da Windows 2000, Microsoft ha iniziato a sviluppare la tecnologia che è oggi nota con la sigla RIS e che ha consentito un'installazione basata su rete. Lo scopo di RIS era relativamente semplice: inserire un'immagine del sistema operativo sul disco locale del computer di destinazione tramite PXE.

Funzionamento di PXE

Nella Figura 1 viene mostrata la sequenza di avvio di PXE. PXE è un protocollo relativamente semplice sviluppato da Intel e da altri fornitori all'interno dell'iniziativa Wired for Management. PXE deriva da Dynamic Host Configuration Protocol (DHCP), a sua volta derivato da BootP ed è generalmente implementato nella propria Network Interface Card (NIC). In parole povere, ecco cosa succede:

Figura 1 Sequenza di avvio di PXE (fare clic sull'immagine per ingrandirla)

Passaggio 1 Il BIOS di sistema esegue un avvio e determina l'ordine di avvio.

Passaggio 2 Se l'ordine di avvio colloca PXE prima dei dischi fissi, delle unità flash o dei CD-ROM o se nessuno di tali dispositivi è presente, la Universal Network Driver Interface (UNDI) viene caricata da NIC. NIC include un driver di periferica di rete dalle dimensioni estremamente contenute e un'implementazione Trivial File Transfer Protocol (TFTP). (Alcune implementazioni di BIOS richiedono che gli utenti finali premano il tasto F12 per l'avvio PXE. Questa opzione non è standard e consiglio di disabilitarla).

Passaggio 3 Il sistema inizia ad eseguire una semplice trasmissione User Datagram Protocol (UDP), ricercando un server DHCP. Questo è in realtà il primo passaggio della sequenza di avvio PXE e viene indicato con il termine Rilevamento. Tenere presente che il protocollo è UDP, il che significa che è necessario spendere del tempo prezioso con i propri router e switch per garantire che le comunicazioni PXE possono passare per tale protocollo.

Passaggio 4 Se un server DHCP percepisce la trasmissione, risponde di conseguenza con un indirizzo IP. Questo passaggio viene indicato con il termine Offerta. Il punto importante da ricordare in questo caso è che PXE è stateless e la quantità di informazioni di stato univoche del sistema che il client deve offrire a questo punto è piuttosto limitata (l'indirizzo MAC e, se disponibile, il System Management BIOS GUID, noto anche come GUID SMBIOS).

Passaggio 5 Il client, dopo avere ricevuto il pacchetto con l'indirizzo IP, rileva di avere effettivamente bisogno di ulteriori informazioni, ovvero dell'indirizzo del server PXE. Si verifica un'altra trasmissione, che include le informazioni dal server DHCP che ha risposto originariamente, In questo punto, il client comunica al server DHCP di avere bisogno di ulteriori informazioni, ovvero del percorso di un Network Boot Program (NBP). Questo passaggio è denominato Richiesta.

Passaggio 6 Il server PXE risponde con l'indirizzo del server PXE e con il percorso dell'NBP, un eseguibile di avvio estremamente piccolo le cui dimensioni devono essere inferiori a 32 KB. Questo passaggio è denominato Riconoscimento. Se si affronta questo processo come una sorta di gioco, si noterà probabilmente l'acronimo DORA (Discover, Offer, Request, Acknowledge) dei termini inglesi, un buon modo per ricordare la sequenza.

Tenere presente che, se sono stati installati Microsoft DHCP e WDS (o sono state utilizzate tecnologie di altri fornitori), il passaggio della richiesta non si verifica e, in effetti, il pacchetto Offerta originale del server DHCP contiene già il percorso del server PXE e del programma NBP (rimuovendo così due passaggi e del tempo prezioso).

Passaggio 7 Il client, che presenta lo stack del protocollo TFTP citato prima, scarica NBP dal percorso di rete specificato dal server PXE. TFTP è un protocollo obsoleto, estremamente piccolo e stateless. Non è stato scelto per la sua sicurezza o per le sue prestazioni e, infatti, molti amministratori di router lo disattivano per impostazione predefinita. Deve essere abilitato per consentire il funzionamento di PXE.

Molte implementazioni di PXE (tra cui RIS) includono la capacità di chiedere all'utente di premere F12 per continuare a questo punto, ma in genere questa opzione può essere disattivata dall'amministratore del server PXE. Il prossimo mese quando esaminerò più a fondo WDS, darò un'occhiata anche ad alcuni dei miglioramenti apportati da Microsoft in TFTPD (TFTP Daemon) di WDS per Windows Server 2008 con lo scopo di migliorare le prestazioni.

Passaggio 8 NBP viene inizializzato. Nel caso di RIS, questa operazione avvia un programma di caricamento avvio di Windows che inizia il processo di distribuzione. PXE (almeno il protocollo a livello di rete effettivo) non è più un componente del processo.

È importante ricordare che PXE (sia esso RIS, WDS o qualunque altra infrastruttura) non funziona correttamente su collegamenti lenti (può trasferire delle quantità considerevoli di dati) o su collegamenti ad elevata latenza come i satelliti (la comunicazione non viene eseguita adeguatamente e potrebbe venire interrotta).

Nel processo di avvio PXE si potrebbe notare che, quando il client invia la richiesta, non viene indicato in alcun modo da dove proviene tale richiesta. In realtà, non sono presenti dati di stato sufficienti che consentano al server PXE di rilevare tali informazioni. Ciò che generalmente accade è di solito una race condition, in cui il primo server a rispondere alla richiesta del client ha la meglio. Un paio di elementi possono aiutare a ridurre questo problema:

• Modificare la velocità di risposta di un server PXE o dell'altro. La potenza del server e la latenza di rete avranno un impatto sulla rapidità di risposta dei server. In effetti, i server utilizzati da Microsoft IT erano talmente validi che anche se il server PXE era presente nell'ufficio, i server aziendali in alcuni casi avrebbero avuto la meglio. In questo caso, è sufficiente impostare il proprio server PXE locale su un valore di timeout pari a zero per i client gestiti.
• Gestire i client. Questo aspetto è molto importante se si modifica il proprio server PXE per rispondere prima di altri server IT aziendali. Tramite la gestione dei propri client, si consentirà ad Active Directory® di comunicare a WDS o RIS che la richiesta proviene esattamente dal server in questione. Tenere presente che l'uso dello SMBIOS GUID è preferito come identificativo univoco per i propri sistemi in Active Directory ma, se uno SMBIOS GUID non viene implementato nei sistemi (probabile in presenza di un hardware relativamente obsoleto), è possibile (e sarà necessario) utilizzare un GUID basato sull'indirizzo MAC. Per ulteriori informazioni, vedere l'intestazione laterale "Gestione dei client".
• Non consentire che le comunicazioni di PXE attraversino switch o router; collocare un server PXE su ogni lato. Questa operazione ha lo svantaggio di essere piuttosto costosa da implementare e da gestire (ogni server deve disporre della propria immagine gestita).

I server RIS (e ora WDS), come i server DHCP di Microsoft, devono essere autenticati rispetto all'implementazione di Active Directory a cui sono associati. Lo scopo è ridurre gli eventuali problemi causati dai server PXE non adeguati (come nel caso di tempeste di trasmissione PXE) lasciando che Active Directory acquisisca tutte le informazioni su tali server.

Tenere presente che questa operazione protegge soltanto contro i server su cui Active Directory ha acquisito informazioni. Se si configura il proprio dominio o un server PXE non Microsoft, la situazione è diversa.

Una volta, alla Microsoft, un dipendente eccessivamente zelante ha configurato un server PXE non RIS per una distribuzione "zero-touch". Tale implementazione ha cancellato completamente i dati del disco fisso creando una nuova immagine. Ciò sarebbe stato utile se la distribuzione si fosse verificata in un laboratorio isolato (non collegato in rete), ma sfortunatamente non è andata così e il risultato è stata la cancellazione dei dati del disco di un dirigente Microsoft sul cui computer PXE precedeva il disco fisso nell'ordine di avvio.

Il problema non era poi così grave, poiché Microsoft dispone dell'opzione per richiedere sempre di premere F12 all'avvio di PXE, ma il server PXE in questione non disponeva di un ritardo, un prompt F12 né di alcun tipo di notifica. Di conseguenza, il dirigente ha perso realmente tutte le informazioni presenti sul suo computer e tutti i dati non protetti dal suo profilo utente mobile.

Questo episodio evidenzia l'importanza di isolare i propri server PXE in caso di utilizzo dell'opzione "zero-touch" o, per lo meno, la necessità di impostare il prompt F12.

Esplorazione di RIS

Ho ereditato RIS dopo la distribuzione di Windows 2000. Windows 2000 non ha avuto molta fortuna relativamente a RIS e i test, le prestazioni e altri vincoli limitarono l'utilizzo di RIS per Windows Server 2000 esclusivamente alla distribuzione di Windows 2000 Professional. Purtroppo, non è stato possibile distribuire i prodotti server tramite RIS. Windows 2000 era disponibile unicamente per computer x86, quindi è risultato essere un ottimo campo di test per RIS poiché ha coinvolto un prodotto su un'unica architettura. RIS includeva (e richiedeva) l'integrazione completa con Active Directory, si integrava bene nel server Microsoft DHCP e includeva il proprio TFTPD.

RIS utilizza NBP per continuare il download di TFTP e ridurre a sufficienza il kernel di Windows per iniziare il processo di configurazione. (A un certo punto, non appena Windows è passato da TFTPD ad una connessione al server basata su Server Message Block o SMB, il percorso del codice letterale viene in realtà condiviso con una tradizionale installazione di Windows 2000 o Windows XP avviata da un dischetto). Una volta inizializzata la modalità nativa di Windows, la configurazione di Windows inizia la procedura guidata RIS OS Chooser (OSC).

Le schermate di OSC sono pagine simili ad HTML 2.0 abbastanza configurabili. Tali pagine sono limitate in modo molto rigido e non possono contenere immagini o simili e, infatti, non possono contenere caratteri non ANSI (che hanno reso complessa la distribuzione di alcune lingue di Windows).

Il prodotto finale di RIS è un file txtsetup.sif sul server RIS. Al termine della procedura guidata OSChooser, il client viene riavviato in modo logico, ma il percorso del server RIS e del filetxtsetup.sif vengono conservati e ricaricati dopo tale riavvio. Questo file txtsetup.sif è essenzialmente uguale al file unattend.txt, con diversi campi aggiuntivi inclusi per semplificare il completamento del processo di configurazione di RIS.

RIS poteva eseguire anche una configurazione molto simile ad una tradizionale configurazione non presidiata (RISetup) e disponeva di un'infrastruttura basata su clonazione simile a Sysprep (RIPrep) con cui, infatti, condivideva il codice. Ma RIPrep consentiva anche il caricamento della propria immagine su un server RIS.

Tuttavia, RIS presentava alcune limitazioni fondamentali che sono diventate evidenti. La prima era la mancanza di supporto per la distribuzione server. Alcuni attacchi, tra cui Code Red e Sasser, combinati con le complessità dell'IT che diversi clienti principali hanno sperimentato direttamente in occasione della tragedia dell'11 settembre 2001, ci ha obbligato a individuare rapidamente una soluzione per i server RIS Windows 2000 esistenti per consentire la distribuzione di Windows Server. A questa soluzione stavamo lavorando da tempo per Windows Server 2003 ma non la avevamo ancora rilasciata formalmente.

Ulteriori informazioni sulle tecnologie correlate a PXE

• Descrizione dell'interazione PXE tra il client PXE, DHCP e il server RIS
• Pianificazione per distribuzioni del sistema operativo avviate da PXE
• Architettura PXE
• Servizi di installazione remota
• Installazione remota del sistema operativo
• Guida dettagliata all'installazione del sistema operativo
• Provider di PXE WDS
• Informazioni sui Servizi di installazione remota
• Servizi di distribuzione automatizzata di Windows Server 2003

In secondo luogo, in RIS mancava la capacità di automatizzare completamente la procedura guidata OSChooser, che fu successivamente abilitata con l'elemento <META ACTION="AUTOENTER"> in Windows Server 2003. Infine, OSChooser non poteva funzionare correttamente con caratteri non ANSI, un punto debole importante evidenziato da numerosi clienti residenti al di fuori degli Stati Uniti.

Di conseguenza, non era possibile completare un'installazione RIS con una tastiera francese, ad esempio. Il corretto funzionamento dei caratteri non ANSI a livello di BIOS su computer di tutto il mondo era estremamente complicato e non era semplice da realizzare.

Con la versione di Windows Server 2003, abbiamo aggiunto formalmente il supporto per l'architettura Intel Itanium e tutte le varianti server di Windows 2000 e Windows Server 2003. In Windows Server 2003 è stato inoltre aggiunto il supporto per l'architettura x64.

Per aumentare le prestazioni di RIS, è inoltre stato riscritto il relativo TFTPD. Windows Server 2003 supportava l'avvio simultaneo di un numero massimo di 75 client; tenete a mente che il limite superiore in questo caso viene raggiunto con il riempimento del pipe SMB a causa del traffico di rete verso i client.

WDS: gli esordi

Quando abbiamo iniziato a lavorare su RIS per "Longhorn" (il nome in codice per quello che è diventato Windows Server 2008), ci siamo subito resi conto che dovevamo fare un passo indietro. Come ho illustrato nelle sezioni precedenti nel mio articolo, avevamo già fatto grandi scommesse sulla configurazione basata sull'immagine (WIM) da Windows PE. Di conseguenza, il principio chiave su cui si basava WDS era la distribuzione basata su immagine da un'istanza di Windows PE avviata da PXE.

Sapevamo che Windows Server 2003 sarebbe stata la piattaforma comune per la distribuzione Windows Vista® e che avremmo avuto bisogno di una soluzione "fuori banda" per il downlevel di WDS. Di conseguenza, siamo riusciti a rendere possibile l'esecuzione di WDS su Windows Server 2003 SP1 e a creare WDS in Windows Server 2003 SP2.

Poiché può operare come server RIS (modalità legacy), server ibrido (modalità mista) o server esclusivo WDS (modalità nativa), WDS consente di eseguire la migrazione alle distribuzioni formali in stile WDS, come garantito. Ho sentito i clienti chiedere se esiste un modo per installare RIS su un sistema Windows Server 2003 SP2. Sì, esiste: è sufficiente installare WDS e attivare la modalità legacy. Nella Figura 2 vengono riportati i sistemi operativi supportati.

Figura 2 Piattaforme supportate per la distribuzione

WDS in Windows Server 2003 SP1 e SP2 ha cercato di iniziare il processo di migrazione a WDS. Come ho indicato prima, le funzioni principali di WDS in Windows Server 2008 erano un TFTPD rivisto, un supporto di avvio Extensible Firmware Interface (EFI) e, ovviamente, la distribuzione basata su multicast.

Altri componenti in gioco

I Servizi di distribuzione automatizzata (ADS) sono stati creati da un altro team interno a Microsoft, principalmente con l'obiettivo di un provisioning server rapido. ADS offriva un imaging formale basato sul settore, il relativo agent di avvio (più piccolo di Windows PE ma non ugualmente completo a livello di funzionalità), il relativo TFTPD e un multicast estremamente avanzato. La funzionalità creata in ADS è diventata disponibile fino ad un certo punto in System Center Configuration Manager (SCCM), nonostante non vi sia una parità di funzioni completa.

Windows XP incorporava un avvio PXE completo di tutte le funzioni tramite il relativo TFTPD in un RAMDisk, ma non consentiva la distribuzione remota in quel modo. La tecnologia è progettata per supportare l'avvio simultaneo di numerosi sistemi dalla stessa immagine disco tramite PXE.

Conclusioni

E questa è la storia, in sintesi. Per ulteriori informazioni, consultare l'intestazione laterale "Ulteriori informazioni sulle tecnologie correlate a PXE". Il prossimo mese esaminerò i principi di base di WDS, a cui seguiranno articoli sulla funzionalità avanzata di WDS (multicast e molto altro) e, infine, sull'utilizzo di WDS senza utilizzare WDS, da cui intendo partire per andare oltre l'esperienza attuale di configurazione/WDS con lo scopo di far funzionare le vostre tecniche di distribuzione personalizzate.

Wes Miller è un Senior Technical Product Manager di CoreTrace (www.CoreTrace.com) di Austin, Texas. In passato ha lavorato per Winternals Software e per Microsoft in qualità di Program Manager. È possibile contattarlo all'indirizzo technet@getwired.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.