Desktop FileAggiornamento di Servizi di distribuzione Windows

Wes Miller

In molti dei miei articoli più recenti ho illustrato le tecnologie di distribuzione correlate a Windows Vista e alla prossima versione di Windows Server, nome in codice "Longhorn". L'unica costante nell'ambito dello sviluppo del software è il cambiamento e pertanto in questo articolo vi presento un piccolo aggiornamento relativo a Servizi di distribuzione Windows (WDS, Windows Deployment Services), che verrà fornito in

Windows Server® "Longhorn". Avendo inoltre raccolto una serie di domande, alcune delle quali poste dai lettori, altre estratte da discussioni a cui ho partecipato negli ultimi mesi, una parte del presente articolo è dedicata alle risposte ad alcune di queste domande relative a ImageX, WDS e Windows® PE.

Nuove funzionalità e miglioramenti

Durante la fase di pianificazione della progettazione di WDS, si sperava che la funzionalità fornita come componente aggiuntivo a Windows Server 2003 sarebbe stata quasi identica alla funzionalità della versione che verrà fornita successivamente in Windows Server "Longhorn". Tuttavia, il team responsabile dello sviluppo di WDS per Windows Server "Longhorn" si è concentrato principalmente su tre nuove funzionalità principali che saranno specifiche di WDS sulla piattaforma server disponibile a breve.

Tra queste nuove funzionalità figurano la distribuzione multicast, il miglioramento delle prestazioni di download TFTP e il supporto per l'avvio di rete basato su EFI (Extensible Firmware Interface) per i sistemi x64. Queste funzionalità sono molto importanti ed estremamente vantaggiose per gli utenti e gli amministratori di WDS e pertanto in questo articolo verrà esaminata ciascuna di esse in modo da fornire una panoramica delle novità che sono state introdotte. È opportuno tuttavia sottolineare prima una precisazione importante: non si prevede di includere queste funzionalità in nessuna delle future versioni di WDS per Windows Server 2003.

Multicast

Molto tempo prima che iniziassi a collaborare con il team di Windows, il supporto multicast era una delle funzionalità maggiormente trattate e richieste per Servizi di installazione remota (RIS, Remote Installation Services) oltre che per la distribuzione di Windows in generale. I clienti che avevano utilizzato tecnologie di distribuzione di terze parti erano consapevoli delle potenzialità della distribuzione multicast. Alcune tecnologie di distribuzione specifiche per gli scenari all'interno di Microsoft, in particolare Servizi di distribuzione automatica (ADS, Automated Deployment Services), hanno implementato il multicast, ma nessuna di esse supporta l'utilizzo di questa tecnica per la distribuzione OEM e aziendale e pertanto è rimasta solo una funzionalità molto richiesta, in particolare dai clienti OEM e aziendali.

Il vantaggio principale del multicast è quello di consentire a più computer simultaneamente di ricevere una comunicazione, ovvero le informazioni inviate dal mittente (in questo caso il server WDS) vengono comunicate una sola volta. Ogni client deve quindi ascoltare l'intera comunicazione per poterla ricevere. Poiché tutti i client sono simultaneamente in ascolto di un unico indirizzo di rete, il vantaggio è duplice: miglioramento della velocità di distribuzione poiché la rete è meno congestionata con più client che eseguono la stessa attività e riduzione della saturazione di rete in quanto ogni client è in ascolto di un singolo flusso.

Lo svantaggio del multicast è da sempre stato rappresentato dall'infrastruttura stessa del multicast. Tutti conoscono il "gioco del telefono senza fili". I passaggi sono molto semplici:

1. Uno dei giocatori inizia il gioco bisbigliando una frase all'orecchio del suo vicino.
2. Questi ascolta la frase
3. e la ripete al prossimo giocatore.
4. Il ciclo continua fino all'ultima persona che partecipa al gioco.

