The Desktop FilesPersonalizzazione di Servizi di distribuzione Windows

Wes Miller

Indice

Sostituzione dei componenti esistenti
Descrizione dello stack
Programma di avvio di rete
Provider PXE di Servizi di distribuzione Windows
TFTP Daemon
Archivio dati di configurazione di avvio
Windows PE
Server di trasporto
Multicast personalizzato
Conclusioni

Negli ultimi tre articoli mi sono occupato di Servizi di distribuzione Windows (WDS), partendo dalle origini, fornendo poi panoramica, per trattare successivamente in dettaglio alcuni argomenti avanzati, quali WDSUtil e multicast. In questo articolo, che conclude la serie, illustrerò dove e come sia possibile personalizzare e configurare WDS per soddisfare le esigenze della propria organizzazione. La maggior parte degli strumenti Microsoft sono progettati con un determinato numero di elementi configurabili. Tuttavia, solo quando si passa all'utilizzo pratico, si scopre se gli strumenti sono davvero in grado di soddisfare le proprie esigenze oppure se, come più spesso accade, siano necessarie ulteriori modifiche per adattarli agli scenari esistenti.

Sostituzione dei componenti esistenti

Ultimamente, i lettori mi hanno posto spesso questa domanda: "Utilizzo x (una tecnologia di distribuzione esistente): WDS è adatto nel mio caso ed è disponibile con la funzione di parità con x?" Con la rimozione di Servizi di distribuzione automatica (ADS), una questione di particolare interesse è come riuscire a eseguire rapide distribuzioni di elevati volumi o riconfigurazioni di server e se WDS sia adatto per tali operazioni.

Sebbene WDS non sia stato progettato per sostituire in tutto e per tutto ADS, e in effetti mancano alcuni componenti chiave per poterlo considerare un vero sostituto, apportando determinate modifiche è possibile utilizzarlo al posto di ADS. Analogamente, se alcuni aspetti di WDS non sono adatti per alcuni scenari, molti dei relativi componenti possono essere sostituiti, con diversi livelli di complessità e progettazione. Di seguito sarà descritta la distribuzione tramite WDS, esaminando i componenti che si possono personalizzare e le procedure da seguire a questo scopo.

Descrizione dello stack

Nella Figura 1 vengono illustrati i componenti del processo di distribuzione di WDS. Ciascuna di queste fasi può essere parzialmente personalizzata. A ogni fase è assegnato un colore che ne rispecchia la complessità, ossia in generale le competenze in termini di sviluppo necessarie per sostituire o personalizzare un componente. Le fasi blu scuro sono quelle in cui la personalizzazione è più complessa.

Figura 1 Complessità della personalizzazione di WDS

È ovvio che la reale difficoltà di personalizzazione di ciascuna fase dipende sia dalle competenze (relative a sviluppo o creazione di script) del team che se ne occupa, sia dal livello di conoscenza di WDS, WIM (Windows Imaging Format), Active Directory o qualsiasi altra tecnologia che si intende integrare, ad esempio SQL o ADSI. Di seguito sarà esaminata ognuna di queste fasi: i lettori potranno riflettere sulle modalità con cui eseguire la personalizzazione e ai metodi applicabili.

Programma di avvio di rete

È improbabile che sia necessario creare un programma di avvio di rete (NBP) personalizzato per sostituire quello fornito con WDS, ma è possibile. WDS include alcuni NBP che possono essere utilizzati con sistemi headless (in generale, server) o sistemi in cui si desidera o meno che venga richiesto di premere il tasto F12 per l'avvio e così via. Gli NBP possono essere gestiti in Active Directory mediante WDSUtil, oppure è possibile sostituire Startrom.com con l'NBP da utilizzare per tutti i sistemi che non sono predisposti (ad esempio, se tutti i sistemi in uso sono headless o si desidera non utilizzare mai un prompt F12).

Purtroppo, la documentazione disponibile sulla creazione di NBP non è molto estesa (per alcune informazioni, visitare il sito msdn.microsoft.com/library/bb870970.aspx). Un NBP è un file eseguibile a 16 bit di dimensioni molto ridotte, che presenta rigide restrizioni e richiede specifiche competenze di programmazione. In generale, si consiglia di utilizzare gli NBP esistenti forniti con WDS, a meno che non sia necessario soddisfare requisiti assai specifici e si disponga di un team di sviluppo con competenze adeguate.