Il problema intrinseco del multicast è rappresentato dal fatto che, per poter dire a quattro persone l'intera frase, è necessario che tutti e quattro siano presenti nella stanza e siano contemporaneamente in ascolto. Se una quinta persona entra nella stanza, a meno che non sappia di dover mettersi immediatamente in ascolto, sarà necessario ripetere l'intera frase anche a quest'ultima persona.

Il multicast funziona in modo molto simile. Si invia un'immagine binaria (in genere un'immagine disco basata su settore) via cavo. Tutti i client che necessitano di ricevere questa immagine, se non sono ancora pronti quando l'immagine viene trasmessa per la prima volta, devono in genere attendere in una coda. L'aspetto più fastidioso tuttavia è rappresentato dal fatto che, se i client perdono una quantità eccessiva di dati a causa dei problemi o delle prestazioni della rete, dovranno abbandonare interamente la coda di comunicazione (in quanto non sono in grado di assicurare di aver ricevuto l'intera immagine disco) o l'intero gruppo deve rallentare per soddisfare le esigenze del client in cui si sono verificati dei problemi. In uno scenario che prevede la distribuzione di centinaia di sistemi contemporaneamente, assicurare che tutti i client vengano avviati contemporaneamente e che i problemi di velocità di un client non abbiano alcun impatto sugli altri è un aspetto su cui deve essere concentrata maggiormente l'attenzione durante la progettazione di un sistema multicast.

Il team WDS ha introdotto significativi cambiamenti a questo proposito rilasciando un nuovo motore multicast che sfrutta l'infrastruttura del formato Windows Imaging (WIM) basata su file per rendere disponibili alcune funzionalità con caratteristiche esclusive. È possibile eseguire gli stessi scenari multicast gestiti temporaneamente supportati dalla maggior parte del software multicast di terze parti, ma la soluzione multicast per WDS offre molte altre funzionalità.

Innanzitutto, i computer client possono partecipare in qualsiasi momento al processo di trasferimento. La trasmissione multicast è una trasmissione di flussi di file basata su un approccio di tipo "round robin" che continua fino a quando non vengono soddisfate le richieste di ogni computer client. Per questo motivo, non è importante sapere quando i client si connettono. I client rimangono in ascolto del server WDS e, quando il server ha completato la trasmissione del file immagine, ricomincia dall'inizio. Se un client perde un file, rimane semplicemente in ascolto finché il file non viene recuperato (si pensi a dei cavalli su una giostra).

Secondo, il protocollo è completamente nuovo e dispone del controllo della congestione e del flusso, il che indica che funziona in modo corretto sulle reti di produzione senza interferire con le comunicazioni di rete esistenti. Un timore comune degli amministratori di rete, giustificato da alcune soluzioni multicast, è rappresentato dal fatto che l'attivazione di tali soluzioni determina in genere la saturazione della rete quando invece, ironicamente, lo scopo è quello di rendere più efficiente la comunicazione.

Terzo, la soluzione è stata progettata in modo da essere indipendente da WDS e da Active Directory®. Ne consegue che, per sfruttare i vantaggi di questa soluzione, non è necessario disporre di Active Directory o di un'implementazione attiva di WDS. Il multicast ImageX può essere eseguito in modo indipendente in quanto si presta a numerosi scenari. Il client multicast è un'applicazione da riga di comando che può eseguita su "Windows Server "Longhorn" (e la versione associata di Windows PE), Windows Vista™, Windows XP Service Pack 2 (SP2) o il sistema operativo Windows Server 2003 SP2 recentemente rilasciato.

Sono disponibili nuove attività di gestione nella console MMC di WDS e nell'applicazione WDSUtil per l'impostazione e la configurazione del multicast. È stata inoltre introdotta una modifica nell'interfaccia utente del client WDS che indica che il multicast è in uso.

Gli strumenti di gestione WDS consentono agli amministratori di monitorare lo stato di avanzamento della trasmissione in tempo reale verso i client (inclusa la rimozione dei client da una trasmissione). Gli strumenti di gestione offrono inoltre funzionalità complete di registrazione e generazione di report. Ne consegue che ora gli amministratori hanno a disposizione un metodo per registrare le installazioni, una funzionalità che sfortunatamente non era inclusa in RIS.

Il multicast in WDS per Windows Server "Longhorn" è uno degli annunci più interessanti finora pubblicati. È straordinario sapere che il team è stato in grado di venire incontro a questa esigenza molto richiesta dai clienti sviluppando una soluzione che dovrebbe soddisfare in modo efficiente anche le necessità dei clienti OEM e aziendali.

Prestazioni di download TFTP migliorate

Il protocollo TFTP (Trivial File Transfer Protocol) è un componente chiave della tecnologia Preboot eXecution Environment (PXE), che è a sua volta la struttura portante di RIS prima e di WDS ora. La scelta del protocollo TFTP non è stata determinata dalla sua efficienza di rete o dalla sua affidabilità, ma si è basata principalmente sul fatto che questo protocollo presenta dimensioni notevolmente ridotte (essendo senza stato, non protetto e basato su UDP) e si presta all'incapsulamento in una ROM di avvio, necessaria per l'avvio PXE dei sistemi dalla rete.

Per Windows Server "Longhorn," il protocollo TFTP Daemon (TFTPD) è stato completamente riscritto in modo da rendere possibile l'introduzione di significativi miglioramenti nei tempi di download TFTP (un importante miglioramento introdotto attualmente riguarda il fatto che l'intero processo di distribuzione di WDS è basato sull'avvio Windows PE dall'immagine RAM). Questa è senza dubbio una buona notizia per i clienti che hanno sempre desiderato un incremento delle prestazioni durante il download di Windows PE da RIS o WDS su Windows Server 2003.

Man mano che il mondo dei computer inizia ad allontanarsi dall'onnipresente BIOS (attualmente la struttura principale dei computer x86) per implementare la tecnologia EFI, Microsoft ha configurato WDS in modo da poter funzionare correttamente con i nuovi sistemi server x64 attualmente disponibili che vengono avviati tramite EFI, piuttosto che mediante il BIOS. La funzionalità inclusa consentirà l'avvio PXE dei sistemi client x64 da un server WDS.

Domande

Con l'aggiornamento di WDS a disposizione, ho deciso di dedicare la parte rimanente del presente articolo alle risposte ad alcune domande che ho ricevuto tramite messaggi di e-mail o che mi sono state rivolte nelle recenti discussioni online e che ritengo potrebbero essere di interesse generale per i miei lettori.

D È possibile utilizzare WDS in un ambiente non basato su DHCP? La mia rete non consente il traffico DHCP o PXE.

R Sì, è possibile utilizzare WDS in un ambiente non basato su DHCP, ma la soluzione non garantisce caratteristiche di scalabilità in quanto è necessario creare supporti CD univoci per ogni installazione che si intende supportare, ciascuno con il proprio indirizzo IP univoco. Probabilmente è più opportuno utilizzare supporti DVD per l'installazione. Se occorre eseguire l'installazione tramite WDS senza DHCP, attenersi alla procedura riportata di seguito.

1. Creare un'immagine di individuazione WDS con un server definito in modo statico (che fa riferimento allo specifico server WDS da cui verrà eseguita l'installazione).
2. Consentire il traffico DHCP attraverso la porta 4011 sul server WDS di destinazione. Anche se non si utilizza DHCP, è necessario consentire il traffico DHCP in quanto in questo modo i client WDS eseguono l'autenticazione handshake nei confronti del server.
3. Creare supporti Windows PE univoci con un indirizzo IP statico anziché DHCP.

Tenere presente che questa soluzione può causare non poche difficoltà in quanto i supporti client devono essere univoci per evitare conflitti tra gli indirizzi IP ed è necessario che l'utente faccia riferimento a uno specifico server WDS sulla rete. Poiché PXE (basato su DHCP) è la struttura portante di WDS, non è difficile comprendere perché WDS funzioni molto meglio se DHCP è supportato nell'ambiente in cui si opera.