Provider PXE di Servizi di distribuzione Windows

Con Servizi di installazione remota (RIS), tra i commenti e suggerimenti dei clienti si riscontrava un desiderio comune di utilizzare un archivio dati diverso da Active Directory per le informazioni sui sistemi client, nella maggior parte dei casi SQL Server. Con WDS, la progettazione prevede un'infrastruttura collegabile per provider Pre-Boot eXecution Environment (PXE). Questo significa che, con un po' di sviluppo, è possibile utilizzare un altro archivio di backup oltre ad Active Directory per le informazioni PXE.

WDS è fornito con il relativo provider che utilizza Active Directory. System Center Configuration Manager (SCCM) si collega ora a WDS e implementa un proprio provider. La documentazione sulla scrittura di un provider personalizzato scarseggia e non è disponibile molto codice di esempio (sebbene il Windows SDK fornisca documenti e un paio di esempi), quindi si tratta di un'attività complessa. A meno che non si debbano soddisfare esigenze davvero specifiche per questo aspetto del processo di avvio, anche in questo caso non è consigliabile tentare di creare un provider PXE personalizzato.

TFTP Daemon

Prima che WDS fosse distribuito, alcuni clienti hanno investito nella creazione di un proprio protocollo Trivial File Transfer Protocol Daemon (TFTPD). Poiché i server PXE non si adattano facilmente tra loro, spesso questo significa utilizzarne uno solo.

In base alle esperienze avute finora, in genere questo comporta l'utilizzo di un TFTPD esistente, di solito basato su Linux, che viene trasformato in modo da avviare altri sistemi operativi. Con l'infrastruttura originale utilizzata dal RIS, questa operazione non sarebbe stata possibile. Tuttavia, da quando l'avvio da RAMDisk è diventato la norma, l'operazione è possibile e si può eseguire utilizzando immagini di avvio basate su WDS.

È importante ricordare che si tratta di un'area priva di supporto tecnico per quanto riguarda Microsoft e che, nella maggior parte dei casi, può causare problemi difficili da diagnosticare. Inoltre, l'ottimizzazione del TFTPD in WDS non garantisce prestazioni migliori. In generale, è consigliabile utilizzare il TFTPD esistente di WDS, cercando di sfruttare timeout, gestione e/o margini di rete del server PXE per definire quali client eseguono l'avvio da determinati server PXE, anziché tentare di modellare un server esistente sulle proprie esigenze.

Archivio dati di configurazione di avvio

Con RIS, al livello di avvio non era possibile specificare gli elementi da inizializzare: era infatti necessario selezionare dapprima il sistema operativo, quindi un'opzione (configurazione, Windows PE - Windows Preinstallation Environment - o altro). WDS invece, poiché utilizza un caricatore completo per l'avvio di rete, supporta anche la personalizzazione dell'archivio dei dati di configurazione di avvio (BCD) fornito ai client. L'archivio BCD predefinito per tutte le architetture si trova in RemoteInstall\Boot\<arch>\Default.bcd, dove <arch> è l'architettura specifica del sistema che viene inizializzato.

È possibile personalizzare il BCD per ciascun client, che lo utilizzerà per l'avvio. Ad esempio, si può impostare una voce BCD che avvia l'installazione, un'altra per l'esecuzione di Ambiente ripristino Windows (WinRE) e un'altra ancora per l'esecuzione di un test sulla memoria. In alternativa, si può impostare una voce di installazione automatica come opzione predefinita e una voce manuale (o di procedura di installazione personalizzata) come opzione selezionabile da parte dell'utente (per ulteriori informazioni, consultare l'articolo sulle modalità di modifica dell'archivio BCD tramite l'utilizzo di Bcdedit all'indirizzo go.microsoft.com/fwlink/?LinkId=115267).

Naturalmente, la maggior parte delle operazioni di WDS sono svolte in Windows PE, pertanto la modifica dell'ambiente al fine di soddisfare le proprie esigenze può rappresentare un'area critica su cui concentrare l'attenzione per una procedura di installazione personalizzata. Per impostazione predefinita, WDS fornisce un modello standard per l'installazione, che include la procedura di installazione completa. A seconda delle proprie esigenze di distribuzione, questa soluzione potrebbe non risultare adeguata. In tal caso è possibile creare la propria immagine di avvio di Windows PE. È opportuno partire dall'inizio.

Oltre a usare BCD per indicare quale immagine utilizzare, è possibile specificare l'immagine personalizzando l'oggetto account (MAO) per un computer in Active Directory. In RIS un attributo MAO specifico memorizzava ciascun elemento (il file Startrom e di installazione automatica, SIF, da utilizzare). Con WDS, questi sono memorizzati come coppie nome-valore in corrispondenza della voce netBootMirrorDataFile. Ad esempio, in questa voce sono memorizzati l'immagine di avvio e il file di installazione automatica che un determinato computer deve utilizzare. La forma delle voci è un elenco di coppie nome-valore delimitate da punto e virgola. Le voci per modificare l'immagine di avvio e il file di installazione automatica sono rispettivamente BootImage e UnattendFilePath.

È naturalmente possibile che sia necessario eliminare completamente la procedura di installazione esistente e crearne una personalizzata. Ad esempio, potrebbe essere necessaria una maggiore configurabilità, una maggiore automazione o un build automatizzato da SQL Server. Potrebbe inoltre essere necessario realizzare, come alcuni clienti hanno fatto in precedenza per RIS e Windows PE, un front-end personalizzato per l'installazione. Le attività principali che occorre svolgere, indipendentemente dalla procedura di installazione che si sta scrivendo, sono le seguenti:

• Scoprire qualsiasi informazione specifica su computer o utenti. Queste informazioni si possono ottenere tramite gli utenti o, ad esempio, tramite SQL Server o un file di testo.
• Copiare e applicare un'immagine di installazione al sistema client. È possibile svolgere tale attività utilizzando direttamente l'installazione, utilizzando ImageX per applicare un'immagine da una condivisione di rete o tramite multicast (copiare semplicemente l'immagine e applicarla tramite ImageX).
• Fornire un file di installazione automatica (ad esempio, Unattend.xml o sysprep.inf, a seconda della versione di Windows distribuita) per completare l'installazione.
• Automatizzare qualsiasi fase di migrazione post-installazione da eseguire (o qualsiasi passaggio per l'applicazione di ruoli nel caso di Windows Server 2008).

ADS ha introdotto il concetto di sequenze di attività che consentono l'assegnazione di passaggi ripetibili a uno o più computer. Poiché ADS non è stato progettato o supportato per l'utilizzo con Windows XP, non è possibile utilizzarlo per la distribuzione del sistema operativo. Tuttavia, le sequenze di attività ADS sono semplici script strutturati ed è possibile eseguire gli stessi passaggi utilizzando un processo di installazione personalizzato.

Poiché per molto tempo sono stato un sostenitore di Microsoft SQL Server (dalla versione SQL Server 6.5), l'istinto mi suggerisce di realizzare la struttura utilizzando SQL. A tal fine è ovviamente necessario aggiungere al proprio Windows PE la funzionalità SQL. Inoltre, è possibile scrivere la propria GUI (applicazione HTML, HTA o file eseguibile compilato) o utilizzare Windows Script Host (WHS) per eseguire una procedura di installazione minimalista, composta da una sola riga di comando. Per poterli utilizzare, si deve aggiungere a Windows PE anche HTA o WSH.

La complessità della progettazione di una procedura di installazione personalizzata dipende interamente dalle competenze e dall'immaginazione di chi se ne occupa. Ho visto sistemi piuttosto eleganti definiti unicamente utilizzando SQL e WSH oppure HTA, che sono competenze relativamente semplici da acquisire. È molto importante, tuttavia, tenere presenti i vincoli citati negli articoli precedenti:

• Windows PE non dispone di alcun sottosistema Windows on Windows (WOW), quindi è necessario compilarlo per ciascuna architettura che si intende supportare.
• Se è necessario eseguire la distribuzione tramite Windows PE x64 o IA64, non è possibile utilizzare Visual Basic 6.0.
• È possibile utilizzare Visual Studio 2005 o 2008 per creare applicazioni, ma occorre creare un'applicazione Visual C++ non gestita, poiché Windows PE non supporta alcuna versione di Microsoft .NET Framework.
• Senza .NET Framework, è inoltre impossibile utilizzare Windows PowerShell per l'automazione.

Se si desidera scrivere una procedura di installazione personalizzata, esiste comunque la possibilità di usare utilità di creazione immagini di terze parti anche tramite WDS. Sebbene il formato WIM e ImageX siano in grado di rispondere alle esigenze della maggior parte degli scenari di distribuzione, determinati requisiti possono essere soddisfatti dallo strumento di creazione immagini esistente dell'utente.

Analogamente, alcuni scenari potrebbero richiedere un partizionamento personalizzato, ad esempio nel caso in cui gli utenti distribuiscano Windows Vista con BitLocker oppure creino sistemi Windows XP memorizzando i dati dei profili su un secondo volume o ancora qualora distribuiscano un sistema Windows Server e desiderino creare un volume separato sullo stesso disco per l'accesso. Tutti i casi citati richiedono l'automazione di DiskPart che, come nelle versioni precedenti, può essere eseguita inserendo uno script (qualsiasi formato di file) che contiene il comando da eseguire e che si conclude con exit, per terminare DiskPart.

Creare la propria procedura di installazione non è un compito semplice, poiché occorre in pratica ricostruire il file eseguibile di installazione (o per lo meno eseguire il mirroring delle relative funzionalità) e gli elementi da progettare e realizzare sono molti. Tuttavia, occorre considerare la quantità di funzionalità predefinite da inserire e gli strumenti utilizzati (HTA, WSH o un linguaggio di programmazione compilato).

Server di trasporto

Il server di trasporto può soddisfare le esigenze degli utenti che non utilizzano la maggior parte delle funzionalità integrate di WDS (ad esempio, Active Directory) o che stanno progettando una soluzione personalizzata completa, senza requisiti indesiderati. La tabella nella Figura 2 (tratta dall'articolo sull'utilizzo del server di trasporto all'indirizzo go.microsoft.com/fwlink/?LinkID=115298) descrive gli elementi inclusi nel ruolo del server di trasporto WDS.

Figura 2 Server di distribuzione e server di trasporto a confronto

Quando affermo che il server di trasporto è un elemento di difficile implementazione, non mi riferisco al ruolo in sé, che, naturalmente, è semplice da distribuire (vedere Figura 3). Mi riferisco piuttosto all'implementazione dell'installazione personalizzata del server di trasporto, che richiede maggiore impegno. L'utilizzo del ruolo del server di trasporto complica l'utilizzo di WDS come ruolo.

Figura 3 Il server di trasporto può essere utile per scenari di distribuzione personalizzata (fare clic sull'immagine per ingrandirla)

Multicast personalizzato

Che si utilizzi o meno il ruolo del server di trasporto, ma in particolare se viene utilizzato, quando si effettuano distribuzioni a più sistemi risulta utile l'uso del multicast. ADS disponeva di una funzionalità multicast molto efficace, che è possibile duplicare utilizzando WDS con multicast. WDS dispone di un proprio multicast, ma se si intende realizzare una soluzione personalizzata, è possibile sfruttare il multicast utilizzando WDSMCast, come illustrato lo scorso mese (vedere la Figura 4). È bene ricordare che occorre trasferire i file di immagini da distribuire, che devono quindi essere applicati. In generale, è necessaria una quantità sufficiente di spazio sul disco locale affinché l'immagine venga memorizzata e quindi applicata.

Figura 4 Esecuzione di WDSMCast (fare clic sull'immagine per ingrandirla)

Conclusioni

WDS è di per sé un servizio piuttosto efficace ed è probabile che sia sufficiente a soddisfare le esigenze della maggior parte delle aziende. Tuttavia, è possibile realizzare una soluzione personalizzata che superi i confini di WDS: l'unico limite è rappresentato dalla propria immaginazione, dalle proprie competenze e dal tempo a disposizione.

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