D Desidero eseguire l'avvio PXE di Windows PE 2.0 da un server PXE diverso da WDS. Come è possibile eseguire questa operazione?

R L'articolo della Knowledge Base all'indirizzo support.microsoft.com/kb/926172 potrebbe fornire alcune indicazioni su come utilizzare Windows PE 2.0 su un server PXE non WDS. Tenere presente tuttavia che il supporto Microsoft per questo tipo di configurazione è piuttosto limitato.

D Che cos'è BDD? Lo strumento Windows Automated Installation Kit (WAIK) è incluso in BDD?

R BDD (in realtà Business Desktop Deployment Solution Accelerator) è una struttura software che fornisce indicazioni su come utilizzare gli strumenti di distribuzione di Windows, come WAIK, in modo gestibile e riproducibile. Lo strumento WAIK non è incluso direttamente in BDD, ma BDD è in grado di integrare tutti gli strumenti necessari, compreso WAIK, in modo da consentirne l'installazione, se non sono stati già installati. Pertanto, sebbene WAIK non sia tecnicamente incluso in BDD, questa soluzione per poter funzionare richiede l'utilizzo dello strumento WAIK. Per ulteriori informazioni su BDD; visitare il sito Web all'indirizzo microsoft.com/desktopdeployment.

D Dove posso scaricare WDS per il sistema Windows Server 2003 di cui dispongo?

WDS è disponibile per il download come parte di WAIK nella directory WDS (go.microsoft.com/fwlink/?LinkId=85377).

D Come è possibile configurare Windows PE 2.0 per l'avvio con un indirizzo IP statico e il supporto per la configurazione DNS?

R Per configurare un indirizzo IP statico, utilizzare il file di esempio unattend.xml nella Figura 1 e inserirlo nella cartella principale del CD, nell'unità flash USB o in un altro supporto di avvio da cui possa essere prelevato. Se si desidera disporre anche del supporto DNS, sarà necessario eseguire il seguente comando:

Figure 1 Figura 1: unattend.xml

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
 <settings pass="windowsPE">
  <component 
   name="Microsoft-Windows-TCPIP" 
   processorArchitecture="x86" 
   publicKeyToken="31bf3856ad364e35" 
   language="neutral" 
   versionScope="nonSxS" 
   xmlns:wcm="https://schemas.microsoft.com/WMIConfig/2002/State" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <Interfaces>
    <Interface wcm:action="add">
     <Ipv4Settings>
      <DhcpEnabled>false</DhcpEnabled>
     </Ipv4Settings>
     <UnicastIpAddresses>
      <IpAddress wcm:action="add" wcm:keyValue="1">
       192.168.0.1</IpAddress>
     </UnicastIpAddresses>
     <Identifier>Local Area Connection</Identifier>
    </Interface>
   </Interfaces>
  </component>
 </settings>
<cpi:offlineImage 
 cpi:source="wim:c:/simtest/winpe.wim#Microsoft Windows Vista PE (X86)" 
 xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

net start "DNS Client"
netsh interface ipv4 add dnsserver "Local Area Connection" 192.168.2.10 index=1

D È possibile avviare Windows PE da un controller Fibre Channel?

R Sì, purché HBA Fibre Channel supporti la registrazione del volume di avvio tramite Int13 in modo da essere visualizzato nel BIOS come volume di avvio per Windows PE. È necessario inoltre aggiungere il driver del controller Fibre Channel allo stesso modo di qualsiasi altro driver del controller di archiviazione predefinito.

D Windows PE 2.0 viene sempre avviato da un'immagine RAMDisk. Alcuni dei miei sistemi non dispongono di una quantità sufficiente di RAM per eseguire questo tipo di avvio. È possibile avviare Windows PE 2.0 senza un'immagine RAMDisk?

R Sì. I sistemi con meno di 256 MB di RAM in particolare possono richiedere per l'avvio un'implementazione di Windows PE senza RAMDisk. È disponibile un articolo di supporto di Microsoft in cui viene descritto come eseguire questa operazione. È importante sottolineare un paio di aspetti: non si sarà in grado di eseguire lo swapping dei supporti, operazione invece supportata da RAMDisk, e il sistema si avvierà più lentamente rispetto a una versione di Windows PE 2.0 basata su RAMDISK.

D Ho cercato di avviare Windows PE 2004 e Windows PE 2005 (1.5 o 1.6) da supporti diversi da DVD e ho provato a copiare un'immagine (o altri dati) da un DVD. Non intendo eseguire l'avvio dal DVD ma semplicemente copiare i dati dal DVD. Non sono tuttavia in grado di eseguire questa operazione. Il DVD è leggibile con un'installazione completa di Windows, ma se utilizzato in un ambiente Windows PE viene visualizzato un messaggio di errore che indica che il volume è danneggiato o illeggibile. È possibile risolvere questo problema?

R Sì. Per impostazione predefinita, Windows PE 1.x non fornisce il supporto per i supporti in formato UDF. I DVD sono, per definizione, formattati con lo standard ISO Bridge (un formato doppio che prevede la combinazione di ISO e UDF) o semplicemente con UDF. Per consentire il corretto funzionamento del sistema Windows PE installato, è necessario aggiungere all'installazione il driver UDF. Il driver è incluso ma non è installato. Per installarlo, procedere come segue:

1. Nel Blocco note, aprire il file txtsetup.sif nella directory I386 (o MiniNT, in caso di installazione di Windows PE da disco rigido).
2. Individuare la sezione [CdRomDrivers.Load] e cercare la riga con il driver cdfs.sys. Sotto tale riga, aggiungere la riga udfs = udfs.sys. Si dovrebbe ottenere un risultato simile al seguente:

[CdRomDrivers.Load]
cdfs = cdfs.sys
udfs = udfs.sys

3. Individuare la sezione [CdRomDrivers] e cercare la riga contenente cdfs. Sotto tale riga, aggiungere la riga udfs = "Universal Disk File System". Si dovrebbe ottenere un risultato simile al seguente:

[CdRomDrivers]
cdfs = "CD-ROM File System"
udfs = "Universal Disk File System"

4. Salvare e chiudere il file txtsetup.sif e ricreare l'immagine di Windows PE in base alle esigenze. A questo punto dovrebbe essere possibile leggere da Windows PE qualsiasi supporto DVD in formato UDF.

D Dispongo di numerosi sistemi precedenti, su cui viene eseguito Windows XP, che non supportano ACPI. È possibile utilizzare Windows PE 2.0 su questi sistemi in modo da eseguirne la migrazione a Windows Vista o per reinstallare Windows XP?

R No, non è possibile. Windows PE 2.0 supporta solo sistemi compatibili con ACPI (Advanced Configuration and Power Interface) e non può essere avviato su questi sistemi. Se è necessario utilizzare Windows PE su questi sistemi, utilizzare Windows PE 1.6 o versione precedente.

D Ho scritto un'applicazione in Visual Studio® 2005 e vorrei eseguirla su Windows PE (1.x o 2.0). Funzionerà in modo corretto?

R Questo dipende dalla modalità di scrittura dell'applicazione. Se si è utilizzato codice C++ non gestito, l'applicazione dovrebbe funzionare. Se si è utilizzato uno dei linguaggio del codice gestito, ad esempio C# o J#, o qualsiasi codice C++ gestito, l'applicazione non funzionerà. Poiché Microsoft® .NET Framework (qualsiasi versione) non è disponibile in Windows PE, non è possibile eseguire codice gestito.

D Sto tentando di scrivere un'applicazione da utilizzare sul sistema Windows PE 2.0 e ho bisogno di aiuto. Qual è la migliore risorsa in cui ricercare informazioni di supporto?

R È consigliabile iniziare con la Guida per gli sviluppatori di Windows PE.

D Ho avviato Windows PE 2.0 da un CD diverse volte, ma la lettera di unità (RAMDisk) è sempre X. Come è possibile sapere qual è la lettera di unità effettiva da cui si è avviato?

R La lettera di unità da cui Windows PE ha eseguito l'avvio iniziale è riflessa nella seguente chiave del Registro di sistema:

HKEY_LOCAL_MACHINE\SYSTEM\Setup\SystemPartition 

Se si rileva che questa chiave non è stata compilata perché in Windows PE è stata utilizzata una shell di terze parti, eseguendo il comando indicato di seguito sarà possibile aggiornare la chiave con il valore corretto:

start /w wpeinit UpdateBootInfo

D È possibile utilizzare ImageX e i file WIM per eseguire il backup dei miei sistemi?

R Teoricamente è possibile, ma non consigliabile. ImageX, al contrario di un vero strumento di backup, non è in grado di eseguire il backup di file bloccati o aperti. È pertanto consigliabile continuare a utilizzare una vera utilità di backup in grado di assicurare la protezione dei file aperti e bloccati.

D Se si acquisisce un file WIM non compresso, sarà possibile distribuirlo più rapidamente rispetto alla stessa immagine di volume compressa?

R No, non in modo significativo. L'acquisizione richiede più tempo a causa della compressione. Tuttavia, l'applicazione dell'immagine a un sistema di destinazione non richiede tempi significativamente più lunghi, indipendentemente dal tipo di compressione utilizzato (nessun tipo, XPress o LZX). È consigliabile scegliere il tipo di compressione in base alle dimensioni effettive dell'immagine e alla quantità di tempo che è possibile dedicare all'acquisizione.

D Se si intende applicare un'immagine WIM al disco, è necessario eseguirne una nuova partizione e formattarlo?

R Sì. Per ottenere un'immagine pulita di un sistema, è necessario innanzitutto eseguire la pulizia del volume con lo strumento diskpart (o eliminare e creare nuovamente la partizione di destinazione). In alternativa è possibile formattare completamente il volume prima dell'applicazione dell'immagine.

Inoltre, occorre tenere presente che le versioni di Windows precedenti a Windows Vista utilizzavano un settore di avvio differente. Se pertanto si utilizza Windows PE 2.0 per distribuire Windows Server 2003 o versione precedente, è necessario eseguire il comando indicato di seguito dall'interno di Windows PE per impostare il settore di avvio su un settore da cui Windows Server 2003 o versione precedente è in grado di eseguire l'avvio prima di iniziare l'installazione di Windows o applicare un'immagine WIM:

bootsect /nt52 sys C: /force

Conclusioni

Spero che abbiate trovato l'aggiornamento di WDS e le risposte a queste domande utili e interessanti. Ringrazio tutti coloro che mi hanno inviato le domande e prometto di fare del mio meglio per poter fornire una risposta a ciascuna di esse quando possibile in questo articolo. Potete pertanto continuare a inviare eventuali domande all'indirizzo di e-mail elencato nella mia biografia.

Windows Vista Hardware Assessment

Baldwin Ng

Buone notizie: il tuo manager risponde finalmente alla proposta che hai avanzato qualche mese fa. Sembra che stia prendendo seriamente in considerazione l'idea di eseguire l'implementazione di Windows Vista in tutta l'organizzazione e ha iniziato a considerare i vantaggi e il risparmio sui costi associati alla gestione di un singolo sistema operativo. Tuttavia, non è completamente convinto che sia economicamente vantaggioso sostituire tutti i PC per l'installazione di Windows Vista. Desidera pertanto informazioni concrete e dettagliate relativamente ai PC di cui è possibile eseguire la migrazione a Windows Vista immediatamente e ai PC di cui è possibile eseguire la migrazione effettuando un aggiornamento minimo, come l'aggiunta di memoria di sistema e di spazio su disco rigido. E desidera una risposta entro la fine della settimana. È necessario definire innanzitutto un punto di partenza: Come è possibile ottenere la risposta in pochi giorni quando l'organizzazione non dispone di strumenti sofisticati per la gestione delle risorse o della rete? A rendere le cose più complicate è il fatto che il tuo predecessore non ti ha lasciato informazioni sufficienti sulle risorse di rete già esistenti.

Microsoft ha di recente rilasciato Windows Vista Hardware Assessment, un acceleratore di soluzione che consente di determinare se la propria organizzazione è pronta per la migrazione a Windows Vista (microsoft.com/technet/wvha). Questo strumento è in grado di valutare rapidamente i computer in una rete e generare report dettagliati sullo stato di preparazione e sulla compatibilità dei relativi dispositivi e infrastruttura hardware nel giro di poche ore nella maggior parte delle organizzazioni di medie dimensioni, senza installare alcun agente software sui PC della rete.

Basandosi sulle potenti tecnologie di raccolta dell'inventario e di generazione di report precedentemente sviluppate per Microsoft Assessment and Deployment Solution (ADS), Windows Vista Hardware Assessment crea una serie di report sullo stato di preparazione dell'organizzazione tramite un processo in tre fasi:

1. Inventario hardware

Mediante l'uso di Strumentazione gestione Windows (WMI), Active Directory® e altri protocolli di rete di Windows, come NetServerEnum, questo strumento è in grado di rilevare i computer presenti in un dominio e i computer inclusi in un gruppo di lavoro. Una volta completato l'inventario, tutte le informazioni sui dispositivi e sulle risorse di sistema vengono memorizzate nel database SQL Server™ 2005 Express. La versione corrente di questo strumento supporta l'individuazione in rete di un massimo di 5.000 computer. Le versioni future saranno probabilmente in grado di garantire una scalabilità che consente di supportare reti di maggiori dimensioni.

2. Analisi della compatibilità

Utilizzando i database di dispositivi e BIOS più aggiornati del team di Windows, lo strumento analizza lo stato di preparazione di ciascun computer sulla base della compatibilità dell'hardware e dei dispostivi per Windows Vista. Inoltre, le informazioni sui driver vengono prelevate tramite un servizio Web aggiornato periodicamente in modo da ottenere le informazioni più aggiornate ogni volta che lo strumento viene eseguito.

3. Report sullo stato di preparazione

L'ultimo passaggio è la generazione automatica di un set di report sullo stato di preparazione nel formato dei documenti di Microsoft Word e dei fogli di calcolo di Excel ®. Questi report forniscono lo stato di preparazione oltre ai consigli per l'aggiornamento di ciascun computer.

Windows Vista Hardware Assessment integra ogni altro acceleratore di soluzione di Windows Vista, tra cui Business Desktop Deployment 2007 e la Guida alla protezione per Windows Vista. Per ulteriori informazioni, dare un'occhiata alla pagina iniziale degli acceleratori di soluzioni.

Baldwin Ng è Product Manager del team Microsoft responsabile degli acceleratori di soluzioni la cui attività è incentrata sulla creazione di strumenti software automatici che garantiscono un utilizzo più rapido ed efficiente del software Microsoft da parte dei clienti e dei consulenti. È possibile contattarlo all'indirizzo Baldwin.Ng@microsoft.com.

Wes Miller è Development Manager presso Pluck (www.pluck.com) ad Austin, Texas. Wes ha lavorato per Winternals Software ad Austin e in Microsoft come Program Manager e Product Manager di Windows. È possibile contattarlo all'indirizzo technet@getwired.com. Wes ringrazia Scott Dickens, Program Manager per Servizi di distribuzione Windows presso Microsoft, per il contributo che ha apportato alla redazione del presente articolo con la sezione relativa alle nuove funzionalità WDS.

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