 TechNet Magazine March 2008

TechNet Magazine March 2008

Numero speciale: Windows Server 2008: Le novità del kernel di Windows Server 2008

Una descrizione dettagliata delle novità principali del kernel di Windows Server 2008 e dei conseguenti miglioramenti di affidabilità, prestazioni e scalabilità. Ecco come Windows Server 2008 utilizza al meglio i pool di thread, semplifica il ripristino da errori hardware, migliora la virtualizzazione con Hyper-V e altro ancora.

Mark Russinovich Numero speciale Windows Server 2008: Novità in Servizi di dominio Active Directory

Windows Server 2008 introduce alcuni miglioramenti significativi in Servizio di dominio Active Directory. Scopri come i controller di dominio di sola lettura e Windows Server Core siano in grado di migliorare la protezione nell'ambiente in uso, come il nuovo strumento Server Manager e il nuovo meccanismo di backup semplifichino la gestione e come i nuovi strumenti di controllo contribuiscano a garantire la conformità.

Gil Kirkpatrick Numero speciale Windows Server 2008: Introduzione a IIS 7.0

IIS 7.0 include numerose nuove funzionalità, che non è tuttavia possibile illustrare in un solo articolo. La nuova versione si basa sulla robusta progettazione incentrata sulla protezione di IIS 6.0, fornendo miglioramenti che consentono di migliorare notevolmente la gestibilità e l'estendibilità della piattaforma. In questo articolo viene fornita una panoramica di alcune delle modifiche più importante introdotte in IIS 7.0.

Isaac Roybal Numero speciale: Windows Server 2008: Accesso alla rete basato su criteri con Windows Server 2008

Che metodi si utilizzano per garantire l'accesso alla rete agli utenti senza sacrificare la protezione? Le nuove tecnologie di Windows Server 2008, come Windows Firewall con protezione avanzata e Protezione accesso alla rete, consentono di implementare un approccio basato sui criteri per raggiungere questo obiettivo.

Ian Hameroff and Amith Krishnan Numero speciale: Windows Server 2008: Configurazione dei ruoli con Server Manager

Un server DNS non deve essere un server di stampa. Un approccio utilizzato da Windows Server 2008 per migliorare la protezione e la facilità di gestione consiste nel semplificare i ruoli del server per installare facilmente solo gli strumenti e i servizi necessari e nient'altro. Di seguito è riportata un'introduzione all'utilizzo di Server Manager per la configurazione dei ruoli e la semplificazione delle distribuzioni.

Byron Hynes Numero speciale Windows Server 2008: Distribuzione di Windows Server 2008 con System Center

In passato, accadeva generalmente che gli amministratori di server installavano manualmente Windows Server dal CD o dal DVD e impiegavano diverse ore per la configurazione del server. Con il rilascio di System Center Configuration Manager 2007 e il nuovo Microsoft Deployment Toolkit, gli amministratori di server ora possono utilizzare gli stessi strumenti utilizzati per anni dagli amministratori desktop per automatizzare le distribuzioni.

Tim Mintner Numero speciale Windows Server 2008: Controllo e conformità in Windows Server 2008

Il controllo delle modifiche ora rappresenta una responsabilità fondamentale dei reparti IT. Il controllo è infatti essenziale per la comprensione e la gestione di sistemi e dati in un ambiente distribuito. In questo articolo vengono illustrati le problematiche più comuni, gli scenari della conformità e delle normative, alcuni dei concetti alla base del meccanismo di controllo e un sistema per creare una strategia di controllo completa.

Rob Campbell and Joel Yoker Dal redattore: Arriva Windows Server 2008

Joshua Hoffman Lettere: La parola ai lettori

Casella degli strumenti: Nuovi prodotti per professionisti IT

Greg Steen Utilità in primo piano: Windows Server Logo Certification

Per aiutare gli ISV e i clienti a verificare la compatibilità delle applicazioni, Microsoft ha creato il programma "Works with Windows Server 2008" e una serie di strumenti gratuiti per effettuare test, resi disponibili tramite il programma stesso e che consentono di garantire la prevedibilità delle prestazioni di un'applicazione.

Venkat Krishnamachari The Cable Guy: Eseguire la migrazione di Intranet a IPv6 con ISATAP

È ora di prepararsi a passare a IPv6. In The Cable Guy, viene illustrato il possibile utilizzo di una tecnologia di transizione IPv6 per ottenere la connettività IPv6 ed eseguire la migrazione a una Intranet compatibile con IPv6.

Joseph Davies Windows PowerShell: Report di stato

Fornire negli script commenti e suggerimenti sullo stato è un'ottima idea sia per gli utenti con una soglia di attenzione limitata che per quelli più attenti. Ecco tutto ciò che serve sapere per fornire lo stato in Windows PowerShell.

Don Jones Hey, Scripting Guy!: I giochi di Shell preferiti

Gli Scripting Guy illustrano come sia possibile modificare la data dell'ultima modifica di un file con alcuni script e l'oggetto Shell.

The Microsoft Scripting Guys Controllo della protezione: Utilizzo di Configurazione guidata impostazioni di sicurezza in Windows Server 2008

La notizia del nuovo strumento Server Manager di Windows Server 2008 si è già diffusa in tutto il mondo. Ma Configurazione guidata impostazioni di sicurezza è ancora disponibile. Ecco alcuni casi in cui si rende ancora necessario il suo utilizzo.

Jesper M. Johansson Desktop file: Non si è mai troppo ricchi o troppo magri

I thin client vanno e vengono, ma sembra che ci siano sempre scenari in cui possono tornare utili. Oggi, vengono utilizzati nei chioschi multimediali e negli ambienti in cui è sufficiente navigare sul Web. Nel presente articolo viene illustrato come riutilizzare il vecchio hardware con un'applicazione client per risparmiare denaro.

Wes Miller Taccuino: Preparazione di IT 2.0

In questo articolo si discute l'importanza di imparare dal passato per affrontare le sfide che il futuro riserva al settore IT.

Romi Mahajan Windows Confidential: Come le versioni Beta sono diventate RC

Raymond Chen illustra gli intriganti retroscena dei cambiamenti alle convenzioni di denominazione delle versioni non definitive. E lancia un appello alle aziende affinché diano più importanza ai test delle versioni beta.

Raymond Chen


 Numero speciale: Windows Server 2008: Le novit&#224; del kernel di Windows Server 2008
Numero speciale: Windows Server 2008 Mark Russinovich

Le novità del kernel di Windows Server 2008
Panoramica:
  • Gestione della memoria e SMB 2.0
  • Riparazione automatica di NTFS, Windows Hardware Error Architecture e il verificatore driver
  • Scalabilità con le porte di completamento I/O, i pool di thread e NUMA
  • Virtualizzazione Hyper-V

Windows Server 2008 è la versione più recente della piattaforma server di Microsoft e contiene novità a livello di sistema in ogni area funzionale del sistema operativo, dalla gestione della memoria
alla pianificazione dei thread e dalla connessione in rete alla protezione, per citarne solo alcune.
Poiché condivide lo stesso kernel di Windows Vista® SP1, Windows Server® 2008 contiene molti dei miglioramenti che ho già descritto nei miei articoli precedenti di TechNet Magazine: "Il kernel di Windows Vista" parti da 1 a 3 (febbraio, marzo e aprile 2007) e "Controllo dell'account utente di Windows Vista" (giugno 2007). Solo alcune delle funzionalità descritte in quegli articoli sono esclusivamente indirizzate ai client e non presenti in Windows Server 2008, come SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot e il Servizio Utilità di pianificazione classi multimediali (MMCSS).
Piuttosto che ripetere le informazioni sulle novità importanti del kernel di Windows Vista disponibili anche in Windows Server 2008, come la determinazione delle priorità di I/O, la nuova architettura dell'avvio, BitLockerTM, l'integrità del codice e i livelli di integrità obbligatori, qui si preferisce appuntare l'attenzione sulle novità principali non illustrate in quegli articoli, tra cui alcune relative ad affidabilità, prestazioni, scalabilità, oltre alla nuova tecnologia di virtualizzazione hypervisor di Microsoft, Hyper-VTM.
Inoltre, come negli articoli precedenti, l'ambito resta limitato al kernel del sistema operativo, Ntoskrnl.exe, oltre che ai componenti di sistema più strettamente associati. In questo articolo non vengono illustrate, ad esempio, le modifiche apportate all'installazione (WIM o Windows® Imaging Format e il modulo di manutenzione pacchetti basato su componenti), alla gestione (Criteri di gruppo e Active Directory®), alla diagnostica e al monitoraggio in generale (Infrastruttura diagnostica Windows), alle funzionalità fondamentali di connessione in rete (la nuova implementazione di firewall e TCP/IP), ai componenti di base del server o ai ruoli del server.
Utilizzo di sistemi multiprocessore
Una delle novità a basso livello del sistema è che Windows Server 2008 contiene solo una versione del kernel progettato per funzionare con i sistemi multiprocessore. In passato in Windows si utilizzava una versione specifica per i processori singoli sui computer con una sola CPU, perché tale versione era in grado di garantire prestazioni leggermente migliori omettendo il codice di sincronizzazione necessario solo negli ambienti multiprocessore. Con il miglioramento dell'hardware, il vantaggio in termini di prestazioni offerto dalle ottimizzazioni è diventato trascurabile e nella maggior parte dei sistemi server odierni sono presenti più processori. L'implementazione di una versione per processori singoli è divenuta quindi inutile.
Nella Figura 1 sono illustrate le varianti del kernel di Windows Server 2008, dove la versione utilizzata in un sistema dipende da se si utilizza la versione di debug (Verificata) o la versione finale del sistema operativo, se l'installazione è a 32 bit o a 64 bit (Itanium, Intel 64 o AMD64) e, in caso di installazione a 32 bit, se il sistema dispone di più di 4 GB di memoria fisica o supporta Protezione esecuzione programmi. Windows Server 2008 è inoltre l'ultimo sistema operativo Windows Server con una versione a 32 bit.
Figure 1 Varianti del kernel di Windows Server 2008 (Close Figure 1)

Kernel | 32 bit | 64 bit
Multiprocessore | Sì | Sì
Multiprocessore verificato | Sì | Sì
Estensione indirizzo fisico PAE multiprocessore | Sì | No
PAE multiprocessore verificato | Sì | No
Con ogni versione di Windows Server si migliorano le prestazioni negli scenari server principali, come lo scambio di file, l'I/O della rete e la gestione della memoria. Inoltre, in Windows Server 2008 sono disponibili molte modifiche e nuove funzionalità che consentono a Windows di sfruttare le nuove architetture hardware, di adattarsi alle reti a latenza elevata e di rimuovere i colli di bottiglia che limitavano le prestazioni nelle versioni precedenti di Windows. In questa sezione vengono esaminati i miglioramenti apportati al gestore della memoria, il sistema di I/O e l'introduzione di un nuovo file system di rete, SMB 2.0.

Gestione della memoria
Esperimento: visualizzazione dell'I/O di file di grandi dimensioni
Per visualizzare le operazioni di I/O di file di grandi dimensioni in un sistema Windows Server 2008, è possibile utilizzare uno strumento di monitoraggio del file system, come TechNet Sysinternals Process Monitor (technet.microsoft.com/sysinternals/bb896645.aspx).
Esistono vari modi per generare I/O di grandi dimensioni. Se su un secondo sistema è in esecuzione Windows Vista Service Pack 1 o Windows Server 2008, è possibile eseguire Process Monitor sul server e monitorare le operazioni di copia dei file del secondo sistema. In genere è possibile generare anche I/O di file di paging voluminosi, eseguendo un programma a utilizzo intensivo della memoria che provochi la scrittura, da parte del gestore della memoria, di pagine nel file di paging.
Nella Figura A è illustrato Process Monitor dopo l'esecuzione di un programma a utilizzo intensivo della memoria su un sistema Windows XP, con l'opzione Enable Advanced Output attivata nel menu delle opzioni di Process Monitor e un filtro impostato per visualizzare soltanto le operazioni di scrittura nel file di paging, pagefile.sys. Nella colonna dei dettagli è indicato che le scritture sono di 64 KB.
Figura A
Quando si eseguono le stesse operazioni su Windows Server 2008, è probabile che si visualizzi qualcosa di simile a quanto illustrato nella Figura B, con la maggior parte delle scritture prossime a 1 MB.
Figura B

Le prestazioni del gestore della memoria sono state migliorate in Windows Server 2008. Ad esempio, vengono eseguite meno operazioni di I/O su disco, ma di maggiori dimensioni rispetto a Windows Server 2003, durante il recupero dei dati dal file di paging oppure durante gli I/O della lettura in avanti sui file mappati. I file di I/O di maggiori dimensioni sono facilitati dalle modifiche apportate al sistema di I/O, che prevedono la rimozione del limite di 64 KB in vigore fin dalla prima versione di Windows NT®.
Inoltre, è importante sottolineare che le letture dei dati per la lettura in avanti (letture speculative) dai file mappati da Gestione cache in Windows Server 2008 sono, in genere, di dimensioni doppie rispetto a Windows Server 2003 e vengono inserite direttamente nell'elenco di standby (la cache del codice e dei dati del sistema). Questo comportamento si verifica in luogo della richiesta alla Gestione cache della mappatura della memoria virtuale e della lettura dei dati nel working set del sistema (la memoria assegnata al sistema dal gestore della memoria), che potrebbe causare l'inutile eliminazione di altro codice o dati in uso dal working set.
Il gestore della memoria esegue operazioni di I/O di maggiori dimensioni anche durante la scrittura dei dati nel file di paging. Se Windows Server 2003 eseguiva spesso operazioni di scrittura anche minori di 64 KB, il gestore della memoria di Windows Server 2008 esegue in genere scritture di 1 MB.
A parte l'ovvio miglioramento delle prestazioni che si ottiene riducendo il numero di scritture nel file di paging, le maggiori dimensioni contribuiscono anche a ridurre la frammentazione all'interno del file di paging. Si riduce di conseguenza anche il numero di letture e di ricerche sul disco necessarie per leggere più pagine, poiché queste risulteranno più spesso adiacenti.
Il gestore della memoria tenta, inoltre, di scrivere in altre pagine modificate che siano prossime a quella in corso di scrittura nello spazio degli indirizzi del processo e sceglie come destinazione l'area del file di paging in cui già risiedono altre pagine adiacenti. In tal modo si riduce al minimo la frammentazione e si migliorano le prestazioni, perché le pagine potenzialmente da scrivere nel file di paging risultano già scritte. Inoltre, si riduce il numero delle letture nel file di paging necessarie per ottenere un intervallo di pagine di processo adiacenti. Per ulteriori informazioni sull'utilizzo delle dimensioni dell''I/O del gestore della memoria , consultare il riquadro "Esperimento: visualizzazione dell'I/O di file di grandi dimensioni".

SMB 2.0
SMB (Server Message Block) protocollo di file system remoto, anche definito Common Internet File System (CIFS), è stato la base del file serving di Windows fin da quando tale funzionalità è stata introdotta in Windows. Negli ultimi anni le limitazioni di progettazione di SMB hanno causato una riduzione delle prestazioni di Windows in termini di file serving e hanno impedito di sfruttare appieno le nuove funzionalità del file system locale. Le dimensioni massime del buffer che possono essere trasmesse in un singolo messaggio, ad esempio, è di circa 60 KB e SMB 1.0 non era in grado di discernere i collegamenti simbolici sul lato client di NTFS che venivano aggiunti in Windows Vista e Windows Server 2008.
In Windows Vista e Windows Server 2008 è disponibile SMB 2.0, un nuovo protocollo di file serving remoto che Windows utilizza quando sia il client che il server lo supportano. Oltre alla corretta elaborazione dei collegamenti simbolici sul lato client e ad altri miglioramenti di NTFS, SMB 2.0 utilizza la suddivisione in batch per ridurre al minimo il numero di messaggi scambiati tra un client e un server. La suddivisione in batch può comportare un aumento della velocità di trasmissione sulle reti a latenza elevata, come le WAN, perché consente di trasmettere più dati allo stesso tempo.
SMB 1.0 inviava l'I/O per un singolo file in modo sequenziale, mentre in SMB 2.0 è implementato il pipelining dell'I/O, che consente di inviare più I/O contemporanei per lo stesso file. Viene inoltre misurata la quantità di memoria del server utilizzata da un client per gli I/O in corso, al fine di determinare la profondità del pipelining.
Grazie alle modifiche apportate al gestore della memoria di I/O di Windows e al sistema di I/O, all'auto tuning della finestra di ricezione TCP/IP e ai miglioramenti del motore di copia dei file, SMB 2.0 rende possibile un aumento significativo della velocità effettiva e la riduzione dei tempi di copia dei file per i trasferimenti di grandi dimensioni. Poiché SMB 2.0 è implementato in entrambi i sistemi operativi, la distribuzione di file server Windows Server 2008 con client Windows Vista consente di utilizzare SMB 2.0 e di ottenere questi vantaggi in termini di prestazioni.

Affidabilità con la riparazione automatica di NTFS
L'affidabilità è un attributo chiave per i server e in Windows Server 2008 sono disponibili alcune funzionalità avanzate che consentono agli amministratori di configurare server che funzionano senza problemi. Alcune di tali funzionalità sono la correzione in linea della coerenza NTFS, una nuova infrastruttura di segnalazione degli errori hardware e le estensioni di Driver Verifier.
Con i dispositivi di archiviazione di più terabyte di oggi, una verifica della coerenza non in linea su un volume può risultare in un'interruzione del servizio di alcune ore. Riconoscendo che molti danneggiamenti del disco sono localizzati in un singolo file o porzione dei metadati, in Windows Server 2008 è implementata una funzionalità di riparazione automatica di NTFS che consente di riparare il danno con il volume in linea.
Quando rileva un danneggiamento, NTFS impedisce l'accesso ai file danneggiati e crea un thread di lavoro di sistema che esegue le correzioni di tipo Chkdsk sulle strutture di dati danneggiate, consentendo l'accesso ai file riparati non appena possibile. L'accesso agli altri file è garantito senza interruzioni durante questa operazione, riducendo al minimo l'interruzione del servizio.

Infrastruttura WHEA
L'infrastruttura WHEA disponibile in Windows Server 2008 promette di semplificare la gestione degli errori hardware e consente di rispondere in modo proattivo agli errori non irreversibili. I server devono spesso rispondere a precise garanzie in termini di tempo di attività, quindi l'individuazione e risoluzione degli errori in tali sistemi è di importanza fondamentale.
Le analisi degli arresti anomali giunte in Microsoft tramite OCA illustra che circa il 10% degli arresti anomali del sistema operativo sono dovuti a un errore hardware, ma l'individuazione della causa principale degli arresti è stata difficile o impossibile, perché in occasione di un arresto anomalo le informazioni sugli errori fornite dall'hardware sono insufficienti. Inoltre, prima di Windows Server 2008, Windows non forniva alcun supporto incorporato per il monitoraggio dell'integrità dei dispositivi né prevedeva funzionalità di ripristino o notifica di errore imminente. Il motivo di fondo è che i dispositivi hardware non utilizzano un formato di errore comune e non forniscono alcun supporto per il software di gestione degli errori.
WHEA costituisce un meccanismo unificato per il rilevamento e la segnalazione dell'origine dell'errore per i dispositivi della piattaforma, compresi processori, memoria, cache e bus come PCI e PCI Express. Il risultato viene ottenuto implementando l'architettura illustrata nella Figura 2, il cui nucleo è un'API del kernel che le origini degli errori chiamano per segnalare gli errori. L'API richiede una formattazione comune per tutti gli errori e registra gli errori utilizzando gli eventi di Analisi eventi per Windows (ETW) (gli errori irreversibili vengono registrati dopo il riavvio).
Figura 2 Infrastruttura di segnalazione degli errori WHEA
Figura 2 Infrastruttura di segnalazione degli errori WHEA
ETW è stato introdotto con Windows 2000 e l'uso che WHEA fa di ETW facilita ai produttori di hardware e di software lo sviluppo di applicazioni di gestione della diagnostica dei dispositivi che utilizzano gli eventi di WHEA. Se un evento è abbastanza grave da provocare un arresto anomalo del sistema, WHEA fa in modo che il record dell'arresto anomalo venga memorizzato nel file dei dettagli dell'arresto anomalo, in modo che gli amministratori possano determinare la causa principale dell'arresto anomalo.
Un'altra parte fondamentale di WHEA è Driver errori hardware specifici di piattaforma (PSHED) in %Systemroot%\System32\Pshed.dll. Il kernel si collega a PSHED, che si interfaccia con l'hardware di piattaforma e firmware, agendo essenzialmente da livello di traduzione tra le rispettive notifiche di errore e l'API di segnalazione degli errori di WHEA. Esiste uno PSHED di Microsoft per ciascuna architettura di piattaforma (x86, x64, Itanium) e PSHED espone un modello di plug-in, in modo che i produttori e fornitori di hardware possano sostituire i comportamenti predefiniti con quelli specifici per le proprie piattaforme.
Infine, i componenti del sistema che si interfacciano con le altre origini di errore (tra cui i driver dei dispositivi, l'Hardware Abstraction Layer e il kernel) possono implementare i gestori degli errori hardware a basso livello (LLHEL) che gestiscono inizialmente una condizione di errore. Un compito dei LLHEL consiste nell'estrarre le informazioni sull'errore dal dispositivo, notificare a PSHED che è necessario consentire la raccolta di ulteriori informazioni di errore della piattaforma e chiamare quindi l'API di segnalazione degli errori WHEA del kernel.

Driver Verifier
Driver Verifier, un potente strumento per monitorare i driver dei dispositivi con problemi e l'hardware difettoso, è stato inserito in ogni copia di Windows, fin da Windows 2000. Gli amministratori in genere configurano Driver Verifier (%Systemroot%\System32\Verifier.exe) in modo da controllare attentamente il comportamento dei driver dei dispositivi sospettati di provocare arresti anomali del sistema. Driver Verifier rileva le operazioni non valide dei driver, in modo che un file dei dettagli dell'arresto anomalo punti direttamente alla parte responsabile dell'errore.
Uno svantaggio delle implementazioni di Driver Verifier precedenti era la necessità di riavviare il sistema per la maggior parte delle modifiche di configurazione, un'operazione ovviamente poco indicata per i server di produzione. Con l'implementazione di Driver Verifier di Windows Server 2008 il processo è stato migliorato, eliminando la necessità di riavviare il sistema per le verifiche più utili, in modo da consentire la risoluzione dei problemi di un server senza doverlo riavviare.
Inoltre, con Driver Verifier vengono introdotte tre verifiche nuove, visibili nella Figura 3. Le verifiche di protezione garantiscono che i driver dei dispositivi impostino autorizzazioni protette sugli oggetti utilizzati per interfacciarsi con le applicazioni. La forzatura delle richieste di I/O in sospeso sottopone a test la flessibilità di un driver nelle operazioni di I/O asincrone che vengono completate immediatamente invece che dopo un ritardo. Le altre verifiche varie ricercano i driver che liberano erroneamente delle risorse in uso, utilizzano in modo non corretto le API di registrazione di Strumentazione gestione windows (WMI) e perdono gli handle delle risorse.
Figura 3 Driver Verifier con le opzioni di Windows Server 2008 attivate
Figura 3 Driver Verifier con le opzioni di Windows Server 2008 attivate

Scalabilità
Per scalabilità si intende la capacità di un sistema operativo o di un'applicazione di utilizzare in modo efficace più processori e grandi quantità di memoria. In ogni nuova versione di Windows la scalabilità viene migliorata riducendo al minimo o eliminando l'uso di blocchi che riducono il parallelismo sui multiprocessori e Windows Server 2008 non fa eccezione a questa regola.
Un miglioramento relativamente piccolo, ma significativo, è nel codice che esegue la scadenza del timer, che non acquisisce più il blocco del dispatcher, un blocco della pianificazione in tutto il sistema utilizzato da tutte le operazioni di sincronizzazione a basso livello. La riduzione che ne risulta nell'overhead di sincronizzazione della CPU, consente ai sistemi di terminal server di Windows Server 2008 di supportare circa il 30% in più di utenti contemporanei rispetto a Windows Server 2003.
Le altre novità nella scalabilità di Windows Server 2008 comprendono i miglioramenti della porta di completamento, una nuova implementazione del pool di thread, l'utilizzo più efficiente dell'hardware NUMA (Non-Uniform Memory Access) e il partizionamento dinamico del sistema.

Miglioramento nella gestione della porta di completamento I/O
La maggior parte delle applicazioni server di Windows scalabili, tra cui IIS, SQL Server® ed Exchange Server, si basano su un'API di sincronizzazione di Windows denominata porta di completamento per ridurre al minimo le commutazioni tra più thread di esecuzione durante le operazioni di I/O. A tal fine vengono prima associate le notifiche degli arrivi di nuove richieste, come le connessioni tra client e server sul Web, a una porta di completamento e viene quindi dedicato un pool di thread all'attesa delle notifiche. Quando arriva una richiesta, Windows pianifica un thread, che di solito esegue quindi altre operazioni di I/O, come la lettura di una pagina Web da disco e l'invio della pagina al client per completare la richiesta.
Perché lo stesso thread possa tornare appena possibile ad attendere altre richieste dei client, il thread invia gli I/O in modo asincrono e associa i completamenti di I/O alla porta di completamento. Il thread torna quindi in attesa sulla porta di completamento, che pianificherà il thread non appena arriva una nuova richiesta o viene completato uno degli I/O. In questo modo lo stesso thread resta attivo su una CPU, elaborando le richieste dei client o restando in attesa sulla porta di completamento.
Uno svantaggio dell'implementazione della porta di completamento nelle versioni precedenti di Windows consisteva nel fatto che, al termine di un'operazione di I/O, il sistema di I/O attivava il thread che aveva emesso l'I/O in modo che eseguisse subito una piccola parte dell'elaborazione di completamento, indipendentemente dalle operazioni in corso. Se erano attivi altri thread, capitava spesso che l'utilità di pianificazione annullasse un thread attivo e il contesto venisse commutato all'emittente.
Windows Server 2008 evita queste commutazioni di contesto differendo l'elaborazione del completamento al thread successivo, in attesa della porta di completamento a cui l'I/O è associato. Così, anche se è presente un altro thread in attesa sulla porta di completamento, l'elaborazione del completamento viene eseguito prima dell'altro codice e l'unità di pianificazione non deve commutare al thread emittente. Questa riduzione delle commutazioni di contesto può comportare un netto miglioramento della scalabilità di applicazioni server con grandi carichi di lavoro.

Pool di thread più efficienti
La scrittura di applicazioni in grado di sfruttare i vantaggi offerti dalle CPU multiple può risultare complessa, quindi con Windows XP sono stati introdotti i pool di thread di lavoro, un'infrastruttura con API associata che astrae i dettagli dell'esecuzione di piccole unità di lavoro tra le CPU. Un'applicazione specifica gli elementi di lavoro all'API del pool di thread, che quindi li esegue su uno dei vari thread che crea e gestisce per ciascuna CPU del sistema.
Lo scopo del pool di thread consiste nel ridurre al minimo le commutazioni di contesto, utilizzando gli stessi thread per eseguire più elementi di lavoro in successione. Quando questo non è possibile perché uno dei thread è già occupato nell'esecuzione di altro lavoro, l'elemento di lavoro viene eseguito utilizzando un altro thread su una diversa CPU.
L'implementazione del pool di thread di Windows Server 2008 prevede un migliore utilizzo delle CPU, indirettamente perché si avvantaggia dei miglioramenti apportati alla porta di completamento e direttamente grazie all'ottimizzazione della gestione dei thread, in modo che i thread di lavoro vengano dinamicamente utilizzati quando necessario per gestire un carico di lavoro dell'applicazione. Inoltre, il nucleo dell'infrastruttura è passato alla modalità kernel, riducendo al minimo il numero di chiamate di sistema eseguite dalle applicazioni che utilizzano l'API. Infine, la nuova API semplifica l'esecuzione di determinate operazioni da parte delle applicazioni, come l'interruzione della coda delle unità lavoro durante l'arresto dell'applicazione.

Ottimizzazioni di NUMA
Con Windows Server 2003 sono state introdotte le ottimizzazioni per i dispositivi NUMA nell'utilità di pianificazione dei thread e nel gestore della memoria, ma in Windows Server 2008 sono state aggiunte ottimizzazioni NUMA al gestore dell'I/O e sono state estese le ottimizzazioni NUMA del gestore della memoria.
I sistemi NUMA sono in genere dei sistemi multiprocessore in cui la memoria ha latenze diverse in funzione del processore che vi accede (vedere la Figura 4). La memoria viene divisa in nodi, dove le latenze tra CPU e nodi possono variare e ciascuna CPU è considerata come parte di un nodo a cui ha l'accesso più rapido.
Figura 4 Sistema NUMA di esempio
Figura 4 Sistema NUMA di esempio
I sistemi NUMA, soprattutto quelli con più di otto CPU, sono spesso più efficienti in termini di costi e prestazioni dei sistemi ad accesso uniforme alla memoria. Mentre un sistema ad accesso uniforme alla memoria deve rendere la memoria ugualmente disponibile a tutte le CPU, un sistema NUMA può implementare interconnessioni ad alta velocità per la memoria direttamente connessa a una CPU e connessioni a latenza elevata più economiche per CPU e memoria più distanti.
Per scalare in modo efficace su un sistema NUMA, un sistema operativo o un'applicazione deve essere in grado di riconoscere la topologia a nodi, in modo che i calcoli vengano eseguiti vicino alla memoria che contiene i dati e il codice necessari per i calcoli. L'utilità di pianificazione di Windows, ad esempio, assegna a ciascun thread un cosiddetto processore ideale, che corrisponde alla CPU su cui l'utilità di pianificazione tenterà sempre di eseguire il thread. In questo modo diventa più probabile che i dati inseriti dal thread nella cache della CPU restino disponibili per il thread a ogni successiva esecuzione.
In Windows Server 2003 l'utilità di pianificazione espande questo concetto, considerando il nodo che contiene il processore ideale come il nodo ideale del thread e, quando il processore ideale è occupato nell'esecuzione di un altro thread, si tenta di pianificare il thread su un'altra CPU nel nodo ideale. Il gestore della memoria di Windows Server 2003 è quindi diventato compatibile con NUMA e, quando possibile, indirizza le allocazioni di memoria di un thread alla memoria del nodo su cui è in esecuzione il thread.
In Windows Server 2008 il gestore della memoria suddivide i buffer di memoria non di paging del kernel (la memoria utilizzata dal kernel e dai driver dei dispositivi per memorizzare i dati che devono restare nella RAM) tra i nodi, in modo che le allocazioni provengano dalla memoria del nodo in cui ha origine l'allocazione. Le voci della tabella della pagina di sistema (PTE) vengono allocate dal nodo da cui ha origine l'allocazione, se l'allocazione richiede una nuova pagina della tabella delle pagine, invece che da un nodo qualunque, come accade in Windows Server 2003.
In Windows Server 2003 quando un thread eseguiva un'allocazione di memoria, il gestore della memoria preferiva il nodo su cui era in esecuzione il thread al momento dell'allocazione. Se il thread era momentaneamente pianificato su un nodo non ideale, qualsiasi allocazione eseguita durante tale periodo proveniva dal nodo non ideale. Ne conseguiva che, quando veniva alla fine eseguito sul nodo ideale, il thread non risultava vicino come previsto ai dati o al codice memorizzato nella memoria allocata.
Per risolvere questo problema, il gestore della memoria di Windows Server 2008 preferisce il nodo ideale di un thread per tutte le allocazioni del thread, anche quando il thread viene eseguito vicino a un altro nodo. Il gestore della memoria rileva automaticamente le latenze tra processori e nodi, in modo che, se sul nodo ideale non è disponibile memoria, venga controllato il nodo più prossimo al nodo ideale. Inoltre, quando un thread fa riferimento al codice o ai dati, il gestore della memoria esegue la migrazione delle pagine presenti nell'elenco di standby verso un nodo ideale del thread.
Le applicazioni che intendono controllare il posizionamento delle proprie allocazioni possono utilizzare le nuove API di memoria NUMA, che consentono di specificare un nodo preferito per le allocazioni di memoria, le viste del mapping del file e gli oggetti del mapping del file. Per un'allocazione correlata al mapping di un file, il gestore della memoria verifica se l'operazione di mapping specifica un nodo, quindi verifica se l'oggetto del mapping del file ne specifica uno e infine, se non ne è specificato alcuno, ricorre al nodo ideale del thread.
Prima di Windows Server 2008, l'interrupt e la chiamata della procedura differita (DPC) associata per un'archiviazione o l'I/O di rete poteva essere eseguita su qualunque CPU, comprese quelle di un nodo diverso dal nodo di origine dell'I/O, causando potenzialmente la lettura o scrittura dei dati durante l'operazione di I/O nella memoria di un nodo diverso da quello di accesso ai dati.
Per evitare questo problema, il sistema di I/O di Windows Server 2008 indirizza l'esecuzione della DPC a una CPU del nodo che ha avviato l'I/O e i sistemi con dispositivi che supportano il bus PCI MSI-X (un'estensione dello standard MSI) possono ulteriormente localizzare il completamento dell'I/O, utilizzando i driver dei dispositivi che sfruttano le API di Windows Server 2008 per indirizzare un interrupt dell'I/O al processore che l'ha avviato.

Partizionamento dinamico
Uno dei modi per rendere un sistema più scalabile è fare in modo che supporti l'aggiunta dinamica di risorse hardware come CPU e memoria. Questo stesso supporto può anche far aumentare la disponibilità del sistema quando è necessario sostituire tali risorse, poiché non è più necessario riavviare il sistema.
Windows Server 2003 consentiva l'aggiunta di memoria a caldo, in modo che i server che supportavano la memoria dinamica potessero utilizzare la RAM aggiunta dall'amministratore. Windows Server 2008 estende il supporto della memoria dinamica consentendo la sostituzione della memoria.
La RAM che diventa più dipendente dalle correzioni ECC è a rischio di errore o blocco completo, quindi su un server che supporta la sostituzione a caldo, Windows Server 2008 è in grado di eseguire in modo trasparente la migrazione dei dati dai banchi di memoria con errori a quelli sostitutivi. Il risultato si ottiene eseguendo prima la migrazione dei dati che sono sotto il controllo del sistema operativo, arrestando quindi effettivamente i dispositivi hardware in uno stato di alimentazione ridotta, eseguendo la migrazione del resto dei dati della memoria e, infine, rialimentando i dispositivi in modo da riprendere il normale funzionamento.
Windows Server 2008 inoltre supporta l'aggiunta e la sostituzione a caldo dei processori. Per consentire una sostituzione a caldo, l'hardware deve supportare il concetto di CPU di riserva, che può essere sia portata in linea o aggiunta dinamicamente quando una CPU esistente genera indicazioni di errore, una funzionalità attualmente disponibile solo nei sistemi di fascia alta. L'utilità di pianificazione di Windows Server 2008 rallenta l'attività sulla CPU che genera indicazioni di errore ed esegue la migrazione alla CPU sostitutiva. A questo punto è possibile rimuovere la CPU con problemi e sostituirla con una nuova CPU di riserva.
Il supporto di Windows Server 2008 per l'aggiunta di processori a caldo consente a un amministratore di aumentare la potenza di elaborazione del server senza tempi di inattività. Tuttavia, l'utilità di pianificazione e i sistemi di I/O rendono disponibile una nuova CPU solo ai driver dei dispositivi e alle applicazioni che richiedono la notifica di arrivo della CPU tramite le nuove API, perché alcune applicazioni partono dal presupposto che il numero di CPU resta fisso per una sessione di avvio. Un'applicazione può, ad esempio, allocare una serie di code di lavoro che corrispondano a ciascuna CPU, dove un thread utilizza la coda associata alla CPU su cui è in esecuzione. Se l'utilità di pianificazione posizionasse uno dei thread dell'applicazione su una nuova CPU, tenterebbe di fare riferimento a una coda inesistente, danneggiando potenzialmente i dati dell'applicazione e bloccando con ogni probabilità l'applicazione.
Le applicazioni Microsoft basate su server, come SQL Server ed Exchange Server, supportano l'aggiunta di CPU, come molti altri processi core di Windows, tra cui il processo di sistema, il processo di gestione della sessione (%SystemRoot%\System32\Smss.exe) e i processi di hosting dei servizi generici (%Systemroot%\System32\Svchost.exe). Anche i processi di altro tipo possono richiedere la notifica dell'arrivo di una nuova CPU utilizzando un'API di Windows. Quando viene installata una nuova CPU, Windows notifica l'arrivo ai driver dei dispositivi, avvia la CPU e invia infine una notifica ai driver dei dispositivi alle applicazioni scritte in modo da sfruttare le nuove CPU che è possibile, se necessario, allocare delle strutture di dati per controllare l'attività sulla nuova CPU.

Virtualizzazione di computer
Prima di Windows Server 2008, i prodotti di virtualizzazione Microsoft, compreso Virtual Server 2005, venivano implementati utilizzando la virtualizzazione hosted, come illustrato nella Figura 5. Nella virtualizzazione hosted le macchine virtuali vengono implementate da un Monitor macchina virtuale (VMM) che viene eseguito insieme a un sistema operativo host, in genere come un driver di dispositivo. Il VMM sfrutta la gestione delle risorse e i driver di dispositivo del sistema operativo host e, quando il sistema operativo host ne pianifica l'esecuzione, il VMM suddivide il tempo di elaborazione della CPU tra le macchine virtuali attive (VM).
Figura 5 Virtualizzazione hosted
Figura 5 Virtualizzazione hosted
Hyper-V, noto in precedenza con il nome in codice "Viridian", viene implementato utilizzando la virtualizzazione hypervisor. Hypervisor ha il controllo completo di tutte le risorse hardware e anche il sistema operativo Windows Server 2008 che avvia il sistema e tramite il quale si controllano le macchine virtuali essenzialmente viene eseguito in una macchina virtuale, come di vede nella Figura 6.
Figura 6 Architettura di Hyper-V
Figura 6 Architettura di Hyper-V
L'hypervisor può suddividere il sistema in più macchine virtuali e trattare l'istanza di avvio di Windows Server 2008 come partizione principale, o radice, garantendo a tale istanza l'accesso diretto ai dispositivi hardware come dischi, schede di rete e processore grafico. L'hypervisor prevede che la partizione radice esegua le funzioni di risparmio energetico e risponda agli eventi di plug and play dell'hardware. Inoltre l'hypervisor intercetta l'I/O dei dispositivi hardware avviato da una partizione figlio e lo instrada verso la partizione radice, che utilizza i driver dei dispositivi standard di Windows Server 2008 per ottenere l'accesso all'hardware. In questo modo i server che utilizzano Hyper-V possono sfruttare al meglio il supporto di Windows per i dispositivi hardware.
Quando si configura Windows Server 2008 con il ruolo del server Hyper-V, Windows imposta i dati del database di configurazione dell'avvio (BCD) hypervisorimagelaunchtypeboot su auto e configura il driver di dispositivo Hvboot.sys in modo che venga avviato appena possibile nel processo di avvio. Se l'opzione è configurata, Hvboot.sys prepara il sistema alla virtualizzazione, quindi carica %Systemroot%\System32\Hvax64.exe o %Systemroot%\System32\Hvix64.exe in memoria, a seconda che il sistema implementi rispettivamente l'estensione di virtualizzazione AMD-V or Intel VT CPU.
Una volta caricato, l'hypervisor utilizza le estensioni di virtualizzazione per inserirsi sotto Windows Server 2008. Le applicazioni in modalità utente utilizzano il livello di privilegi Ring 3 del processore x64 e il codice in modalità kernel viene eseguito al livello Ring 0, quindi l'hypervisor opera al livello di privilegio concettuale di Ring -1, poiché può controllare l'ambiente di esecuzione del codice eseguito al livello Ring 0.
Quando si utilizza la console di gestione di Hyper-V per creare o inizializzare una partizione figlio, questa comunica con l'hypervisor utilizzando il driver %Systemroot%\System32\Drivers\Winhv.sys, che utilizza l'API di hypercall pubblicamente documentata per ottenere dall'hypervisor la creazione di una nuova partizione con le dimensioni della memoria fisica e le caratteristiche di esecuzione specificate. Il servizio della macchina virtuale (%Systemroot%\System32\Vmms.exe) all'interno della partizione radice è ciò che crea un processo di lavoro della macchina virtuale (%Systemroot%\System32\Vmwp.exe) per ciascuna partizione figlio per gestire lo stato della partizione figlio.
Un modo in cui Windows migliora le prestazioni dei sistemi operativi della macchina virtuale figlio è l'implementazione sia in Windows Server 2008 che in Windows Vista degli enlightenment, che sono sequenze di codice che si attivano solo quando il sistema operativo viene eseguito su un hypervisor che implementa l'API hypercall di Microsoft. Poiché richiede direttamente i servizi dell'hypervisor, la macchina virtuale figlio evita l'overhead del codice di virtualizzazione che risulterebbe se l'hypervisor dovesse indovinare l'intento del sistema operativo figlio.
Un sistema operativo guest, ad esempio, che non implementa gli enlightenment per gli spinlock, che esegue la sincronizzazione multiprocessore a basso livello, resterebbe in un loop stretto in attesa che uno spinlock venga rilasciato da un altro processore virtuale. Una delle CPU hardware ne potrebbe risultare bloccata fina a quando l'hypervisor pianifica il secondo processore virtuale. Sui sistemi operativi con enlightenment il codice spinlock notifica all'hypervisor, tramite hypercall, quando inizia il loop, in modo che l'hypervisor possa pianificare subito un altro processore virtuale e ridurre lo spreco in termini di utilizzo della CPU.
In Windows Server 2008 le prestazioni della macchina virtuale risultano migliori anche grazie all'accelerazione dell'accesso ai dispositivi da parte della macchina virtuale. Questo risultato si ottiene installando una raccolta di componenti, denominati collettivamente "componenti di integrazione della macchina virtuale", nel sistema operativo figlio.
Se si esegue una macchina virtuale senza installare i componenti di integrazione, il sistema operativo figlio configurerà i driver dei dispositivi hardware per i dispositivi emulati che l'hypervisor gli presenta. L'hypervisor deve intervenire quando un driver di dispositivo tenta di raggiungere una risorsa hardware per informare la partizione radice, che esegue l'I/O del dispositivo utilizzando i driver di dispositivo standard di Windows per conto del sistema operativo della macchina virtuale figlio. Poiché una singola operazione di I/O ad alto livello, come una lettura da un disco, può prevedere molti accessi discreti all'hardware, è possibile che si verifichino molte transizioni, denominate intercettazioni, nell'hypervisor e nella partizione radice.
Con Windows Server 2008 si riducono al minimo le intercettazioni grazie a tre componenti: il driver del bus della macchina virtuale (%Systemroot%\System32\Drivers\Vmbus.sys), i client del servizio virtuale (VSC) e i provider del servizio virtuale (VSP). Quando si installano i componenti di integrazione in una macchina virtuale con un sistema operativo supportato, i VSC assumono il ruolo di driver di dispositivo e utilizzano i servizi del driver Vmbus.sys nella macchina virtuale figlio per inviare le richieste di I/O ad alto livello al driver del bus della macchina virtuale nella partizione radice, tramite l'hypercall e i servizi di condivisione della memoria dell'hypervisor. Nella partizione radice Vmbus.sys inoltra la richiesta al VSP corrispondente, che avvia quindi le richieste di I/O Windows standard mediante i driver di dispositivo della partizione radice.
Come si può vedere, Windows Server 2008 ha un ruolo fondamentale nella strategia di virtualizzazione di Microsoft, proprio grazie all'introduzione della virtualizzazione basata sull'hypervisor Hyper-V. Ulteriori informazioni su queste e altre funzionalità verranno pubblicate nella prossima edizione del mio libro, Microsoft Windows Internals, in uscita tra qualche mese.

Mark Russinovichè un Technical Fellow di Microsoft nella Platform and Services Division. È coautore di Microsoft Windows Internals (Microsoft Press, 2004) e spesso partecipa come oratore a conferenze su IT e sviluppo, tra cui Microsoft TechEd e Professional Developers Conference. È entrato in Microsoft dopo l'acquisizione dell'azienda che ha cofondato, Winternals Software. Ha inoltre creato Sysinternals, dove ha pubblicato molte diffuse utilità, tra cui Process Explorer, Filemon e Regmon.
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 Numero speciale Windows Server 2008: Novit&#224; in Servizi di dominio Active Directory
Numero speciale Windows Server 2008 Gil Kirkpatrick

Novità in Servizi di dominio Active Directory
Panoramica:
  • Utilizzo del nuovo strumento Server Manager con ADDS
  • Esecuzione dei servizi di dominio su Server Core
  • Controller di dominio di sola lettura
  • Modifica di password, backup e controllo

Con Windows 2000 Microsoft ha introdotto Active Directory. La versione successiva, Windows Server 2003, ha introdotto significativi miglioramenti in Active Directory, ma nessuna
modifica rivoluzionaria. Oggi, Active Directory® è un servizio directory consolidato e molto affidabile. Ciò nonostante, il team di Active Directory ha introdotto innovazioni significative nella versione più recente allo scopo di migliorare la protezione e la gestibilità di questo servizio di rete di base.
Al volgere del secolo, Active Directory rappresentava il sistema in grado di autenticare un utente all'accesso, applicare criteri di gruppo all'utente e al relativo computer e assistere l'utente nella ricerca della stampante desiderata. Alcuni anni dopo, Microsoft ha rilasciato una variante autonoma denominata Active Directory Application Mode (ADAM).
Con l'avvento del 2006, la situazione è completamente cambiata. Active Directory non era più una tecnologia specifica. Attualmente, rappresenta un marchio che identifica un insieme di servizi Windows® integrati per il controllo di accesso e di identità. Nella Figura 1 viene riportato un rapido riepilogo dei componenti che costituiscono Active Directory.
Figure 1 Componenti di Active Directory (Close Figure 1)

Tecnologia Active Directory corrente | Denominazione precedente | Descrizione
Servizi di dominio Active Directory (ADDS) | Active Directory | Si tratta della tecnologia che in precedenza era definita Active Directory. Fornisce l'autenticazione Kerberos e basata su NTLM per gli utenti e i computer di dominio; inoltre gestisce unità organizzative, utenti, gruppi, criteri di gruppo e molto altro.
Active Directory Lightweight Directory Services (ADLDS) | Active Directory Application Mode (ADAM) | Un server LDAP a elevate prestazioni basato sullo stesso codice sorgente utilizzato da ADDS.
Servizi certificati Active Directory (ADCS) | Servizi certificati | Fornisce autenticazione avanzata mediante certificati X.509.
Active Directory Rights Management Services (ADRMS) | Rights Management Server | Protegge le risorse digitali, come documenti e messaggi di posta elettronica, dall'utilizzo non autorizzato creando file e contenitori protetti da diritti.
Active Directory Federation Services (ADFS) | Active Directory Federation Services | Fornisce federazione delle identità e funzionalità Single Sign-On Web per i servizi Web compatibili con WS-*.
Pertanto, per utilizzare la corretta terminologia, questo articolo tratta di Servizi di dominio. È bene chiarire, tuttavia, che si tratta dello stesso Active Directory che abbiamo imparato ad amare sin dal 2000.

Server Manager in Windows Server 2008
I primi due miglioramenti per Active Directory che verranno illustrati in questo articolo, in effetti, non rappresentano le modifiche introdotte in Servizi di dominio Active Directory (ADDS), quanto piuttosto le modifiche introdotte nell'ambiente Windows che cambieranno la modalità di gestione di Active Directory. Il primo, il nuovo strumento Server Manager, viene visualizzato quando il server Windows Server® 2008 viene avviato per la prima volta. Il secondo è rappresentato dall'installazione di Server Core, che verrà trattata tra breve.
Server Manager risulterà probabilmente familiare in quanto già disponibile nella Configurazione guidata server di Windows Server 2003, che viene visualizzata, per impostazione predefinita, dopo l'installazione di Windows Server 2003. Tale versione, tuttavia, non risulta particolarmente utile per l'amministrazione quotidiana e molti utenti preferiscono selezionare la casella "Non visualizzare questa pagina all'accesso".
Server Manager in Windows Server 2008, invece, si rivela molto utile (per una panoramica su Server Manager, vedere l'articolo di Byron Hynes in questo numero di TechNet Magazine). Innanzitutto, come si può osservare nella Figura 2, Server Manager ora è uno snap-in di Microsoft® Management Console (MMC) anziché un'applicazione HTML (HTA). Questo significa che tale strumento è dotato di un'interfaccia utente con funzionalità complete familiare e facile da personalizzare. Server Manager consente di gestire l'installazione dei ruoli del server (servizi principali come DNS, ADDS e IIS) e delle funzionalità (componenti software, come Microsoft .NET Framework, Crittografia unità BitLockerTM e Windows PowerShellTM). Oltre alla possibilità di aggiungere e rimuovere il software, Server Manager fornisce anche un singolo punto di contatto per l'esecuzione di strumenti di diagnostica, come Visualizzatore eventi e PerfMon, e utilità di configurazione di sistema, come Gestione dispositivi e lo snap-in Windows Firewall. Se si aggiungono gli snap-in di MMC per Active Directory, ad esempio Utenti e computer, Domini e trust e Siti e servizi, si avrà a disposizione un'interfaccia molto interessante per la gestione quotidiana del controller di dominio di Windows Server 2008.
Figura 2 Server Manager in Windows Server 2008
Figura 2 Server Manager in Windows Server 2008

Server Core per Windows Server 2008
Windows Server Core è una nuova opzione di installazione di Windows che fornisce una versione ridotta di Windows contenente solo i componenti necessari per eseguire alcuni ruoli del server principali, come Servizi di dominio Active Directory. Nella Figura 3 vengono elencati i ruoli supportati da Server Core. Sebbene l'installazione di Server Core preveda un'interfaccia grafica, non esegue la shell desktop di Windows e quasi tutti gli strumenti grafici per la gestione e la configurazione di Windows sono assenti (vedere la Figura 4). In sostituzione di tali strumenti è presente solo una finestra di comando, che crea una "sensazione di vuoto", in quanto non viene fornita alcuna indicazione sulle successive azioni da intraprendere. In che modo è possibile modificare il nome del computer? In che modo è possibile configurare un indirizzo IP statico?
Figura 4 Non c'è molto da vedere nell'interfaccia utente di Server Core
Figura 4 Non c'è molto da vedere nell'interfaccia utente di Server Core
I primi minuti davanti a un'installazione di Server Core possono essere in un certo qual modo sconvolgenti. Tuttavia, se si dedica un po' di tempo ad acquisire nuovamente dimestichezza con le utilità WMIC, NETSH e NETDOM, si sarà in grado di eseguire tutte le comuni attività di installazione e configurazione senza alcuna difficoltà. Inoltre, per soddisfare le proprie esigenze grafiche, è ancora possibile avvalersi di Regedit e del Blocco note.
Il vantaggio principale di Server Core è che gran parte della quantità di codice risultante da un'installazione di Windows tipica, che potrebbe non essere necessaria per i ruoli del server di base, viene rimossa. Questo determina una riduzione della potenziale superficie di attacco per il malware (un grande vantaggio) nonché una riduzione del numero di applicazioni di patch e di riavvii che è necessario eseguire nei controller di dominio (un vantaggio ancora maggiore). È possibile inoltre ottenere una riduzione del footprint del disco e dei requisiti dell'unità disco, il che, sebbene non rappresenti un grosso vantaggio, può rivelarsi particolarmente utile in ambienti server virtualizzati.
La mancanza di utilità grafiche renderà difficoltosa la gestione di ADDS? Niente affatto. È possibile effettuare quasi tutta le attività di gestione in modalità remota eseguendo le utilità sulla workstation locale e connettendosi al controller di dominio in rete. Prevedo che la maggior parte dei controller di dominio verrà, alla fine, eseguita nelle installazioni Server Core.

Modifiche a DCPROMO
La prima modifica che è possibile notare in ADDS è rappresentata dalla nuova funzionalità DCPROMO. Sebbene identica alla funzionalità DCPROMO disponibile in Windows Server 2003, la nuova utilità è stata completamente riscritta per semplificarne l'utilizzo. Non è necessario, ad esempio, inserire le credenziali di amministratore di dominio, in quanto DCPROMO è in grado di utilizzare le credenziali dell'account di accesso corrente per innalzare di livello il server. Non occorre inoltre digitare DCPROMO /ADV per attivare le opzioni DCPROMO in modalità avanzata; ora nella prima finestra di dialogo di DCPROMO è presente una casella di controllo che consente di attivare queste opzioni. La modalità avanzata consente inoltre di selezionare il controller di dominio esistente da cui eseguire la replica. Questo contribuisce a ridurre il carico di replica di DCPROMO che grava sui controller di dominio di produzione.
Durante l'innalzamento di livello di un controller di dominio in un nuovo dominio o una nuova foresta, DCPROMO consente di impostare immediatamente il livello di funzionalità del dominio e della foresta. È inoltre possibile specificare il sito di Active Directory in cui si desidera inserire il controller di dominio durante il processo di innalzamento di livello, il che risulta molto utile in uno scenario con DCPROMO in automatico. DCPROMO è in grado persino di suggerire il sito più appropriato per il controller di dominio in base all'indirizzo IP del controller di dominio.
Il nuovo strumento DCPROMO prevede la raccolta in una singola pagina di tutte le opzioni di configurazione, fornendo un'unica posizione in cui è possibile scegliere se impostare il nuovo controller di dominio su un catalogo globale, un server DNS o un controller di dominio di sola lettura. Non è necessario accedere a un'area sconosciuta dello snap-in Siti e servizi di Active Directory per contrassegnare il controller di dominio come catalogo globale.
Tuttavia, probabilmente la funzionalità più interessante della nuova utilità DCPROMO è rappresentata dalla capacità di salvare tutte le impostazioni di DCPROMO in un file di risposta prima dell'avvio del processo di innalzamento di livello. Questo meccanismo è molto più semplice e meno soggetto a errori rispetto alla compilazione manuale del file di risposta. È quindi possibile utilizzare il file di risposta per eseguire le operazioni DCPROMO in modalità automatica su altri server. Per i fanatici degli script, tutte le opzioni di DCPROMO sono ora accessibili dalla riga di comando.

Controller di dominio di sola lettura
Nelle prime fasi del rilascio di Active Directory, le organizzazioni distribuivano in genere i controller di dominio in ogni sito a cui gli utenti potevano accedere. Questo comportamento era piuttosto comune nelle banche, che collocavano, ad esempio, un controller di dominio in ogni succursale. La logica era che gli utenti nella succursale sarebbero stati in grado di accedere alle risorse di rete locali anche in caso di errore della rete WAN.
In quel periodo, l'importanza della necessità di garantire la protezione fisica dei controller di dominio non era stata ben compresa. Ho visto controller di dominio posizionati sotto le scrivanie a cui tutti potevano accedere senza problemi. Solo alcuni anni dopo i progettisti di Active Directory hanno compreso pienamente il rischio per la protezione che un controller di dominio non protetto crea. Di conseguenza, le organizzazioni IT hanno iniziato a consolidare i relativi controller di dominio in centri dati più centralizzati. Questo implicava la necessità per gli utenti delle succursali di eseguire l'autenticazione sulla rete WAN, un compromesso tuttavia vantaggioso in termini di maggiore protezione.
Active Directory in Windows Server 2008 cambia l'equazione rispetto alle distribuzioni in succursali introducendo i controller di dominio di sola lettura. Questi rappresentano la modifica la più significativa in Servizi di dominio di Windows Server 2008.
Il team di Active Directory si è concentrato sui requisiti dello scenario di distribuzione in succursali quando ha progettato il controller di dominio di sola lettura e ha adottato un approccio di tipo "Ciò che accade nella succursale, resta nella succursale". Il punto è che, se si distribuisce un controller di dominio in una succursale fisicamente non protetta, non si potrà in alcun modo impedire che il controller di dominio (e i computer che considerano attendibile tale controller di dominio) venga compromesso. È tuttavia possibile impedire che tale compromissione si diffonda dalla succursale nel resto del dominio.
Tenere presente che, anche se rappresentano una modifica significativa all'infrastruttura ADDS, i controller di dominio di sola lettura sono piuttosto semplici da implementare. Il dominio deve essere al livello di funzionalità della foresta di Windows Server 2003 ed è necessario che nel dominio sia presente almeno un controller di dominio di Windows Server 2008. Oltre a essere una semplice soluzione per succursali, i controller di dominio di sola lettura sono utili in ambienti che interagiscono con Internet e in situazioni in cui il controller di dominio viene posizionato nella rete perimetrale.

Furto di un controller di dominio
Esistono diverse classi di minacce che occorre prendere in considerazione in una succursale. Il primo tipo di minaccia è rappresentato da uno scenario che prevede il furto di un controller di dominio, in cui qualcuno ruba il controller di dominio o il disco del controller di dominio. Oltre all'interruzione del servizio locale, il rischio principale è rappresentato dalla capacità dell'utente malintenzionato di accedere a tutti i nomi e le password degli utenti all'interno del dominio e di elevare i relativi privilegi per ottenere l'accesso alle risorse protette o causare un attacco Denial of Service. Per far fronte a questa minaccia, i controller di dominio di sola lettura, per impostazione predefinita, non archiviano hash di password nel database DIT (Directory Information Tree) del controller di dominio di sola lettura. Pertanto, per eseguire l'autenticazione nel dominio, quando un utente si autentica per la prima volta presso uno specifico controller di dominio di sola lettura, quest'ultimo passa la richiesta al controller di dominio completo nel dominio. Il controller di dominio completo elabora la richiesta e, in caso di esito positivo, il controller di dominio di sola lettura emette una richiesta di replica per l'hash di password.
Un controller di dominio di sola lettura compromesso potrebbe richiedere hash di password per gli account riservati. Per impedire una situazione di questo tipo, l'amministratore del dominio può configurare un criterio di replica password per ogni controller di dominio di sola lettura. Il criterio di replica password è composto da due attributi nell'oggetto computer del controller di dominio di sola lettura. L'attributo msDS-RevealOnDemandGroup contiene i nomi distinti di gruppi, utenti o account di computer le cui password possono essere memorizzate nella cache del controller di dominio di sola lettura (si tratta in genere degli utenti e dei computer che risiedono nello stesso sito del controller di dominio di sola lettura). L'attributo msDS-NeverRevealGroup contiene i nomi distinti di gruppi, utenti o account di computer le cui password non possono essere memorizzate nella cache del controller di dominio di sola lettura (ad esempio, l'account di amministratore di dominio non deve mai memorizzare nella cache del controller di dominio di sola lettura i relativi hash di password). Quando il controller di dominio di sola lettura richiede l'hash della password per uno specifico account, il controller di dominio completo valuta la richiesta in base al criterio di replica password per determinare se l'hash della password deve essere replicato nel controller di dominio di sola lettura. Quando un controller di dominio viene rubato, questa situazione limita la vulnerabilità delle password che sono state memorizzate nella cache del controller di dominio di sola lettura rubato nel momento in cui è stato rimosso dalla rete ed elimina la possibilità che una password critica venga compromessa.
L'oggetto computer del controller di dominio di sola lettura contiene altri due attributi che consentono di determinare esattamente quali account devono avere le relative password memorizzate nella cache. L'attributo msDS-AuthenticatedAtDC elenca gli account che sono stati autenticati nel controller di dominio di sola lettura, mentre l'attributo msDS-RevealedList elenca gli account le cui password sono correntemente memorizzate nel controller di dominio di sola lettura.
Gli hash di password di utenti e computer non sono gli unici segreti memorizzati in un controller di dominio. L'account KrbTGT contiene le chiavi per il servizio Centro distribuzione chiavi Kerberos (KDC) in esecuzione in ciascun controller di dominio. In uno scenario tipico, ogni KDC all'interno del dominio condivide lo stesso account KrbTGT ed è possibile che un utente malintenzionato recuperi queste chiavi da un controller di dominio rubato e le utilizzi per sferrare un attacco contro il resto del dominio. Tuttavia, ogni controller di dominio di sola lettura dispone di un proprio account KrbTGT e di specifiche chiavi, eliminando tale possibilità.
Inoltre, non è insolito per le applicazioni memorizzare le password o altri segreti nel DIT. Se un utente malintenzionato dovesse rubare un controller di dominio, potrebbe rubare eventualmente le password di queste applicazioni e utilizzarle per accedere alle applicazioni. Per ridurre questo rischio, Servizi di dominio di Windows Server 2008 consente agli amministratori di definire il RO-FAS (Read-Only DC Filtered Attribute Set). Gli attributi che fanno parte del RO-FA non vengono mai replicati nei controller di dominio di sola lettura e, pertanto, non possono essere recuperati da un controller di dominio compromesso. È possibile assegnare attributi al RO-FAS impostando il bit 9 (0x0200) dell'attributo searchFlags dell'oggetto attributeSchema corrispondente nello schema.

I barbari sono alle porte
Un'altra classe di minaccia per i controller di dominio delle succursali è rappresentata da uno scenario in cui un amministratore di un server locale eleva i relativi privilegi utilizzando i privilegi del controller di dominio per ottenere l'accesso ad altre risorse del dominio o progettare un attacco Denial of Service. Se l'amministratore locale dispone dell'accesso fisico al controller di dominio, non è possibile in alcun modo evitare la compromissione. Tuttavia, è possibile impedire all'utente malintenzionato di utilizzare il controller di dominio della succursale per compromettere gli altri controller di dominio all'interno del dominio.
I controller di dominio di sola lettura non vengono considerati come controller di dominio trusted dai controller di dominio completi all'interno del dominio. Dal punto di vista dell'attendibilità, i controller di dominio completi considerano i controller di dominio di sola lettura come server membro del dominio. Un controller di dominio di sola lettura non è membro del gruppo Controller di dominio organizzazione o Controller di dominio. Poiché la capacità dell'account del controller di dominio di sola lettura di aggiornare il contenuto della directory è piuttosto limitata, anche se un utente malintenzionato compromette l'account del controller di dominio di sola lettura, non otterrà privilegi utili.
I controller di dominio di sola lettura non vengono neppure visualizzati nella normale topologia di replica di Servizi di dominio. Poiché i controller di dominio di sola lettura sono simili a normali server membro piuttosto che a controller di dominio, l'attività di Controllo di coerenza informazioni (KCC, Knowledge Consistency Checker), che rappresenta il processo in ciascun controller di dominio responsabile del calcolo della topologia di replica di Servizi di dominio, non creerà oggetti connessione dai controller di dominio di sola lettura. Nessun controller di dominio completo o controller di dominio di sola lettura tenterà di eseguire la replica da un controller di dominio di sola lettura. D'altra parte, il controller di dominio di sola lettura creerà un oggetto connessione che rappresenta un accordo di replica in ingresso da un controller di dominio completo; tuttavia, questo oggetto connessione esiste solo nella replica del controller di dominio di sola lettura, in quanto nessun altro controller di dominio dispone di una copia dell'oggetto connessione in questione. Dal punto di vista della replica, i controller di dominio di sola lettura sono come "trappole per scarafaggi" per gli oggetti directory. Gli oggetti vengono replicati in ingresso, ma non vengono replicati in uscita.

Separazione dei ruoli amministrativi nei controller di dominio di sola lettura
È molto comune che un controller di dominio di succursale venga gestito da un amministratore del server locale che esegue qualsiasi tipo di operazione, dall'esecuzione dei backup sul controller di dominio alla pulizia delle tastiere. Tuttavia, la concessione a un amministratore di un sito remoto dei diritti necessari per eseguire la manutenzione generale in un controller di dominio rappresenta un rischio per la protezione e l'amministratore del sito potrebbe elevare i relativi privilegi nel dominio. Per ridurre questo rischio, i controller di dominio di sola lettura forniscono due tipi di separazione dei ruoli amministrativi.
Con il primo tipo di separazione dei ruoli, l'amministratore del dominio può innalzare di livello il controller di dominio di sola lettura utilizzando DCPROMO o può utilizzare un processo a due fasi in cui il processo di innalzamento di livello effettivo viene delegato all'amministratore della succursale, senza concedere diritti per l'amministrazione del dominio. L'amministratore del dominio crea in modo preliminare l'account del computer del controller di dominio di sola lettura utilizzando lo snap-in MMC Utenti e computer di Active Directory, come illustrato nella Figura 5.
Figura 5 Creazione preliminare dell'account del computer del controller di dominio di sola lettura
Figura 5 Creazione preliminare dell'account del computer del controller di dominio di sola lettura
Se si seleziona "Creazione preliminare account controller di dominio di sola lettura", verrà eseguita una versione abbreviata di DCPROMO che esegue tutte le attività che richiedono l'accesso amministrativo al dominio, tra cui la creazione dell'account del computer, l'assegnazione del controller di dominio di sola lettura a un sito, l'impostazione dei ruoli del controller di dominio, l'impostazione dei criteri di replica password e la definizione dell'utente o del gruppo che dovrà disporre dei diritti necessari per completare l'operazione DCPROMO nel controller di dominio di sola lettura. L'amministratore o il gruppo delegato viene memorizzato nell'attributo managedBy dell'oggetto computer del controller di dominio di sola lettura.
L'amministratore delegato può eseguire quindi DCPROMO sullo stesso server. DCPROMO rileverà l'account creato in modo preliminare e convertirà il server in un controller di dominio di sola lettura. Questa modalità di esecuzione di DCPROMO non richiede credenziali di amministratore di dominio.
Il secondo metodo con cui i controller di dominio di sola lettura forniscono la separazione dei ruoli amministrativi consiste nel creare ruoli amministrativi locali nel controller di dominio di sola lettura. Questi ruoli, che sono simili a gruppi locali di computer, vengono memorizzati nel Registro di sistema del controller di dominio di sola lettura e possono essere solo valutati nel controller di dominio di sola lettura. Tuttavia, anziché utilizzare lo snap-in di MMC Gestione computer per gestirli, l'amministratore gestisce i ruoli dei controller di dominio di sola lettura locali mediante NTDSUTIL. Nella Figura 6 vengono elencati i ruoli amministrativi locali in un controller di dominio di sola lettura. Esiste una corrispondenza uno-a-uno tra questi ruoli e i gruppi incorporati di Windows.
Figure 6 Ruoli amministrativi dei controller di dominio di sola lettura locali (Close Figure 6)

Account Operators
Administrators
Backup Operators
Certificate Service DCOM Access
Cryptographic Operators
Distributed COM Users
Event Log Readers
Guests
IIS_IUSRS
Incoming Forest Trust Builders
Network Configuration Operators
Performance Log Users
Performance Monitor Users
Pre-Windows 2000 Compatible Access
Print Operators
Remote Desktop Users
Replicator
Server Operators
Terminal Server License Servers
Users
Windows Authorization Access Group

Comportamento imprevisto dei controller di dominio di sola lettura
Poiché i controller di dominio di sola lettura sono di sola lettura e nessuno altro controller di dominio può eseguire la replica da tali controller di dominio, i controller di dominio di sola lettura presentano alcuni comportamenti imprevisti. Ad esempio, gli oggetti residui, ovvero gli oggetti che sono stati eliminati da ovunque eccetto da uno specifico controller di dominio, in quanto quest'ultimo non è stato in grado di eseguire la replica per un tempo maggiore rispetto alla durata di rimozione definitiva della foresta, vengono in genere rilevati dai partner di replica in uscita del controller di dominio. Tuttavia, poiché i controller di dominio di sola lettura non dispongono di partner di replica in ingresso, per tali controller di dominio non viene rilevato alcun oggetto residuo.
I controller di dominio di sola lettura non prevedono le operazioni di aggiornamento LDAP (aggiunta, modifica, eliminazione, ridenominazione o spostamento), ma restituiscono un errore con un riferimento LDAP a un controller di dominio scrivibile che può gestire l'operazione. Se l'applicazione che ha richiesto l'aggiornamento LDAP non è in grado di gestire correttamente l'operazione di riferimento, è possibile che si verifiche un errore.
Infine, se un utente da un altro dominio nella foresta tenta di eseguire l'autenticazione in un controller di dominio di sola lettura, quest'ultimo dovrà essere in grado di accedere a un controller di dominio completo nel proprio dominio per ottenere la password di trust in modo da passare correttamente la richiesta di autenticazione al controller di dominio nel dominio dell'utente. Se la connessione di rete tra il controller di dominio di sola lettura e il controller di dominio completo nel relativo dominio non è disponibile, l'autenticazione non riuscirà.

Criteri specifici per le password
La capacità di definire più criteri password nel dominio è stata probabilmente la funzionalità più richiesta per il servizio ADDS di Windows Server 2008. Come probabilmente si saprà, in Windows 2000 e in Active Directory per Windows Server 2003, ogni dominio supporta un singolo criterio password che viene applicato a tutte le entità di protezione all'interno del dominio. Se si necessita di un criterio password separato per un gruppo specifico di utenti, occorre creare un dominio separato. Tuttavia, ora una nuova funzionalità di ASSD per Windows Server 2008, denominata criteri specifici per le password, consente di definire più criteri password all'interno di un dominio.
La nuova strategia utilizza i gruppi per applicare agli utenti i criteri specifici per le password. È necessario prima definire i criteri specifici per le password creando un nuovo oggetto msDS-PasswordSettings in CN=Contenitore Impostazioni password, CN=Sistema, DC=<dominio>. L'oggetto msDS-PasswordSettings (abbreviato in PSO) contiene attributi che equivalgono all'impostazione dei criteri password in Criteri di gruppo (vedere la Figura 7).
Figure 7 Attributi nell'oggetto mSDS-PasswordSettings (Close Figure 7)

Attributo | Descrizione
mSDS-PasswordReversibleEncryptionEnabled | Valore booleano che indica se le password vengono crittografate mediante la crittografia reversibile.
mSDS-PasswordHistoryLength | Numero di voci contenute nella cronologia delle password.
mSDS-PasswordComplexityEnabled | Valore booleano che indica se le restrizioni relative alla complessità delle password sono attivati.
mSDS-MinimumPasswordLength | Numero intero che definisce la lunghezza minima della password.
mSDS-MinimumPasswordAge | INTEGER8 che indica la validità minima della password prima che possa essere modificata.
mSDS-MaximumPasswordAge | INTEGER8 che indica la validità massima della password prima che sia necessario modificarla.
mSDS-LockoutThreshold | Numero intero che indica il numero di accessi non riusciti prima del blocco.
mSDS-LockoutObservationWindow | INTEGER8 che indica il numero di nanosecondi entro cui è necessario eseguire accessi consecutivi non riusciti per attivare il blocco.
mSDS-LockoutDuration | INTEGER8 che indica il numero di nanosecondi in cui l'account viene bloccato.
Assegnare quindi i criteri password agli utenti o ai gruppi aggiungendo i nomi degli utenti o dei gruppi all'attributo multivalore mDS-PSOAppliesTo di PSO. Una volta accettata l'idea che i criteri password non vengono applicati alle unità organizzative, tale attività è piuttosto semplice, anche se presenta un livello di complessità aggiuntivo.
Gli utenti sono in genere membri di molti gruppi. Pertanto, cosa accade se a un utente sono associati più criteri password in conflitto a causa dell'appartenenza a diversi gruppi? In questo caso, ADDS utilizza la valutazione delle precedenze per determinare quali criteri password devono essere applicati. Questo meccanismo funziona come indicato di seguito:
  1. Se un criterio password viene collegato a un oggetto utente direttamente (non tramite l'appartenenza al gruppo), verrà applicato il criterio password in questione.
  2. Se all'utente vengono collegati direttamente più criteri password, verrà applicato il criterio con il valore di precedenza più basso (come determinato dal valore dell'attributo msDS-PasswordSettingsPrecendence di PSO).
  3. Se sono presenti più PSO con la stessa precedenza, verrà applicato quello con il valore objectGUID più basso.
  4. Se all'utente non viene collegato direttamente alcun PSO, ADDS valuterà i PSO collegati ai gruppi dell'utente. Se sono presenti più PSO, verrà applicato il PSO con il valore più basso nell'attributo msDS-PasswordSettingsPrecedence.
  5. Se sono presenti più PSO con lo stesso valore di precedenza, verrà applicato quello con il valore objectGUID più basso.
  6. Se all'utente non è associato alcun PSO, verranno utilizzati i criteri password di dominio.
Gli oggetti utente hanno un nuovo attributo denominato msDS-ResultantPSO che consente di determinare esattamente il PSO da applicare a un utente. Questo attributo contiene il nome distinto del PSO che gestisce la password dell'utente in questione.
I criteri specifici per le password forniscono maggiore flessibilità di quella effettivamente necessaria, ma occorre gestire questi criteri con attenzione e garantirne la semplicità di utilizzo. Non è disponibile alcuna utilità integrata per la definizione di criteri specifici per le password e, pertanto, sarà necessario utilizzare ADSIEdit o un'utilità di terze parti.

Servizio Active Directory riavviabile
Ogni volta che si provoca l'arresto di un controller di dominio per la manutenzione DIT si causa un'interruzione nei livelli di servizio della rete. I controller di dominio di Windows Server 2008 dispongono di una nuova funzionalità che consente di arrestare il servizio directory senza arrestare completamente il controller di dominio.
Il comando NET STOP NTDS consente di arrestare ADDS in un controller di dominio di Windows Server 2008. Quando si esegue questa operazione, il processo LSASS (Local Security Authority Subsystem Service) sul controller di dominio continua l'esecuzione, ma scarica tutte le DLL correlate ad ADDS e il servizio directory diventa non disponibile. LSASS si comporta essenzialmente come si comporterebbe su un server membro, inoltrando le richieste di autenticazione del dominio a un controller di dominio. Poiché le DLL che gestiscono ADDS vengono scaricate, è possibile applicare delle patch correlate ad ADDS o eseguire una deframmentazione non in linea del DIT. L'avvio di ADDS è semplice quanto l'avvio di NET START NTDS. Il ripristino del DIT da un backup dello stato di sistema richiede tuttavia l'esecuzione dell'avvio in modalità ripristino servizi directory.
È importante comprendere che il servizio directory non è un vero servizio di Windows. È un componente integrato di LSASS e non è possibile arrestare LSASS senza spegnere il computer. Tuttavia, la capacità di avviare e arrestare il servizio directory in Windows Server 2008 è un'opzione molto utile.

Backup e ripristino
L'intero meccanismo di backup e ripristino è stato rinnovato in Windows Server 2008. Questo meccanismo non verrà trattato in modo dettagliato nel presente articolo, ma la nuova funzionalità Windows Server Backup presenta alcune modifiche che hanno un impatto significativo su ADDS.
Windows Server Backup è una soluzione di backup basata su volume, ovvero esegue contemporaneamente il backup dei volumi dell'intero disco. Prevede inoltre solo il backup su periferiche disco e non fornisce il supporto per i backup su nastro.
Per l'utilità di backup della riga di comando WBADMIN è disponibile un'opzione di backup dello stato di sistema. Utilizzando il comando WBADMIN START SYSTEMSTATEBACKUP, ora è possibile creare un'immagine di backup che contiene tutti i file di sistema critici necessari per ripristinare Active Directory su un controller di dominio. Il set di backup può contenere un massimo di cinque volumi, ma i volumi nel set di backup conterranno solo i file necessari per un ripristino dello stato di sistema. Ancora più fastidioso è il fatto che, a partire dalla build RC0 di Windows Server 2008, non è possibile eseguire un backup dello stato di sistema in una condivisione di rete. Per archiviare le immagini di backup dello stato di sistema, è necessario che sia disponibile un volume del disco locale e che il volume non faccia parte del set di volumi di backup dello stato di sistema. Potrebbe essere necessario aggiungere un nuovo volume del disco a ogni controller di dominio su cui si eseguono i backup dello stato di sistema.
L'esecuzione di un ripristino dello stato di sistema è piuttosto semplice. Avviare semplicemente il controller di dominio in modalità ripristino servizi directory ed eseguire il comando WBADMIN START SYSTEMSTATERECOVERY. Il risultato è un DIT non ripristinato in modo autorevole, in cui è possibile eseguire un ripristino autorevole di oggetti specifici utilizzando NTDSUTIL, come è stato fatto in Windows Server 2003.
Un aspetto di Windows Server Backup merita particolare attenzione, ovvero la capacità di archiviare le immagini di backup in formato VHD (Virtual Hard Disk). Si tratta dello stesso formato utilizzato in Microsoft Virtual Server 2005 per archiviare le relative immagini disco virtuali. Questo implica la possibilità di utilizzare un'immagine di backup creata con Windows Server Backup e di montarla come unità disco in un computer virtuale in esecuzione su Microsoft Virtual Server. È possibile quindi esplorare i contenuti di backup come se si trattasse di una normale unità disco.
Un'altra modifica riguardante il meccanismo di backup di ADDS è rappresentata dalla capacità di utilizzare il servizio Copia Shadow del volume per creare istantanee temporizzate di Active Directory. Quando si crea un'istantanea utilizzando NTDSUTIL, il servizio Copia Shadow del volume salva i dati visualizzati prima dell'immagine di ciascun blocco del disco del DIT prima che vengano sovrascritti da un'operazione di aggiornamento. Combinando questi dati salvati con la versione corrente del DIT, il servizio Copia Shadow del volume può creare un'istantanea completa del DIT con un overhead minimo. Un'istantanea tipica viene creata solo in pochi secondi, indipendentemente dalle dimensioni del DIT.
Sebbene questa funzionalità sia piuttosto interessante, non è di grande utilità. Tuttavia, in Windows Server 2008, ADDS include un'utilità della riga di comando, denominata DSAMAIN, che consente di montare l'immagine dell'istantanea in modalità di sola lettura. Questo fornisce un server LDAP autonomo, molto simile a un'istanza ADLDS che include il contenuto della directory al momento dell'istantanea. È possibile esplorare la directory utilizzando l'utilità LDP o altri strumenti LDAP e recuperare le versioni degli oggetti directory relative a un momento precedente.

Replica SYSVOL con DFS-R
Windows Server 2003 R2 includeva un servizio DFS (Distributed File Service) completamente rinnovato che incorporava un nuovo meccanismo di replica dei file denominato DFS-R. DFS-R utilizza la tecnologia RDC (Remote Differential Compression, Compressione differenziale remota), che in sostanza riduce il traffico di replica dei file determinando quali blocchi di un file di destinazione devono essere replicati in modo da sincronizzare il file di destinazione con il file di origine. Tuttavia, Windows Server 2003 R2 continua a utilizzare il servizio Replica file (non DFS-R) per replicare SYSVOL tra i controller di dominio. Per questo motivo, la replica SYSVOL ha continuato a essere fonte di problemi per gli amministratori di Active Directory.
Quando l'esecuzione avviene al livello di funzionalità del dominio di Windows Server 2008, Windows Server 2008 è in grado di replicare SYSVOL mediante DFS-R, migliorando la velocità e la robustezza della replica SYSVOL. È ragionevole pertanto collocare file di grandi dimensioni in SYSVOL in modo da renderli disponibili su tutti i controller di dominio. Per utilizzare DFS-R per SYSVOL, è necessario prima eseguire la migrazione dei dati SYSVOL precedenti in DFS-R utilizzando l'utilità DFSRMIG. Questo processo prevede quattro passaggi:
  • Creare gli oggetti Active Directory richiesti da DFS-R.
  • Creare la nuova struttura di file per SYSVOL su ogni controller di dominio.
  • Configurare tutti i controller di dominio per l'utilizzo del nuovo volume SYSVOL.
  • Rimuovere il volume SYSVOL precedente.
A seconda delle dimensioni di SYSVOL e del numero di controller di dominio a disposizione, questo processo potrebbe richiedere molto tempo; tuttavia l'incremento delle prestazioni e il miglioramento dell'affidabilità fanno passare in secondo piano lo sforzo compiuto.

Miglioramenti al sistema di controllo
Il sistema di controllo in Active Directory per Windows Server 2003 arreca vantaggi ma anche problemi. Da una parte, fornisce una soluzione completa, flessibile e protetta per tenere traccia delle modifiche nella directory. Tuttavia, alcuni potrebbero sostenere che presenta significativi problemi di utilizzabilità.
L'abilitazione del controllo delle modifiche della directory in un controller di dominio di Windows Server 2003 è come un'operazione di tipo "all-or-nothing": il controllo o è attivato o è disattivato. Inoltre, il volume del traffico di controllo su un controller di dominio organizzazione non disponibile può rendere il controllo impraticabile. La configurazione del sistema di controllo per la produzione dei messaggi necessari utilizzando singoli descrittori di protezione è un'attività noiosa e soggetta a errori. Gli stessi messaggi di controllo sono spesso enigmatici e, in molti casi, non contengono le informazioni necessarie, come i valori precedenti e successivi degli attributi modificati. Inoltre, la raccolta, la correlazione e l'archiviazione dei messaggi da più controller di dominio potrebbe non essere possibile mediante gli strumenti di Windows nativi.
Il sistema di controllo dei servizi directory in Windows Server 2008 fa fronte ad alcuni di questi problemi. Primo, sono disponibili quattro nuove sottocategorie di controllo per il controllo del servizio directory: accesso a Servizi di dominio, modifiche di Servizi di dominio, replica di Servizi di dominio e replica di Servizi di dominio dettagliata. Pertanto, se si desidera controllare le modifiche della directory, non è necessario esaminare tutti gli eventi di replica e di lettura. Tuttavia, se si desidera includere le eliminazioni degli oggetti nel registro di controllo, è necessario attivare l'accesso a Servizi di dominio. Questo determina la generazione di messaggi per tutti gli accessi agli oggetti DS; in sostanza, il risultato è la generazione di un numero eccessivo di messaggi. È responsabilità dello sviluppatore configurare i descrittori di protezione per generare i messaggi di controllo desiderati per gli oggetti a cui è interessato.
I messaggi di controllo sono stati sostanzialmente puliti in modo che siano leggibili e contengano i dati necessari. In particolare, le modifiche della directory generano le voci del registro di controllo che contengono i vecchi e i nuovi valori degli attributi modificati. Questo rappresenta un enorme miglioramento. L'unico svantaggio è che i valori nuovi e precedenti vengono visualizzati in voci del registro di controllo separate e, pertanto, è necessario metterle in correlazione per comprendere la modifica apportata. Molti prodotti di raccolta di registri di controllo aggiuntivi, tra cui Microsoft Audit Collection Services (ACS), supportano questo tipo di correlazione.

Miglioramenti all'interfaccia utente
Gli snap-in di MMC Utenti e computer di Active Directory, Siti e servizi e Domini e trust sono sempre state soluzioni adeguate per la gestione di Active Directory. In Windows Server 2008, gli strumenti di amministrazione di base sono stati puliti e forniscono un paio di nuove e interessanti funzionalità. Se si attiva Caratteristiche avanzate, nella finestra di dialogo delle proprietà per ciascun oggetto viene visualizzata una scheda aggiuntiva, Editor attributi. Si tratta della stessa scheda Editor attributi utilizzata da ADSIEdit, che consente di controllare e modificare tutti gli attributi dell'oggetto. La scheda ora offre una migliore decodifica degli attributi codificati, come l'attributo userAccountControl. Nella Figura 8 viene illustrata la facilità di integrazione dell'editor attributi.
Figura 8 Editor attributi in Utenti e computer di Active Directory
Figura 8 Editor attributi in Utenti e computer di Active Directory

Conclusioni
A parte i punti chiave discussi in questo articolo, in ADDS di Windows Server 2008 sono stati introdotti numerosi altri miglioramenti. Ad esempio, KDC utilizza la tecnologia Advanced Encryption Standard a 256 bit (AES-256) nel caso in cui il dominio si trovi nel livello di funzionalità del dominio di Windows Server 2008. È possibile impedire l'eliminazione accidentale degli oggetti selezionando la casella appropriata nella scheda Oggetto per qualsiasi oggetto DS. Il motore Extensible Storage Engine che fornisce il servizio di gestione dei dati è stato migliorato e configurato per l'utilizzo della correzione di errori di bit singoli, riducendo la probabilità che un errore hardware o software nel sottosistema disco danneggi il DIT. Il servizio DNS avvia l'elaborazione delle richieste prima di aver caricato completamente il database DNS. Il modulo DC Locator è stato migliorato in modo che, in caso di errore durante il rilevamento di un controller di dominio nel sito desiderato, tenti di individuare un controller di dominio nel sito successivo più vicino anziché utilizzare semplicemente un qualsiasi controlller di dominio rilevato all'interno del dominio. L'utilità NTDSUTIL ora supporta i controller di dominio di sola lettura e le istantanee del servizio Copia Shadow del volume.
Chiaramente, Windows Server 2008 introduce un numero significativo di miglioramenti in Servizi di dominio Active Directory. Queste modifiche nell'insieme miglioreranno considerevolmente la protezione e la gestibilità di ADDS. L'aspetto più interessante, tuttavia, è che l'integrazione di Windows Server 2008 nell'ambiente Active Directory non implica una migrazione su larga scala: è un processo semplice e incrementale.

Gil Kirkpatrick è CTO di NetPro e si occupa dello sviluppo software per Active Directory dal 1996. In collaborazione con Guido Grillenmeier, che lavora presso HP, ha realizzato i noti workshop sul ripristino di emergenza in Active Directory. Gil è anche il fondatore della Directory Experts Conference (www.dec2008.com).


 Numero speciale Windows Server 2008: Introduzione a IIS 7.0
Numero speciale Windows Server 2008 Isaac Roybal

Introduzione a IIS 7.0
Panoramica:
  • Modifiche all'architettura di IIS 7.0
  • Gestione di IIS 7.0
  • Compatibilità con le versioni precedenti
  • Risoluzione dei problemi relativi a IIS 7.0

Ogni reparto IT è differente, in quanto ciascuno presenta una serie di esigenze e obiettivi univoci, in particolare nell'ambito dell'hosting di siti o servizi Web. I server Web potrebbero richiedere soluzioni differenti per soddisfare i requisiti dell'organizzazione; occorre inoltre considerare la sfida rappresentata dalla
replica su più server della "ricetta" ritenuta più appropriata e dalla necessità di garantire un'efficace gestione di tutti i server. Alcune delle modifiche più significative introdotte in IIS 7.0 ha lo scopo di assistere i reparti IT nel far fronte a questo tipo di esigenze durante la creazione di un server Web o di Web farm.
Scorrendo l'elenco di tutte le straordinarie funzionalità incluse in IIS 7.0, ero davvero entusiasta all'idea di condividere i dettagli di queste funzionalità con i miei lettori. Quando, tuttavia, mi sono reso conto dell'impossibilità di illustrarle tutte in un solo articolo, ho deciso di concentrare l'attenzione su alcune delle funzionalità e modifiche più significative di IIS 7.0. Per ulteriori informazioni, visitare il sito Web della community di IIS all'indirizzo IIS.net.

Nuova architettura
Le modifiche principali in IIS 7.0 sono correlate all'architettura, all'elaborazione delle richieste, al supporto del framework di applicazioni PHP e all'archivio di configurazione. Con IIS 6.0, le funzionalità rappresentavano in sostanza una soluzione del tipo "tutto o niente". Era necessario installare tutte le funzionalità ed era possibile personalizzare IIS solo utilizzando ISAPI.
IIS si basa sul presupposto che un amministratore IT desideri iniziare da un set di funzionalità di base e fare uso di eventuali funzionalità aggiuntive solo quando necessario e richiesto dall'ambiente in uso. Ogni amministratore conosce meglio di chiunque altri l'ambiente in cui opera e, pertanto, IIS fornisce gli elementi di base necessari per creare un server Web personalizzato. In tal modo, l'overhead amministrativo risulta ridotto grazie alla riduzione della superficie di attacco del server e all'eliminazione della necessità di aggiornamenti per i componenti che non vengono utilizzati. L'elemento chiave di questo nuovo approccio è rappresentato dall'architettura modulare di IIS 7.0.
IIS 7.0 prevede una nuova progettazione che consente di scegliere le funzionalità, note come moduli, da installare nel server. Questi moduli sono collegati direttamente alla pipeline di elaborazione della richiesta integrata. Questa nuova progettazione modulare arreca diversi vantaggi, tra cui la riduzione della superficie di attacco e dell'occupazione di spazio del server Web.
IIS include attualmente 40 moduli predefiniti; ad esempio, l'autenticazione di base, l'autenticazione anonima e l'autenticazione di Windows® sono ora singoli moduli che è possibile aggiungere alla pipeline di elaborazione della richiesta in modo indipendente. Per semplicità, i moduli vengono raggruppati in otto sottocategorie (vedere la Figura 1).
Figura 1 I moduli di IIS 7.0 vengono classificati in otto aree funzionali
Figura 1 I moduli di IIS 7.0 vengono classificati in otto aree funzionali
Ne consegue che ora è possibile creare un server Web personalizzato adattato perfettamente alle esigenze specifiche dell'ambiente in uso. Cosa accade tuttavia se si necessita di una funzionalità che non viene fornita dai 40 moduli predefiniti, ad esempio una sorta di autenticazione personalizzata o un modificatore di contenuto? Nessun problema. Per soddisfare questa esigenza, è possibile scrivere un modulo in codice nativo o gestito e aggiungerlo direttamente alla pipeline. Questo consente inoltre a Microsoft di scrivere e rilasciare nuovi moduli singolarmente in modo che non sia necessario attendere il rilascio del successivo service pack o della successiva versione principale del prodotto. IIS 7.0 consente inoltre di sovrascrivere uno dei 40 moduli predefiniti con moduli personalizzati. Per ulteriori informazioni su come creare un modulo personalizzato, visitare il sito Web all'indirizzo IIS.net.

Pipeline di elaborazione della richiesta integrata
È possibile considerare la pipeline di elaborazione della richiesta integrata come un insieme fondamentale di passaggi lineari che è necessario eseguire ogni volta che una pagina viene gestita (come illustrato nella Figura 2). In genere, è necessario eseguire un'autenticazione, seguita dall'autorizzazione a recuperare il contenuto, dalla determinazione ed esecuzione del gestore necessario per tale contenuto, dall'esecuzione di tutte le registrazioni necessarie e, infine, dall'invio di una risposta. La pipeline di elaborazione della richiesta integrata fornisce a IIS 7.0 la flessibilità di eseguire contemporaneamente diversi framework di applicazione. È possibile, ad esempio, eseguire l'autenticazione basata su form per il contenuto PHP con un modulo di registrazione personalizzato, il tutto nella stessa pipeline.
Figura 2 Moduli e pipeline integrata di IIS 7.0
Figura 2 Moduli e pipeline integrata di IIS 7.0
Ogni sito Web sul server prevede una pipeline di elaborazione della richiesta integrata e può essere eseguito in una delle due modalità seguenti: integrata e classica. La modalità integrata, che rappresenta l'impostazione predefinita, consente di aggiungere specifiche funzionalità alla pipeline, fornendo un controllo granulare sull'elaborazione della richiesta. Per garantire la compatibilità, la modalità classica riproduce le funzionalità IIS 6.0/ISAPI tramite un modulo ISAPI nella pipeline. Questa modalità è molto utile quando si esegue la migrazione delle applicazioni in IIS 7.0.

Installazione predefinita
A questo punto è opportuno illustrare come installare il nuovo server Web modulare. Se si esamina l'installazione predefinita di IIS 7.0, si noterà che prevede solo 10 moduli (se si include il servizio Attivazione processo Windows). L'installazione di IIS 7.0 fornisce le funzionalità di base di IIS quando si installa il ruolo di server Web, specificamente solo i moduli necessari per gestire il contenuto statico, come il normale linguaggio HTML o ASP classico. La scelta dei componenti da installare nel server è responsabilità dell'utente. Di seguito vengono riportate le funzionalità incluse in un'installazione predefinita:
  • Funzionalità HTTP comuni, come Contenuto statico, Documento predefinito, Esplorazione directory ed Errori HTTP
  • Funzionalità di integrità e diagnostica, come Registrazione HTTP e Monitor richieste
  • Funzionalità di protezione come Filtro richieste
  • Funzionalità relative alle prestazioni come Compressione contenuto statico
  • Strumenti di gestione, tra cui Console di Gestione IIS
  • Servizio Attivazione processo Windows
Come è possibile osservare, si tratta di un'installazione minima del server che non include ASP.NET o altre nuove funzionalità di IIS 7.0, come le funzionalità di diagnostica e di risoluzione dei problemi. L'attivazione di funzionalità aggiuntive sul server, ad esempio la capacità di fornire contenuti dinamici, come ASP.NET e FastCGI (PHP), è un'operazione piuttosto semplice. Selezionare il set di moduli che si desidera installare da "Aggiungi servizi ruolo" del ruolo Web all'interno di Windows Server® 2008 Server Manager.

Nuovo archivio di configurazione
Un'altra modifica importante apportata a IIS 7.0 è rappresentata dal nuovo archivio di configurazione. La metabase, ora un componente facoltativo per la compatibilità con le versioni precedenti, è stata sostituita da un sistema di configurazione XML. Si dirà: "Ma la metabase era XML!" Sì, è vero. Tuttavia, la metabase era piuttosto complicata da leggere. Pertanto, è stata sostituita con un sistema XML più flessibile. Come ASP.NET, IIS 7.0 prevede l'utilizzo di file .config puliti, semplici, portabili e facili da leggere.
Il passaggio a questo formato implica che il sistema di configurazione ora è indipendente dal computer, a differenza della metabase immessa in un singolo computer. Di conseguenza, ora è possibile eseguire facilmente il porting del sistema di configurazione su altri server con una semplice operazione di trascinamento o con il comando xcopy.
Questo nuovo sistema di configurazione offre inoltre vantaggi straordinari per le Web farm grazie all'utilizzo di una nuova funzionalità di IIS 7.0 denominata Configurazione condivisa. Poiché questo nuovo sistema di configurazione è portabile, è possibile condividere un unico file .config master tra tutti i nodi all'interno della farm. Configurazione condivisa consente di esportare la configurazione di un server di preproduzione noto e di condividerlo nell'ambiente di produzione o di utilizzo.
Durante l'esportazione del file .config è necessario specificare una password della chiave di crittografia. Questa password protegge il file .config da eventuali tentativi di un server Web non autorizzato di riprodurre il file .config del server senza autorizzazione.
L'attivazione della funzionalità Configurazione condivisa è molto semplice. Nel nodo del server di Gestione IIS, selezionare Configurazione Condivisa, sotto la sezione Gestione del riquadro delle attività. Selezionare semplicemente "Abilita configurazione condivisa," fornire il percorso fisico della configurazione da condividere (in genere si tratta di una condivisione UNC), immettere le credenziali necessarie per accedere al percorso fisico e fare clic su Applica. Una volta individuato il file .config , verrà chiesto di immettere la password di crittografia. Dopo aver completato questo processo, riavviare Gestione IIS in modo che venga caricato il nuovo file .config.
La struttura del nuovo sistema di configurazione è diversa da quella precedente; è opportuno pertanto illustrarne gli elementi di base. Come illustrato nella Figura 3, la configurazione di IIS 7.0 è stata suddivisa in due categorie: impostazioni a livello di server e impostazioni specifiche del sito. Tutte le impostazioni a livello di server vengono memorizzate nel file applicationhost.config, situato in %systemroot%\windows\system32\inetsrv\config. Questo file contiene tutti i moduli installati, i siti sul server e così via. Le impostazioni specifiche del sito vengono memorizzate in singoli file web.config.
Figura 3 Per le impostazioni a livello di server è disponibile un solo file .config, ma per ciascun sito Web su tale server sono presenti singoli file .config separati
Figura 3 Per le impostazioni a livello di server è disponibile un solo file .config, ma per ciascun sito Web su tale server sono presenti singoli file .config separati
Se si è utilizzato ASP.NET, si avrà probabilmente dimestichezza con i file web.config. In IIS 7.0 i file web.config vengono utilizzati per memorizzare le impostazioni specifiche di singoli siti Web, come impostazioni predefinite di applicazioni e documenti di un sito, e le impostazioni ASP.NET. Questo implica che sarà disponibile un file web.config per ogni sito sul server.
Il file web.config di un sito risiede nel percorso fisico del sito, ad esempio %systemroot%\inetpub\wwwroot. Questa progettazione produce gli stessi vantaggi di portabilità notati in precedenza, ma a livello di sito. È possibile, ad esempio, sviluppare facilmente un sito su un server di test e successivamente copiare tramite trascinamento o xcopy i file dell'applicazione e web.config del sito su un server di produzione.
Ogniqualvolta si esegue il porting o si condividono i file .config, controllare le informazioni specifiche del computer, come indirizzi IP e lettere di unità. IIS 7.0 fornisce un rimedio per questa possibile distrazione grazie al supporto per le variabili di ambiente del sistema operativo (come %systemroot%). Assicurarsi inoltre che sui server di test e di produzione vengano installati gli stessi set di moduli, in modo da evitare errori di applicazione imprevisti. È possibile che si verifichino errori anche nel caso in cui il file web.config faccia riferimento a un modulo che non è installato o un modulo predefinito sia in conflitto con un modulo personalizzato.

Gestione del server Web
A questo punto si ha a disposizione un nuovo straordinario server Web personalizzabile, flessibile e portabile. Come si prevede di gestirlo? La gestione è stata una fase importante dei processi di pianificazione e creazione di IIS 7.0, che prevede pertanto diversi metodi per gestire le attività amministrative.
Le preferenze di gestione in genere rientrano in almeno una delle tre categorie seguenti: amministrazione di tipo point-and-click dall'interfaccia utente, immissione di comandi nella riga di comando e scrittura di script per automatizzare il più possibile le attività. Iniziamo con l'interfaccia utente.
In IIS 6.0, lo snap-in Interfaccia utente di Microsoft® Management Console (MMC) prevedeva due note visualizzazioni di base: la visualizzazione albero e la visualizzazione a schede. Per visualizzare un'impostazione, era necessario fare clic con il pulsante destro del mouse e selezionare Proprietà; in tal modo venivano visualizzati un gruppo di schede, oltre a pulsanti di opzione e caselle di controllo.
Per fortuna, l'interfaccia utente in IIS 7.0 è stata completamente rinnovata. La nuova interfaccia utente, denominata Gestione IIS, è stata progettata per consentire un approccio orientato alle attività, come illustrato nella Figura 4. È inoltre disponibile la funzionalità Gestione remota per i client di livello inferiore come Windows XP e Windows Server 2003, che è possibile scaricare da IIS.net/downloads.
Figura 4 Nuova interfaccia utente in IIS 7.0
Figura 4 Nuova interfaccia utente in IIS 7.0
La nuova interfaccia utente è costituita dal riquadro Connessioni nella parte sinistra, dal riquadro Azioni nella parte destra e dal riquadro delle attività o area di lavoro nella parte centrale. L'albero di gestione delle connessioni nella parte sinistra è simile alla visualizzazione albero di IIS 6.0 con nodi padre e figlio. Una novità per la visualizzazione albero è rappresentata dalla capacità di creare nuove connessioni, salvare le connessioni correnti o eliminare le connessioni esistenti. Il riquadro delle attività rappresenta il miglioramento più importante dell'interfaccia utente e prevede due visualizzazioni. La visualizzazione funzionalità include tutte le proprietà configurabili della precedente visualizzazione a schede di IIS e le raggruppa in base all'area amministrativa, come IIS, gestione e protezione.
Anche le proprietà ASP.NET sono state integrate in Gestione IIS, eliminando la necessità di utilizzare uno snap-in di MMC aggiuntivo. A ogni proprietà configurabile è associata una specifica icona, semplificandone l'individuazione. Poiché Gestione IIS è stato creato come un'applicazione Windows Forms, è possibile aggiungere facilmente icone di plug-in per qualsiasi funzionalità o modulo personalizzato.
La seconda visualizzazione del riquadro delle attività è la visualizzazione contenuto, che è molto simile a IIS 6.0, in quanto consente di visualizzare gli elementi presenti nella directory del contenuto di un sito e di eseguire azioni su tale contenuto. La novità è rappresentata dalla capacità di selezionare specifici contenuti, ad esempio una pagina Web, e passare alla visualizzazione funzionalità per richiamare determinate impostazioni nel contenuto selezionato, il che fornisce un controllo granulare a livello della pagina.

Altri metodi di gestione
Per coloro che preferiscono la riga di comando, è disponibile un nuovo e potente strumento, APPCMD.exe, che consente di eseguire attività semplici, come l'arresto di un sito o il backup del file .config corrente, nonché attività più complesse, come la ricerca all'interno dello schema della configurazione. La sintassi è molto semplice:
APPCMD (command) (object-type) <identifier> </parameter1:value1 ...>.
Per elencare tutti gli oggetti disponibili per APPCMD, digitare:
APPCMD /?
In alternativa, se si desidera visualizzare i comandi disponibili per un determinato tipo di oggetto, immettere:
APPCMD (object-type) /?
Per tutti i programmatori, sono stati aggiunti a IIS 7.0 un'API di codice gestito, denominata Microsoft.Web.Administration, e un nuovo provider Strumentazione gestione Windows (WMI). Questi due metodi offrono una miriade di opzioni per la creazione di script, l'automazione e la scrittura di strumenti per la gestione di IIS 7.0. È possibile utilizzare entrambi i metodi con Windows PowerShell®, mentre il provider WMI può essere utilizzato anche con VBScript e JScript®. Per ulteriori informazioni, visitare il sito Web all'indirizzo blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx.

Gestione remota e amministrazione delegata
IIS 7.0 offre nuovi metodi per la gestione remota del server, dei siti e delle applicazioni Web e fornisce diritti di amministrazione delegata per gli utenti non amministratori. Esaminiamo innanzitutto le nuove funzionalità di gestione remota e i relativi vantaggi.
In passato, la gestione remota di un server IIS avveniva in due modi: utilizzando il sito Web di gestione remota o utilizzando Desktop remoto/Servizi terminal per accedere all'interfaccia utente. Tuttavia, se ci si trovava all'esterno del firewall o al di fuori della sede dell'organizzazione, queste opzioni non erano molto utili. IIS 7.0 risolve questo problema creando funzionalità di gestione remota direttamente nell'interfaccia utente che funzionano tramite protocolli HTTPS di facile integrazione con i firewall.
La gestione remota in IIS 7.0 offre diversi vantaggi. Innanzitutto, è possibile utilizzare l'interfaccia utente come se si fosse connessi localmente. Secondo, non è necessario aprire le porte sul firewall, in quanto la comunicazione avviene tramite HTTPS. Infine, ora è possibile gestire diversi server da una singola interfaccia utente. Non è necessario tenere aperte contemporaneamente più finestre di Desktop remoto o del sito Web remoto.
Il servizio di gestione remota effettivo all'interno di IIS 7.0 è essenzialmente un'applicazione Web di piccole dimensioni che viene eseguita come servizio separato con un account di servizio locale di Windows NT®, denominato NT Service\WMSVC. Questa progettazione garantisce il corretto funzionamento della funzionalità di gestione remota anche nel caso in cui il server IIS non risponda.
Come la maggior parte delle funzionalità di IIS 7.0, per motivi di protezione, la gestione remota non è installata per impostazione predefinita. Per installare le funzionalità di gestione remota, aggiungere i servizi per il ruolo di server Web nello strumento Server Manager di Windows Server 2008, disponibile in Strumenti di gestione. Una volta installata questa funzionalità, è necessario attivare le connessioni remote e avviare il servizio WMSVC in quanto, per impostazione predefinita, è arrestato.
L'impostazione di avvio predefinita del servizio WMSVC è manuale. Se si desidera avviare il servizio automaticamente dopo un riavvio, è necessario modificare l'impostazione in automatico. Questa operazione può essere eseguita dalla riga di comando digitando:
sc config WMSVC start=auto
Quando si attivano le connessioni remote tramite il servizio di gestione, viene visualizzato un elenco di impostazioni, come Credenziali di identità, Connessioni e Restrizioni indirizzi IPV4. A questo punto, l'unica decisione critica consiste nel determinare la serie di credenziali di identità a cui concedere l'autorizzazione per la connessione a IIS 7.0: solo le credenziali di Windows o le credenziali di Windows e di Gestione IIS.
La prima opzione indica che si desidera concedere l'autorizzazione solo agli account utente di Windows, sia locali che di dominio. La seconda opzione coinvolge gli utenti di Windows e un tipo di account completamente nuovo in IIS 7.0, che non è associato agli account utente di Windows: Utenti Gestione IIS. Con Utenti Gestione IIS gli amministratori hanno la possibilità di creare account utente che sono noti solo nel contesto di IIS 7.0 e non hanno accesso al sistema operativo. Infine, per impostazione predefinita, IIS fornisce un certificato autofirmato, ma è consigliabile aggiungere un certificato SSL firmato valido. A questo punto, applicare l'impostazione e avviare il servizio.
Per garantire un ulteriore livello di controllo e di protezione, gli amministratori IT possono delegare in modo protetto le attività di amministrazione di singoli siti o applicazioni Web agli utenti non dotati di privilegi di amministratore.
L'amministrazione delegata è essenzialmente amministrazione remota, ma limita l'ambito di accede a singoli siti o applicazioni Web. Sotto questo aspetto la funzionalità Utenti Gestione IIS si rivela particolarmente utile. È possibile creare utenti IIS per i proprietari di siti fuori sede e delegare l'autorizzazione all'amministrazione del relativo sito o applicazione. Questi utenti non hanno accesso alle impostazioni a livello di server e sono limitati solo alle impostazioni per il relativo specifico sito o applicazione Web.
È inoltre possibile specificare le funzionalità e le impostazioni che gli utenti possono modificare e visualizzare nell'interfaccia utente. Se, ad esempio, si desidera che un utente non modifichi il tipo di autenticazione utilizzato per il relativo sito, è possibile impostare tale funzionalità in modo che sia di sola lettura o non ereditata. Quando una funzionalità è di sola lettura, gli utenti possono comunque accedere alla funzionalità e determinare l'impostazione ma non possono apportare modifiche; con l'impostazione non ereditata, l'icona della funzionalità non viene visualizzata nella visualizzazione di Gestione IIS dell'utente delegato. Questo tipo di delega delle funzionalità consente di fornire ad altri utenti un accesso rigidamente controllato senza tuttavia fornire il controllo amministrativo sul server Web.

Transizione a IIS 7.0
Durante la fase di progettazione di IIS 7.0, lo scopo del team è stato assicurare una transizione senza problemi alla nuova applicazione, consentendo l'utilizzo di alcuni degli investimenti esistenti negli script e negli strumenti di gestione per IIS 6.0. Particolare attenzione è stata dedicata alla compatibilità con le versioni precedenti di IIS 7.0, in modo da garantirne il corretto funzionamento con gli script di IIS 6.0. È disponibile un set completo di strumenti, dalla compatibilità con la metabase IIS 6.0 alla console di gestione effettiva di IIS 6.0, che è possibile installare nel nodo per la compatibilità di gestione con IIS 6.0.
L'infrastruttura Compatibilità metabase IIS 6.0 prevede l'utilizzo del componente ADOMapper. Questo componente consente di eseguire gli script della metabase ABO (Admin Base Object) e ADSI (Active Directory Services Interface) sul nuovo sistema di configurazione, limitandolo solo ai tipi di operazioni eseguibili con IIS 6.0. Pertanto, tale componente non è in grado di leggere o scrivere le nuove proprietà di IIS 7.0, di accedere ai nuovi dati di runtime o di leggere e scrivere le proprietà ASP.NET o i file web.config.

Risoluzione dei problemi e diagnostica
La risoluzione dei problemi e la diagnostica sono sempre state attività dispendiose in termini di tempo. Un'analisi completa dei registri e il tentativo di riprodurre un problema in una Web farm di grandi dimensioni o persino su un singolo server possono rivelarsi attività piuttosto complesse. IIS 7.0 include uno strumento, Traccia richieste non riuscite, che consente di alleviare parte delle difficoltà associate a queste attività e di ridurre inutili perdite di tempo. Questo strumento può rivelarsi utile in molte situazioni, ad esempio nei casi in cui una richiesta si blocchi o produca errori o per l'analisi dei problemi di autenticazione e autorizzazione.
Lo strumento Traccia richieste non riuscite utilizza le regole di traccia come criteri per la ricerca di errori. Le regole di traccia possono essere create per cercare determinati tipi di comportamento o errori specificando il tipo di contenuto che si desidera tracciare, ad esempio tutto il contenuto sul server, solo contenuto ASP.NET o contenuto personalizzato come PHP, e le condizioni in cui occorre eseguire la traccia delle richieste, ad esempio un determinato codice di stato restituito, il tempo impiegato per servire la pagina, la gravità dell'evento o una combinazione di questi elementi.
Si supponga, ad esempio, che gli utenti segnalino che un sito impiega troppo tempo per il caricamento. Questo scenario è piuttosto complicato da riprodurre in qualsiasi caso, ma soprattutto nel caso in cui il sito preveda migliaia di accessi ogni ora. Con la funzionalità Traccia richieste non riuscite, quando una pagina impiega per il caricamento una quantità di tempo ritenuta eccessiva, ad esempio due secondi, è sufficiente aggiungere una regola di traccia per avviare la registrazione e attendere che il server riproduca automaticamente il problema (vedere la Figura 5).
Figura 5 Utilizzo della funzionalità Traccia richieste non riuscite per la risoluzione dei problemi
Figura 5 Utilizzo della funzionalità Traccia richieste non riuscite per la risoluzione dei problemi
La differenza tra Traccia richieste non riuscite e la registrazione tradizionale è rappresentata dal fatto che la prima prevede la registrazione solo quando viene rilevato un particolare criterio di richiesta non riuscita. Il file di registro stesso include un foglio di stile XML, che ne semplifica la lettura. Come la maggior parte delle funzionalità di IIS 7.0, questa funzionalità non è installata per impostazione predefinita ed è disponibile nella sezione Integrità e diagnostica dell'installazione. È necessario inoltre attivarla in IIS Manager.
IIS 7.0 rappresenta un grande passo in avanti per tutti gli amministratori. La nuova architettura e le nuove funzionalità forniscono l'agilità e la flessibilità necessarie per adattarsi a un ambiente in continua evoluzione. Con le funzionalità di gestione, gli strumenti per la compatibilità con le versioni precedenti e le funzionalità di risoluzione dei problemi, IIS 7.0 è ormai pronto per la distribuzione e per interagire senza problemi con l'ambiente esistente.

Isaac Roybal è Product Manager del team di Windows Server in Microsoft. La sua attività è incentrata principalmente sulle soluzioni Web correlate a Windows Server. Isaac ha lavorato con Windows Server sin dal rilascio di Windows NT 3.51 e IIS 4.0. In precedenza, ha ricoperto la carica di Operations Program Manager per il gruppo Office Internet Platform & Operations. Ha conseguito la certificazione MCSE in Windows NT 4.0, Windows 2000 e Windows Server 2003.


 Numero speciale: Windows Server 2008: Accesso alla rete basato su criteri con Windows Server 2008
Numero speciale: Windows Server 2008 Ian Hameroff and Amith Krishnan

Accesso alla rete basato su criteri con Windows Server 2008
Panoramica:
  • Bilanciamento di accessibilità e protezione della rete
  • Un approccio all'accesso alla rete basato sui criteri
  • Nuove tecnologie di protezione in Windows Server 2008

Si è scritto molto della scomparsa dei perimetri di rete tradizionali, provocata da una forza lavoro sempre più mobile e dalla diversità crescente di utenti e dispositivi che richiedono di
accedere alle risorse IT di un'organizzazione. Per incrementare la produttività, utenti e proprietari di prodotti line-of-business richiedono connessioni che siano fluide e libere da procedure noiose. A questa situazione già complessa si aggiunge l'aumento delle normative, un paesaggio delle minacce in continua evoluzione e i rischi associati al decentramento dei dati.
Gli amministratori di Windows® si trovano così a dover fronteggiare una difficile sfida: come garantire un facile accesso alle risorse pur continuando a soddisfare i requisiti sempre più stringenti di protezione delle informazioni e della rete.
Tutte queste sfide potrebbero non avere una soluzione unica, ma gli amministratori di Windows dispongono di molti strumenti che consentono di migliorare i controlli di protezione (come i firewall di confine) già in uso. Un ottimo metodo per raggiungere un punto di equilibrio appropriato tra accessibilità e protezione consiste nel passare dai modelli di connettività tradizionali a un modello che tenti di definire l'accesso alla rete in modo più logico e basato su criteri definiti.

Approccio di accesso alla rete basato su criteri
Risorse sulle connessioni in rete
  • IPSec
  • Windows Firewall con protezione avanzata
  • Isolamento dei server e dei domini
  • Protezione accesso alla rete (NAP) per Windows Server 2008

Lo scopo di un accesso alla rete basato sui criteri è rimuovere le limitazioni che si incontrano quando si tenta di basare l'attendibilità principalmente sui confini della topologia di rete. È possibile, ad esempio, determinare che un dispositivo è attendibile e autorizzato a connettersi ai server che utilizzano un'applicazione CRM solo perché è collegato a una delle porte dello switch Ethernet dietro il firewall aziendale?
Piuttosto, il nuovo modello adotta decisioni relative all'accesso in base sia alle condizioni di protezione del dispositivo che all'identità dell'utente che richiede l'accesso, indipendentemente dalla posizione. Dopo l'autenticazione, sarà possibile utilizzare il medesimo framework per autorizzare l'accesso a determinate informazioni e risorse.
Il passaggio da un atteggiamento difensivo a uno più orientato all'accesso richiede molti ingredienti chiave, tra cui l'adozione di meccanismi in grado di convalidare l'identità e la conformità ai criteri degli host che si connettono, l'emissione di identità utente attendibili e il controllo dinamico dell'accesso alla rete basato su questi attributi. Per semplificare la gestione di queste varie parti mobili, un altro componente importante è un archivio criteri centralizzato.
L'adozione di un approccio basato sui criteri può aiutare a fondere insieme molti diversi controlli di accesso alla rete e di protezione degli host all'interno di una soluzione più completa. In tal modo è possibile impostare le regole fondamentali di accesso alla rete a un livello logico superiore all'infrastruttura della connettività, con un'evoluzione delle procedure consigliate di difesa tradizionali.
Quando, ad esempio, un utente si connette con il proprio computer portatile alla rete wireless dell'organizzazione, è possibile verificare la conformità del dispositivo con i requisiti di configurazione della protezione più recenti. Una volta determinato che il computer portatile è dotato di tutti gli aggiornamenti antivirus correnti e delle patch critiche per la protezione e che ha attivati tutti i controlli di protezione dell'endpoint, come un firewall dell'host, è possibile concedere l'accesso alla rete aziendale. Quindi, quando l'utente tenta di accedere a un'applicazione aziendale, è possibile utilizzare la combinazione di stato di integrità del computer portatile e di identità di rete dell'utente per determinare se questi è autorizzato a connettersi alle risorse che ospitano l'applicazione. Quando si opera a questo livello logico, al di sopra dell'infrastruttura fisica della rete, i criteri possono essere applicati con continuità, anche se l'utente passa da una connessione wireless a una cablata o addirittura a una connessione ad accesso remoto.
Quando implementato, l'accesso alla rete basato sui criteri può garantire procedure di connessione più semplici per gli utenti, senza sacrificare la protezione. Per gli amministratori, l'esecuzione dei controlli di accesso alla rete a livello più alto rispetto alle porte dello switch o alle configurazioni del gateway di Accesso remote può garantire una gestione più semplice. In entrambi i casi il risultato finale è una maggiore produttività e un miglioramento complessivo dell'integrità della aziendale, anche quando le reti funzionano da host a fronte di parti con diritti di accesso diversi, come gli ospiti (invitati o meno), i fornitori, i partner e i dipendenti.
Come accade per qualsiasi progetto di protezione, il primo passaggio consiste nell'implementare i mezzi di accesso alla rete basato sui criteri, sviluppando una serie di criteri operativi globali. In genere questo passaggio prevede la definizione delle linee guida per:
  • Conformità della protezione del dispositivo: cosa si intende per dispositivo integro?
  • Suddivisione logica in zone della rete: in che modo i dispositivi non integri verranno separati da quelli autorizzati?
  • Gestione del rischio per le informazioni: in che modo vengono classificati e protetti dagli attacchi i dati riservati?
Per fortuna, sono disponibili molte risorse relative allo sviluppo dei criteri presso il Microsoft® TechNet Security Center (microsoft.com/technet/security).
Dopo aver sviluppato i criteri di accesso, sarà necessario scegliere le tecnologie in grado di distribuirli facilmente e applicarli con efficacia. Per questi scopi, lo strumento perfetto è Windows Server® 2008, perché non solo Windows Server 2008 è il Windows Server meglio protetto di sempre, ma anche perché offre agli amministratori una piattaforma di protezione più robusta, ideale come pietra angolare di una soluzione di accesso alla rete basata sui criteri. Nel lungo elenco di funzionalità nuove e migliorate di Windows Server 2008, sono presenti molti degli ingredienti necessari per implementare un accesso alla rete sicuro e basato sui criteri, che garantisca la protezione delle informazioni riservate dagli attacchi.

Le reti di nuova generazione
Lo stack TCP/IP di nuova generazione costituisce il nucleo dei miglioramenti apportati alla protezione della rete in Windows Server 2008, un aggiornamento importante delle funzionalità di connessione in rete e dei servizi correlati della piattaforma. Oltre a garantire migliori prestazioni della rete e una maggiore scalabilità, Windows Server 2008 irrobustisce la protezione grazie a una serie di funzionalità di rete integrate che stabiliscono una solida base su cui costruire una soluzione di accesso alla rete basata sui criteri.
Internet Protocol Security (IPSec) è una delle funzionalità che è stata considerevolmente migliorata in Windows Server 2008, in modo da assumere un ruolo fondamentale in un approccio di accesso alla rete basato sui criteri. La novità non è tanto nell'utilizzare IPSec come un protocollo di tunneling e crittografia, quanto nella possibilità di sfruttare le sue funzionalità di autenticazione di rete da host a host. Inoltre, poiché funziona a Livello 3, IPSec può essere utilizzato per applicare i criteri di accesso alla rete a una varietà di tipi di rete.
Per facilitare l'implementazione dei controlli per l'accesso alla rete basato su IPSec, in Windows Server 2008 è stata introdotta una lunga serie di miglioramenti e nuove funzionalità mirate a semplificare la creazione, l'applicazione e la gestione dei criteri. Il numero e i tipi dei metodi di autenticazione di IPSec, ad esempio, sono stati aumentati. Questo risultato è stato ottenuto con l'introduzione di AuthIP, un'estensione del protocollo IKE (Internet Key Exchange). AuthIP consente di creare regole di protezione della connessione personalizzate (un altro nome per i criteri IPSec in Windows Server 2008) in cui ai peer in comunicazione viene richiesto di autenticarsi a vicenda, non solo con le credenziali del computer ma, facoltativamente, anche con credenziali di utente o integrità. Questa ulteriore flessibilità consente di progettare reti logiche molto sofisticate, senza dover aggiornare l'infrastruttura di switch e router.

Windows Firewall con protezione avanzata
Il nuovo Windows Firewall con protezione avanzata è basato sulle funzionalità IPSec appena descritte. Grazie alla combinazione di regole di protezione della connessione IPSec con i filtri del firewall in un singolo criterio, il nuovo Windows Firewall costituisce un'altra dimensione di accesso alla rete basata sui criteri: azioni del firewall di autenticazione più intelligenti.
Come illustrato nella Figura 1, è possibile scegliere fra tre opzioni durante la definizione dell'azione specifica che deve essere eseguita da un filtro del firewall in ingresso o in uscita: consentire, bloccare o consentire solo se protetta. Quando si seleziona come azione l'opzione "Consenti solo connessioni protette", Windows Firewall sfrutta le funzionalità di autenticazione in rete da host a host di IPSec per determinare se un host o un utente che richiede la connessione deve essere approvato in base ai criteri definiti. La regola del firewall consente di definire quali utenti, computer e gruppi hanno diritto a connettersi. È utile notare che in questo modo si aggiunge un altro livello di protezione, integrando i controlli esistenti sull'accesso a livello di sistema operativo e applicazione.
Figura 1 Definizione delle regole di autenticazione del firewall
Figura 1 Definizione delle regole di autenticazione del firewall
A questo punto, inizia ad apparire chiaro come sia possibile fondere insieme questi controlli di protezione della rete mediante dei criteri centralizzati, per una gestione più efficace e scalabile dell'accesso alla rete.
Tornando all'esempio di CRM: l'amministratore può creare una regola per le connessioni in entrata per i server, eseguendo l'applicazione CRM dell'azienda (tramite le porte dell'eseguibile del programma o del servizio) con l'opzione "Consenti solo connessioni protette" attivata. All'interno dello stesso criterio del firewall, l'amministratore può specificare che solo i membri del gruppo degli utenti dell'applicazione CRM possono connettersi a questa applicazione di rete, come illustrato nella Figura 2. Se si assume questo stesso concetto e lo si applica a tutte le comunicazioni di rete fra tutti i computer gestiti sulla rete, il risultato è l'aggiunta di un livello di isolamento di dominio e server alla strategia di accesso alla rete basata su criteri.
Figura 2 Gli amministratori possono specificare chi può connettersi in base a questi criteri
Figura 2 Gli amministratori possono specificare chi può connettersi in base a questi criteri

Isolamento dei server e dei domini
In molte organizzazioni è in continua crescita il numero di ospiti e di altri dispositivi non gestiti che si connettono alle reti, quindi assume importanza critica la disponibilità di mezzi in grado di separare e proteggere gli host attendibili. Esistono, per fortuna, molti modi per isolare i computer gestiti e attendibili dagli altri dispositivi presenti sulla rete. Tuttavia, è bene sapere che molte di queste opzioni sono costose (richiedono, ad esempio, sistemi di cablaggio fisici dedicati) e di difficile gestione (come le VLAN basate su switch) con l'espandersi della rete.
L'isolamento dominio e server può rappresentare un mezzo meno costoso e gestibile per la segmentazione dell'ambiente in reti logicamente isolate e protette. Come illustrato dalla Figura 3, si utilizzano essenzialmente le stesse regole di protezione della connessione (vale a dire, i criteri IPSec) già menzionati, ma li si associa a tutti i computer gestiti tramite i Criteri di gruppo di Active Directory®. Ne risulta un criterio di accesso alla rete che richiede a tutti i peer di autenticarsi a vicenda prima di poter avviare qualsiasi comunicazione. Poiché l'isolamento ha luogo al livello 3, l'applicazione di questi controlli di accesso si estende a hub, switch e router senza tenere conto dei confini fisici e geografici.
Figura 3 Definizione dei requisiti di autenticazione in modo che corrispondano alle esigenze di accesso della propria rete
Figura 3 Definizione dei requisiti di autenticazione in modo che corrispondano alle esigenze di accesso della propria rete
Per creare una rete isolata, i vari computer della rete devono essere separati in base al tipo di accesso desiderato. È possibile definire i criteri in modo che i computer su una rete isolata possano avviare la comunicazione con tutti i computer sulla rete, compresi quelli che non si trovano nella rete isolata. Al contrario, i computer che non sono nella rete isolata non possono avviare comunicazioni con i computer che sono all'interno della rete isolata. In effetti, i computer nella rete isolata ignorano tutte le richieste di comunicazione provenienti da computer all'esterno della rete isolata.
Per applicare il criterio di rete, si utilizzano un dominio di Active Directory e l'appartenenza al dominio. I computer membri del dominio accettano solo comunicazioni autenticate e protette da altri computer membri del dominio. È inoltre possibile definire i criteri in modo che tutte le comunicazioni all'interno del dominio isolato vengano crittografate.
L'isolamento di server e dominio comporta notevoli vantaggi in termini di costi, poiché non è necessario apportare alcuna modifica significativa all'infrastruttura di rete esistente o creare nuove applicazioni. Questa soluzione crea un velo di protezione basato sui criteri che non solo aiuta a difendersi contro costosi attacchi alla rete e accessi non autorizzati alle risorse di rete attendibili, ma non richiede una gestione continua basata sulle modifiche alla topologia di rete.

Protezione accesso alla rete
Come descritto in precedenza, la soluzione di isolamento di server e dominio garantisce la separazione logica dei computer dei server sulla rete. Se da un lato questa soluzione aiuta a impedire gli accessi non autorizzati alla rete, non esiste alcuna garanzia che il rischio alla protezione non possa provenire da un computer autorizzato.
Protezione accesso alla rete è una piattaforma incorporata in Windows Server 2008 che consente di verificare se i computer che si connettono a una rete, o che comunicano su una rete, sono conformi ai requisiti di integrità del sistema (ovvero, conformità a criteri e protezione) definiti.
Spesso sono proprio gli utenti autorizzati a propagare virus e spyware sulla rete. Quando, ad esempio, un utente va in ferie, è possibile che al ritorno il suo computer non sia più conforme ai requisiti di protezione impostati dall'amministratore. Le ripercussioni di questo scenario possono essere serie se al computer non arriva una patch o una firma rilasciata durante l'assenza dell'utente.
Un amministratore non è oggettivamente in grado di gestire e registrare le connessioni alla rete di ciascun utente. È necessario uno strumento automatico in grado di verificare la conformità in termini di integrità di ciascun computer che si connette alla rete, ripristinando gli eventuali computer non conformi in base a dei criteri centralizzati. Questa è la funzione di Protezione accesso alla rete, che aggiunge un ulteriore livello alla soluzione di accesso alla rete basata su criteri.
L'agente Protezione accesso alla rete, integrato nel sistema operativo del computer client (come in Windows Vista®) o installabile separatamente (per le versioni meno recenti di Windows e i sistemi operativi non Windows), rileva tutti i potenziali problemi di conformità al Server dei criteri di rete, che è il modulo criteri incorporato in Windows Server 2008. È in Server dei criteri di rete che si definiscono i criteri di conformità che devono essere soddisfatti da tutti i dispositivi.
Mentre è necessario per limitare i dispositivi che non superano la verifica della conformità, è importante anche verificare che l'agente sia in grado di mettere in quarantena e aggiornare i computer non conformi. Protezione accesso alla rete offre l'opzione di aggiornare automaticamente il dispositivo nei casi in cui sia attivata la soluzione di firewall o antivirus oppure di aggiornare manualmente il dispositivo, inserendolo in un'area di quarantena. Da qui il dispositivo può accedere a un server di monitoraggio e aggiornamento con le patch, gli aggiornamenti e le firme più recenti. Dopo l'aggiornamento manuale da parte dell'utente viene concesso l'accesso alla rete, sempre che la verifica della conformità abbia esito positivo.
Con l'ubiquità, l'accesso alla rete è diventato molto più semplice. Tuttavia, è aumentato anche il lavoro aggiuntivo necessario per garantire che i dispositivi siano integri e conformi, indipendentemente dal meccanismo di accesso. I computer possono accedere alla rete tramite un normale switch compatibile con lo standard 802.1X o un punto di accesso wireless oppure, in alternativa, possono connettersi in modalità remota dall'abitazione dell'utente, utilizzando una connessione di accesso remoto basata su VPN o Servizi terminal. Protezione accesso alla rete non solo garantisce la conformità per i computer che si connettono mediante questi diversi meccanismi, ma offre anche l'applicazione dei criteri a livello di server DHCP, switch 802.1X, gateway VPN, gateway di Servizi terminal o punto di accesso wireless compatibile con 802.1X.
Nella Figura 4 la rete è stata già isolata utilizzando la soluzione di isolamento di server e dominio. L'utilizzo di Protezione accesso alla rete in presenza di una rete così isolata offre ulteriori vantaggi nel garantire la conformità ai criteri di integrità per i computer che si connettono alla rete. Il client, all'avvio, invia il proprio rapporto di integrità all'Autorità registrazione integrità, che è un server di certificato. L'Autorità registrazione integrità passa il rapporto di integrità al Server dei criteri di rete per la convalida dei criteri. Se il rapporto di integrità è valido, l'Autorità registrazione integrità invia al client di Protezione accesso alla rete un certificato di integrità e il client può così avviare la comunicazione protetta basata su IPSec con le risorse protette. Se il rapporto di integrità non è valido, l'Autorità registrazione integrità fornisce al client di Protezione accesso alla rete informazioni su come correggere lo stato di integrità e non invia alcun certificato di integrità. Il client di Protezione accesso alla rete non può avviare alcuna comunicazione con gli altri computer che richiedono un certificato di integrità per l'autenticazione di IPSec. Tuttavia, il client di Protezione accesso alla rete può comunicare con il server di monitoraggio e aggiornamento per tornare conforme ai criteri.
Figura 4 Protezione accesso alla rete con applicazione dei criteri IPSec
Figura 4 Protezione accesso alla rete con applicazione dei criteri IPSec

In sintesi
Con l'articolo si è appena accennato alle potenzialità di queste nuove funzionalità di Windows Server 2008, ma è importante comprendere in che modo ciascun componente sia stato costruito sul precedente. L'elemento davvero nuovo rispetto all'approccio tradizionale della difesa in profondità è la struttura di criteri sottostante offerta da Windows Server 2008 tramite, ad esempio, i Criteri di gruppo di Active Directory.
Grazie a questa integrazione, si può disporre di fondamenta solide per la definizione e distribuzione di una soluzione di accesso alla rete basata sui criteri, senza vanificare gli investimenti esistenti. Sollevando la decisione sull'accesso a un livello logico superiore con una gestione centralizzata dei criteri, è possibile bilanciare alla perfezione per le proprie esigenze i due aspetti di facile accesso e maggiore protezione.
Microsoft ha pubblicato molti documenti in cui si illustrano nel dettaglio le aree tecnologiche menzionate in questo articolo. Per acquisire l'esperienza operativa necessaria con le funzionalità descritte, è consigliabile consultare prima gli articoli e le guide dettagliate (i collegamenti nel riquadro "Risorse sulle connessioni in rete" sono un ottimo punto di inizio). In seguito è possibile provare a sviluppare ciascuna fase del progetto in modo che costituisca una base solida per la fase successiva.
Si può creare, ad esempio, una serie di regole di autenticazione del firewall per le applicazioni principali, come delineato nella sezione Windows Firewall con protezione avanzata. Una volta acquisita familiarità con questo tipo di operazioni, è possibile espandere le regole di protezione della connessione in modo da isolare il dominio di rete e aggiungere, infine, il livello di Protezione accesso alla rete. I vantaggi dell'implementazione di una strategia di accesso alla rete basata sui criteri sono notevoli, non ultima la possibilità di restare al passo con quel mondo in continua evoluzione che si chiama rete aziendale.

Ian Hameroff è Senior Product Manager del gruppo Security and Access Product Marketing in Microsoft. È responsabile della gestione e del marketing del prodotto per le tecnologie di rete della piattaforma Windows Server. Ian è il punto di riferimento per le strategie go-to-market per le reti e le soluzioni Windows Server incentrate sulle iniziative principali di protezione e connessione in rete, come l'isolamento di server e domini, le connessioni in rete scalabili e l'adozione di IPv6.
Amith Krishnan è Senior Product Manager del gruppo Security and Access Product Marketing in Microsoft ed è responsabile per la gestione e il marketing del prodotto per le iniziative di connessione in rete e protezione per Windows Server, come la protezione dell'accesso e le connessioni wireless protette. Si occupa inoltre della strategia go-to-market e di diffondere le conoscenze su queste soluzioni.


 Numero speciale: Windows Server 2008: Configurazione dei ruoli con Server Manager
Numero speciale: Windows Server 2008 Byron Hynes

Configurazione dei ruoli con Server Manager
Panoramica:
  • La differenza tra ruoli e funzionalità
  • Operazioni possibili con Server Manager
  • Utilizzo delle procedure guidate
  • Gestione di ruoli e funzionalità dalla riga di comando

Uno dei temi che sembra caratterizzare Windows Server 2008 è che fare di meno rende di più. Questo non significa dover eliminare inutilmente delle funzionalità. Piuttosto, si tratta di una strategia utile per semplificare e chiarire i ruoli e gli strumenti, in modo da installare esattamente ciò che serve, eliminando il superfluo. Server Manager
è un elemento importante di questo concetto in Windows Server® 2008.
Gli aspetti da considerare sono due. Il primo è il concetto fondamentale di ruoli e funzionalità del server, che rappresentano gli elementi di base di Windows Server 2008. Il secondo è proprio lo strumento Server Manager. Questo strumento non solo sostituisce diversi strumenti utilizzati in Windows Server 2003, ma è anche dotato di altre funzionalità, per cui gli amministratori sempre troppo impegnati possono ottenere di più, in modo più veloce e facile.

Ruoli e funzionalità
Nella documentazione disponibile per Windows Server 2008, vengono utilizzati alcuni termini probabilmente poco noti prima d'ora nel contesto Windows®, come "carichi di lavoro" e "ruoli". È opportuno partire dalla definizione di questi termini per i professionisti IT.
All'inizio del ciclo di sviluppo di Windows Server 2008, si è tentato a lungo di comprendere con esattezza come gli utenti utilizzano i prodotti server Microsoft e questo tentativo continua ancora adesso. In generale si è scoperto che i server vengono distribuiti per svolgere operazioni specifiche. Può sembrare ovvio, ma scoprire che i clienti non acquistano dei server solo per avere un server in azienda è stata una rivelazione importante. Anzi, cosa ancora più importante, i server non vengono distribuiti per eseguire tantissime attività, piuttosto agli utenti interessano server che consentano di eseguire operazioni specifiche. Esistono, come è ovvio, delle eccezioni, ma nella maggior parte dei casi, un server viene configurato per eseguire una funzione particolare.
A seguito di queste rivelazioni, si è tentato di raggruppare le "funzioni particolari" in classificazioni ampie, definite carichi di lavoro. Ad esempio, esiste un carico di lavoro del database e un carico di lavoro del server delle applicazioni. Poiché il concetto di carichi di lavoro è ampio e un po' vago, sono state create delle sottocategorie all'interno dei carichi di lavoro, definite ruoli. Un ruolo è una singola operazione, molto specifica, che un server deve eseguire. Si pensi al modo in cui gli utenti dell'organizzazione fanno riferimento ai server sulla rete. La maggior parte degli utenti considera i server in generale come server di file, controller di dominio, server di stampa, server Web e così via. Questa è l'accezione comune di server, quindi Windows Server 2008 presenta lo stesso approccio per la gestione dei ruoli.
È possibile considerare tre categorie principali di ruoli in Windows Server 2008: gestione delle identità e degli accessi (i ruoli che fanno parte di Active Directory®), infrastruttura (comprende server di file, server di stampa, DNS e così via) e applicazione (come il ruolo del server Web e i Servizi terminal).
In Windows Server 2008 saranno disponibili circa 17 ruoli (che comprendono ruoli quali servizi di certificazione di Active Directory, i servizi di accesso e criteri di rete e la virtualizzazione di Windows Server). Inoltre saranno disponibili per il download alcuni ruoli aggiuntivi, come i servizi dei flussi multimediali.
Ciascun ruolo viene descritto in un articolo a parte. Alcuni sono trattati in modo più approfondito in questo numero di TechNet Magazine, altri sono stati già illustrati e altri saranno sviluppati in seguito. È opportuno esaminare tutti i ruoli, partendo dalle informazioni disponibili all'indirizzo technet2.microsoft.com/windowsserver2008/en/servermanager/default.mspx.
Quando si inizia la distribuzione di Windows Server 2008, è necessario scegliere i ruoli da installare su ciascun server. La distribuzione basata sui ruoli è un concetto importante per utilizzare Windows Server 2008 in modo efficace e per snellire le procedure di distribuzione delle risorse.
Nell'elenco dei ruoli non sono compresi elementi come la crittografia unità BitLockerTM e il bilanciamento del carico di rete (NLB). Questo accade perché si tratta di funzioni utili, ma che non sono in genere tra i motivi principali per cui si acquista un sistema. I ruoli, d'altra parte, sono le attività per cui vengono acquistati i sistemi. I server non vengono acquistati, ad esempio, per implementare il bilanciamento del carico, ma per ospitare magari tutti i servizi di un sito Web. Anche se può essere un aspetto essenziale di un server Web, ad esempio, il bilanciamento del carico di rete non costituisce l'obiettivo principale dell'implementazione del server.
Piuttosto che avere tutte le funzionalità del server installate e attive, un amministratore può scegliere le sole funzionalità che devono essere installate. L'elenco di funzionalità contenute in Windows Server 2008 è illustrato nella Figura 1. Con l'inclusione dei soli ruoli e funzionalità necessari, si migliorano stabilità e protezione. Le risorse utilizzate dalle funzionalità o dai ruoli che non vengono installati non costituiscono più un problema. Né lo sono le funzionalità relative alla risoluzione dei problemi o la protezione dei ruoli non installati.
Figure 1 Funzionalità incluse in Windows Server 2008 (Close Figure 1)

Funzionalità di Microsoft .NET Framework 3.0
Crittografia unità BitLocker
Estensioni del server BITS
Connection Manager Administration Kit
Esperienza desktop
Gestione Criteri di gruppo
Client di stampa Internet
Internet Storage Name Server (iSNS)
Monitor porta LPR
Accodamento messaggi
Multipath I/O
Peer Name Resolution Protocol
Servizio audio/video Windows di qualità (qWave)
Assistenza remota
Strumenti di amministrazione remota del server
Gestione archivi rimovibili
Proxy RPC su HTTP
Servizi per NFS
Server SMTP
Gestione archivi SAN
Servizi TCP/IP semplificati
Servizi SNMP
Subsystem for UNIX-based Applications
Client Telnet
Server Telnet
Client TFTP (Trivial File Transfer Protocol)
Clustering di failover
Bilanciamento carico di rete
Windows Server Backup
Gestione risorse di sistema Windows
Server WINS (Windows Internet Naming Service)
Servizio LAN wireless (WLAN)
Database interno di Windows
Windows PowerShell
Servizio Attivazione processo Windows
La sintesi di questo concetto è l'opzione di installazione di Server Core. Server Core è un argomento al di fuori dell'ambito di questo articolo, ma può essere considerato l'estensione logica dell'esclusione di ruoli e funzionalità non utilizzati, che non vengono nemmeno copiati sul disco rigido o resi disponibili. Una differenza essenziale tra un'installazione normale e un'installazione Server Core è che in un'installazione normale sono comprese le risorse necessarie per installare ruoli aggiuntivi in qualsiasi momento e sono supportati tutti i ruoli. Server Core, tuttavia, non prevede neanche una GUI per la shell e supporta solo un numero limitato di ruoli.

Server Manager
La nuova console di Server Manager in Windows Server 2008 semplifica la gestione e la protezione di più ruoli del server in un'azienda. In sostanza Server Manager funziona come una MMC (Microsoft® Management Console) espansa, poiché consente di visualizzare e gestire virtualmente tutte le informazioni e gli strumenti che riguardano la produttività del server. Costituisce un riferimento centralizzato per la gestione di un'identità del server e delle informazioni del sistema, visualizzando lo stato del server, individuando i problemi con la configurazione dei ruoli server e gestendo tutti i ruoli installati sul server. Sostituisce anche alcune funzionalità incluse in Windows Server 2003, come Amministrazione server, Configurazione server e Installazione componenti di Windows.
In alcuni casi Server Manager può ridurre anche la necessità dell'amministratore di eseguire la Configurazione guidata della protezione (SCW) prima di distribuire i server. Server Manager configurerà il server in modo che tutti i ruoli installati siano funzionali, ad esempio configurando automaticamente il firewall di Windows. Nei casi in cui i ruoli sono stati aggiunti e poi rimossi, oppure quando si desidera avere più controllo sulle impostazioni di protezione corrette, SCW rappresenta ancora uno strumento valido. Per ulteriori informazioni, leggere l'articolo Controllo della protezione di Lesper Johansson, "Utilizzo di Configurazione guidata impostazioni di sicurezza in Windows Server 2008", in questo numero (microsoft.com/technet/technetmag/issues/2008/03).
Durante lo sviluppo di Windows Server 2008, si è riflettuto seriamente su come impostare le attività degli amministratori. In alcune situazioni si è notato che gli strumenti e le procedure guidate rendevano le attività più semplici, in altri casi invece si perdeva troppo tempo a passare da uno strumento all'altro. L'obiettivo di progettazione importante per Windows Server 2008 in generale, e per Server Manager in particolare, era rendere la gestione più efficace, lasciando agli amministratori il compito di eseguire molti tipi di attività in modo centralizzato. Di conseguenza, con Server Manager è possibile:
  • Visualizzare e apportare modifiche ai ruoli e alle funzioni installate sul server.
  • Eseguire attività di gestione che riguardano il server, come l'avvio e l'arresto di servizi e la gestione di account utente locali.
  • Eseguire attività di gestione che riguardano i ruoli installati sul server.
  • Verificare lo stato del server, individuare gli eventi critici e analizzare i problemi di configurazione.
  • Installare o rimuovere ruoli, servizi di ruolo e funzionalità mediante una GUI o una riga di comando.
La console di Server Manager presenta una serie di informazioni e funzionalità in uno spazio ridotto. Nella Figura 2 è illustrata la console di Server Manager sul nodo del ruolo Servizi file. Nella finestra principale della console sono disponibili quattro sezioni comprimibili: Riepilogo server, Riepilogo ruoli, Riepilogo funzionalità e Risorse e supporto.
Figura 2 La console di Server Manager con il ruolo Servizi file
Figura 2 La console di Server Manager con il ruolo Servizi file
Nella sezione Riepilogo server sono riportate due sottosezioni, Informazioni computer e Informazioni protezione. Nella sottosezione Informazioni computer vengono visualizzati il nome del computer, il dominio, il nome account dell'amministratore locale, le connessioni di rete e l'ID prodotto del sistema operativo. È possibile utilizzare anche dei comandi per modificare le informazioni. Nella sottosezione Informazioni protezione viene indicato se gli aggiornamenti automatici di Windows e Windows Firewall sono abilitati, ma anche se la configurazione della protezione avanzata di Windows Internet Explorer® è attivata (per gli amministratori o per altri utenti). Allo stesso modo, sono disponibili dei comandi per modificare le impostazioni e visualizzare tutte le opzioni avanzate.
Nella sezione di riepilogo ruoli è disponibile una tabella con i ruoli installati sul server. I comandi in questa sezione consentono di aggiungere o rimuovere i ruoli o di passare a una console più dettagliata con cui gestire un ruolo specifico.
Nella sezione Riepilogo funzionalità è disponibile una tabella con le funzionalità installate sul server. Qui, come prevedibile, è possibile aggiungere e rimuovere funzionalità.
Infine, nella sezione Risorse e supporto viene indicato se il server partecipa ai programmi Analisi utilizzo software e allo strumento Segnalazioni errori Windows ed è possibile configurare la partecipazione del server ai programmi di commenti e suggerimenti. È possibile inoltre individuare rapidamente gli argomenti della guida e ricercare altri argomenti correlati, disponibili nei Windows Server TechCenter e nella documentazione tecnica.

Informazioni sui ruoli
Per ciascun ruolo installato è disponibile la relativa home page all'interno di Server Manager. Per ciascuna delle home page dei ruoli, la sezione Risorse e supporto offre un menu di configurazioni o di scenari consigliati in cui si utilizza il ruolo o parti del ruolo. Ciascuna configurazione consigliata è collegata a un elenco di controllo, che guida l'utente attraverso le attività necessarie da eseguire per adattare al meglio i ruoli specifici.
Un aspetto particolarmente interessante di Server Manager è che vengono messi a disposizione degli utenti informazioni e comandi importanti, proprio quando sono più necessari. Quando, ad esempio, si cerca la home page del ruolo Servizi file, è possibile visualizzare subito gli eventi relativi a tale ruolo, senza dover avviare il Visualizzatore eventi e creare un filtro.
Tuttavia, alcuni ruoli possono generare centinaia di eventi, per cui è possibile creare dei filtri direttamente dalla home page del ruolo. È possibile selezionare i filtri di eventi nel menu laterale e ridurre l'ambito degli eventi visualizzati. Questa finestra di dialogo non fornisce tutte le opzioni di filtro disponibili nel visualizzatore del registro eventi, ma consente di focalizzare rapidamente l'attenzione solo sugli eventi relativi al ruolo particolare, tralasciando il filtro degli altri eventi.
Allo stesso modo, è possibile visualizzare lo stato dei servizi di sistema (i servizi richiesti dal ruolo, ma che fanno parte del sistema globale) e i servizi di ruolo (specifici per il ruolo). Per alcuni ruoli, è possibile scegliere le parti di un ruolo che sono disponibili e verranno installati vari set di servizi di ruolo. Direttamente dalla home page del ruolo è possibile avviare e arrestare i servizi, ma anche specificare i servizi da monitorare come servizi di sistema per il ruolo.

Utilizzo delle procedure guidate
Una procedura guidata ben strutturata consente di risparmiare tempo e di evitare errori, soprattutto se si tratta di attività eseguite solo occasionalmente. Nelle versioni precedenti di Windows Server era necessario utilizzare le procedure Configurazione server, Amministrazione server e Installazione componenti di Windows per modificare i componenti installati sul server. I controlli sulle dipendenze erano limitati e in base alla procedura Installazione componenti di Windows era necessario completare l'installazione di un ruolo prima di poterne aggiungere un altro.
Ora invece, utilizzando le procedure guidate di Server Manager, è possibile installare o rimuovere più ruoli, servizi di ruolo e funzionalità in un'unica sessione. Cosa ancor più importante, i controlli sulle dipendenze vengono eseguiti man mano che si utilizzano le procedure guidate di Server Manager, garantendo che vengano installati tutti i ruoli e i servizi di ruolo necessari. I ruoli vengono configurati con le impostazioni di protezione predefinite consigliate; è possibile, tuttavia, utilizzare Configurazione guidata impostazioni di sicurezza per modificare le impostazioni di protezione. È possibile impostare il server in modo da renderlo pronto per la distribuzione dopo una sola sessione in una delle procedure guidate di Server Manager.
Server Manager contiene una serie di procedure guidate, tra cui quella alcune per l'aggiunta dei ruoli, l'aggiunta dei servizi di ruolo, l'aggiunta delle funzionalità, la rimozione dei ruoli, la rimozione dei servizi di ruolo e la rimozione delle funzionalità.
La procedura guidata per l'aggiunta dei ruoli, come si può immaginare, viene utilizzata per aggiungere ruoli al server, verificare automaticamente le dipendenze tra i ruoli e controllare che tutti i ruoli e i servizi di ruolo richiesti vengano installati per ciascun ruolo selezionato. Per alcuni ruoli, come Servizi terminal e Servizi certificati Active Directory, la procedura guidata per l'aggiunta dei ruoli fornisce anche le pagine di configurazione in cui specificare come deve essere configurato il ruolo durante il processo di installazione. Nella Figura 3 è riportata la pagina per la selezione dei ruoli server della procedura guidata per l'aggiunta dei ruoli.
Figura 3 Utilizzo della procedura guidata per l'aggiunta dei ruoli per scegliere i ruoli server
Figura 3 Utilizzo della procedura guidata per l'aggiunta dei ruoli per scegliere i ruoli server
La maggior parte dei ruoli è costituita da più sottoelementi, a cui si fa riferimento in Server Manager come servizi di ruolo. Una volta installato un ruolo complesso, è possibile utilizzare la procedura guidata di aggiunta ruoli per aggiungere altri servizi di ruoli.
Allo stesso modo della procedura guidata di aggiunta ruoli, la procedura guidata per l'aggiunta delle funzionalità consente di installare le funzionalità. È possibile aggiungere una o più funzionalità nel sistema in un'unica sessione.
La procedura guidata per la rimozione dei ruoli, come suggerisce il nome, consente di rimuove i ruoli da un server. La procedura guidata controlla automaticamente le dipendenze, per garantire che restino installati gli eventuali ruoli o servizi di ruolo necessari per i ruoli che non vengono rimossi. È possibile anche rimuovere i servizi di ruolo da un ruolo installato, utilizzando la relativa procedura guidata per la rimozione dei servizi di ruolo. Al tempo stesso, la procedura guidata per la rimozione delle funzionalità consente di rimuove le funzionalità dal sistema.

La riga di comando
Spesso i professionisti IT non amano le procedure guidate. Anche se sono in pochi a sostenere la propria opinione in modo a tutti i costi, molti professionisti IT preferiscono utilizzare una riga di comando, perché può rivelarsi più comoda, in quanto consente semplici funzioni di ripetibilità e scripting. Server Manager offre uno strumento da riga di comando, ServerManagerCmd.exe, molto più facile dei precedenti strumenti ocsetup e pkgmgr. È possibile utilizzare ServerManagerCmd.exe per installare e rimuovere ruoli, servizi di ruolo e funzionalità. Utilizzando dei semplici parametri è possibile visualizzare un elenco di tutti i ruoli, i servizi di ruolo e le funzionalità, con gli elementi installati e quelli disponibili per l'installazione.
Da questa riga di comando è possibile eseguire installazioni e rimozioni di ruoli, servizi di ruolo e funzionalità non presidiate. È possibile inoltre utilizzare la riga di comando per installare o rimuovere un singolo ruolo, un servizio di ruolo o una funzionalità in un'istanza di comando, altrimenti è possibile utilizzare un file di risposte XML con il comando di Server Manager per aggiungere o rimuovere più ruoli, servizi di ruolo e funzionalità in una sola istanza di comando. Infine, è possibile visualizzare i registri delle operazioni ed eseguire query per visualizzare gli elenchi di ruoli, i servizi di ruolo e le funzionalità installati e disponibili per l'installazione.
Un elemento essenziale di questo strumento da riga di comando è il parametro -whatif, che consente di visualizzare esattamente le modifiche da apportare al server quando si installa il ruolo specificato. Ad esempio, nella Figura 4 sono riportati i risultati dell'esecuzione del comando seguente:
ServerManagerCmd -install Web-Server
-allsubfeatures -whatif
Naturalmente, è possibile salvare l'output in un file per ulteriori analisi.
Figura 4 Utilizzo del parametro -whatif per visualizzare le modifiche da apportare al server
Figura 4 Utilizzo del parametro -whatif per visualizzare le modifiche da apportare al server
Per un'analisi più approfondita dei dettagli e della sintassi di ServerManagerCmd.exe, vedere l'articolo "Appendice alla panoramica tecnica di Server Manager" disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=107113.
A Gaby Kaplan vanno i ringraziamenti per il contributo fornito per questo articolo.

Byron Hynes è un Enterprise Technology Strategist di Enterprise and Partner Group presso Microsoft. Ha lavorato in precedenza nella divisione di Windows Server, oltre che come consulente e istruttore. È possibile contattarlo all'indirizzo bhynes@microsoft.com.


 Numero speciale Windows Server 2008: Distribuzione di Windows Server 2008 con System Center
Numero speciale Windows Server 2008 Tim Mintner

Distribuzione di Windows Server 2008 con System Center
Panoramica:
  • Funzionalità di distribuzione di Configuration Manager
  • Creazione e personalizzazione di una sequenza di attività del server
  • Aggiunta dei ruoli del server
  • Impostazione di variabili specifiche del computer

Con il rilascio di System Center Configuration Manager 2007, gli amministratori di server ora hanno la possibilità di sfruttare i vantaggi degli stessi strumenti di distribuzione dei sistemi operativi che gli amministratori di client hanno
utilizzato per diversi anni. In passato, gli amministratori di server spesso eseguivano installazioni manuali di Windows Server® utilizzando il CD o il DVD, quindi trascorrevano diverse ore a configurare il server. Alcuni amministratori hanno fatto un importante passo avanti e hanno sviluppato routine di installazione automatica creando un file unattend.txt e, probabilmente, utilizzando Servizi di installazione remota (RIS) per automatizzare il processo di installazione, in modo da eliminare la necessità della relativa presenza fisica alla console del server. Gli amministratori più avanzati hanno sfruttato i vantaggi dei servizi di distribuzione automatica (ADS, Automated Deployment Services) per Windows Server 2003 per automatizzare completamente l'intero processo di generazione del server. Ora, con Windows Server 2008, il processo di installazione per i server ha subito per la prima volta delle modifiche considerevoli sin dal rilascio di Windows NT® 4.0.
La distribuzione di Windows Server 2008 prevede l'utilizzo degli stessi strumenti e tecnologie di distribuzione sottostanti di Windows Vista®. A causa di queste modifiche, gli strumenti utilizzati in passato dagli amministratori di server dovranno essere aggiornati o sostituiti. La funzionalità Servizi di installazione remota è stata sostituita da Servizi di distribuzione Windows® (WDS) e ADS non fornisce il supporto per la distribuzione di Windows Server 2008. Per ulteriori informazioni sulle tecnologie e sugli strumenti che sono stati modificati con la distribuzione server e client, vedere "10 cose da sapere sulla distribuzione di Windows Vista" all'indirizzo technetmagazine.com/ issues/2006/11/Deployment.
Poiché le tecnologie sottostanti per la distribuzione di Windows Server 2008 e Windows Vista sono identiche, non sarebbe fantastico poter utilizzare gli stessi strumenti e le stesse conoscenze per distribuire entrambi i sistemi operativi? System Center Configuration Manager e Microsoft® Deployment ora forniscono questo set di strumenti integrato. In questo articolo verrà descritto come utilizzare Configuration Manager insieme a Microsoft Deployment per avviare la distribuzione di Windows Server 2008.

Distribuzione del sistema operativo con Configuration Manager
Prima di avviare la distribuzione di Windows Server 2008, è opportuno esaminare le funzionalità di distribuzione del sistema operativo di Configuration Manager. Quando si avvia la console di Configuration Manager e si accede a Gestione computer, è possibile notare una nuova area di destinazione per la distribuzione dei sistemi operativi, come illustrato nella Figura 1.
Figura 1 Pagina della distribuzione dei sistemi operativi
Figura 1 Pagina della distribuzione dei sistemi operativi
Questa pagina contiene un rapido riepilogo delle distribuzioni del sistema operativo che sono state eseguite nell'ambiente in uso e consente di accedere ad altri nodi della distribuzione dei sistemi operativi, come per la gestione delle sequenze di attività e la gestione delle immagini d'avvio. Nella pagina è presente inoltre un elenco dei report Web per la visualizzazione dello stato delle distribuzioni e dello stato dell'ambiente di distribuzione. Sotto Risorse è inoltre disponibile una guida di riferimento rapido che contiene collegamenti alla documentazione della Guida relativa alla distribuzione del sistema operativo.
Sotto i nodi del riquadro di spostamento è inoltre possibile osservare tutti gli elementi che devono essere configurati per l'esecuzione di una distribuzione del sistema operativo. Di seguito viene riportato un riepilogo di questi elementi:
Immagini d'avvio Contiene un elenco delle immagini di avvio basate su Windows PE 2.0 che verranno utilizzate durante il processo di distribuzione.
Associazione di computer Utilizzato principalmente per le distribuzioni client per eseguire il mapping tra un computer esistente e un nuovo computer in modo che sia possibile gestire lo stato utente in modalità protetta. Contiene inoltre una procedura guidata per l'importazione di account di computer sconosciuti nel database di Configuration Manager in modo che sia possibile distribuire server privi di software.
Immagini del sistema operativo Include un elenco di pacchetti che contengono immagini WIM (Windows Imaging Format) per la distribuzione di server e client.
Pacchetti di installazione del sistema operativo Include i pacchetti che contengono l'insieme completo dei file di origine per una distribuzione del sistema operativo, come i file di origine per Windows Server 2008.
Sequenze di attività Contiene più passaggi, ciascuno dei quali definisce le azioni da riga di comando che verranno eseguite senza l'interazione dell'utente. Le sequenze di attività rappresentano il motore trainante del processo di distribuzione del sistema operativo e possono fornire tutte le istruzioni necessarie per distribuire e configurare un sistema operativo.
Driver Un archivio centrale per la gestione di tutti i driver necessari per i diversi modelli di computer server e client.
Pacchetti di driver Contiene uno o più insiemi di driver che possono essere distribuiti ai punti di distribuzione di Configuration Manager e vengono utilizzati durante la distribuzione di computer server e client.
A questo punto si ha una conoscenza di base delle funzionalità di distribuzione del sistema operativo di Configuration Manager; è possibile quindi raccogliere tutte le informazioni necessarie per eseguire una distribuzione di Windows Server 2008.

Operazioni preliminari alla distribuzione di Windows Server 2008
Cos'è Microsoft Deployment?
Microsoft Deployment è la versione successiva di Business Desktop Deployment (BDD) 2007. Questa soluzione riunisce gli strumenti e i processi necessari per la distribuzione di desktop e server in una comune console di distribuzione e una raccolta di istruzioni. Il prodotto aggiunge nuove funzionalità di distribuzione e organizzazione in sequenza di attività per i desktop e i server utilizzando System Center Configuration Manager 2007.
Microsoft Deployment è disponibile nell'Area download Microsoft e il materiale con le istruzioni può essere letto online nei Desktop Deployment e Server Deployment TechCenter su Microsoft TechNet. Per ulteriori informazioni e collegamenti a queste destinazioni e altri contenuti correlati, visitare il sito microsoft.com/deployment.

Per distribuire Windows Server 2008 con Configuration Manager sono necessari i seguenti elementi:
Microsoft Deployment Toolkit (MDT) Fornisce gli strumenti e le procedure consigliate per la distribuzione dei sistemi operativi server e client. Si integra direttamente con la console di Configuration Manager per semplificare il processo di distribuzione. È possibile scaricare Microsoft Deployment Toolkit da microsoft.com/deployment.
Immagine di avvio personalizzata Configuration Manager fornisce immagini di avvio a 32 bit e a 64 bit basate su Windows PE 2.0 e include il supporto per VBScript, Strumentazione gestione Windows (WMI) e applicazioni HTML (HTA). Tuttavia, se si desidera che durante il processo di distribuzione vengano richieste informazioni da un database SQL Server® separato, sarà necessario utilizzare un'immagine di avvio personalizzata che includa il supporto per ADO.
Pacchetto di installazione del sistema operativo Contiene i file di origine disponibili sul DVD di Windows Server 2008.
Pacchetto MDT Contiene tutti gli script e i file di supporto necessari per Microsoft Deployment Toolkit.
Pacchetto client di Configuration Manager Contiene i file di installazione per il client Configuration Manager.
Pacchetto di impostazioni Contiene il file unattend.xml utilizzato per un'installazione automatica di Windows Server 2008 e il file customsettings.ini utilizzato con Microsoft Deployment Toolkit.
Pacchetto Sysprep Utilizzato solo durante la distribuzione di Windows Server 2003 o Windows XP e fornisce i file sysprep necessari per preparare un computer per l'acquisizione di un'immagine del sistema operativo.
Driver Contiene tutti i driver necessari per specifici modelli di server.
Condivisioni di rete per le origini del pacchetto e le immagini WIM acquisite Percorsi UNC (Universal Naming Convention) in cui vengono memorizzati i pacchetti sopra elencati e l'immagine WIM personalizzata.
La creazione di tutti questi pacchetti potrebbe sembrare un processo laborioso. Tuttavia, la buona notizia è che con Microsoft Deployment Toolkit è disponibile una procedura guidata che consente di creare tutti questi pacchetti in modo automatico.
Per utilizzare Microsoft Deployment Toolkit con Configuration Manager è necessario installarlo nello stesso computer della console di gestione di Configuration Manager. Successivamente, accedere a Start | Tutti i programmi | Microsoft Deployment Toolkit e scegliere l'opzione che consente di configurare l'integrazione di ConfigMgr, quindi specificare il nome del server del sito e il codice del sito di Configuration Manager e scegliere Avanti. Alla console di Configuration Manager verranno aggiunte delle estensioni fornite da Microsoft Deployment Toolkit. A questo punto, quando si avvia la console di Configuration Manager e si fa clic con il pulsante destro del mouse su Task Sequences, viene visualizzata una nuova opzione, come illustrato nella Figura 2.
Figura 2 Importazione della sequenza di attività di Microsoft Deployment
Figura 2 Importazione della sequenza di attività di Microsoft Deployment
Selezionare l'opzione che consente di importare la sequenza di attività di Microsoft Deployment e seguire la procedura riportata di seguito per creare i pacchetti necessari e la sequenza di attività per Windows Server 2008:
  1. Nella schermata in cui è possibile scegliere i modelli selezionare la voce relativa alla sequenza delle attività server, quindi fare clic su Avanti.
  2. Fornire un nome per la sequenza di attività e aggiungere commenti in cui venga descritta la sequenza di attività, quindi scegliere Avanti.
  3. Inserire i dettagli per la partecipazione a un dominio o un gruppo di lavoro, comprese le credenziali dell'account utente per aggiungere il server al dominio. Immettere le informazioni sull'organizzazione e il codice "Product Key", quindi specificare un percorso UNC e un nome file per l'immagine WIM personalizzata che verrà acquisita. Fornire le credenziali utente per la connessione alla condivisione di rete in cui verrà memorizzato il file WIM, quindi scegliere Avanti.
  4. Nella schermata Immagine d'avvio specificare di creare un nuovo pacchetto di immagini di avvio e fornire un percorso di rete da utilizzare come directory di origine pacchetto per il pacchetto di immagini di avvio, quindi fare clic su Avanti.
  5. Fornire un nome per il pacchetto, le informazioni sulla versione e i commenti per il pacchetto Immagine d'avvio, quindi fare clic su Avanti.
  6. Selezionare una piattaforma (x86 o x64), il supporto ADO, i tipi di carattere facoltativi necessari, uno sfondo personalizzato per l'immagine di avvio, se necessario, ed eventuali cartelle aggiuntive da includere nell'immagine Windows PE, quindi scegliere Avanti.
  7. Nella schermata relativa al pacchetto MDT, specificare di creare un nuovo pacchetto di file per Microsoft Deployment Toolkit, fornire un percorso UNC da utilizzare come origine del pacchetto e fare clic su Avanti.
  8. Specificare un nome, la versione, la lingua, il produttore e i commenti per il pacchetto MDT, quindi fare clic su Avanti.
  9. Per l'immagine del sistema operativo, specificare di creare un nuovo pacchetto di installazione del sistema operativo, fornire il percorso dei file di origine di Windows Server 2008 e specificare un percorso UNC da utilizzare come directory di origine del pacchetto, quindi fare clic su Avanti.
  10. Per il pacchetto client, scegliere di creare un nuovo pacchetto client di Configuration Manager e fare clic su Avanti.
  11. Per il pacchetto di impostazioni, specificare di creare un nuovo pacchetto di impostazioni e fornire un percorso UNC da utilizzare come origine pacchetto per il pacchetto di impostazioni, quindi fare clic su Avanti.
  12. Per il pacchetto Sysprep, scegliere l'opzione che consente di escludere i file Sysprep e fare clic su Avanti.
A questo punto, la procedura guidata creerà l'immagine di avvio e tutti i pacchetti. Se si espande Pacchetti, Immagini d'avvio, Operating System Install Packages e Task sequences, verranno visualizzati tutti i pacchetti e la sequenza di attività creati. Una volta creati, questi pacchetti devono essere distribuiti ai punti di distribuzione.
Oltre ai pacchetti, è necessario aggiungere i driver per gli specifici componenti hardware del server. A tal fine, aggiungere i driver all'archivio driver di Configuration Manager e creare un pacchetto driver che verrà utilizzato durante la distribuzione.
Per importare i driver nel catalogo dei driver e creare un pacchetto driver, accedere alla console di Configuration Manager, fare clic con il pulsante destro del mouse su Driver e scegliere Importa. Scegliere di importare tutti i driver nel percorso UNC specificato, quindi digitare un percorso UNC che contiene tutti i driver raccolti per gli specifici modelli di server. Al termine, fare clic su Avanti.
Nella pagine Drivers Details scegliere i file INF da importare e, se si desidera, assegnare i driver a una categoria (una categoria può essere basata su uno specifico tipo di modello del server). Fare clic su Avanti, quindi nella pagina in cui è possibile aggiungere driver al pacchetto fare clic sull'opzione che consente di creare nuovi pacchetti. Specificare un nome, un commento e un percorso UNC da utilizzare come origine pacchetto per il pacchetto driver, quindi fare clic su OK. Al termine, scegliere l'opzione per aggiornare i punti di distribuzione e fare clic su Avanti.
Nella pagina per aggiungere un driver alle immagini d'avvio selezionare l'immagine di avvio creata in precedenza e, al termine, selezionare la casella per l'aggiornamento dei punti di distribuzione. Fare clic su Avanti, quindi nella pagina di riepilogo fare di nuovo clic su Avanti per completare la procedura guidata, importare i driver e creare il pacchetto driver.

Modifica della sequenza di attività
Una volta creati tutti i pacchetti necessari e la sequenza di attività per installare Windows Server 2008, è opportuno personalizzare alcune azioni nella sequenza di attività predefinita. Per modificare la sequenza di attività, fare clic con il pulsante destro del mouse su di essa e scegliere Modifica. Verrà visualizzato il modello della sequenza di attività del server Microsoft Deployment, come illustrato nella Figura 3.
Figura 3 È possibile personalizzare la sequenza di attività predefinita
Figura 3 È possibile personalizzare la sequenza di attività predefinita
Da un punto di vista generale, una sequenza di attività rappresenta una serie di elementi della riga di comando, noti come attività, ciascuno dei quali esegue specifiche operazioni. Per ogni attività è possibile specificare determinate proprietà configurabili e impostare una serie di condizioni nella scheda Opzioni che valutano se sia opportuno eseguire specifiche attività. Ad esempio, per la prima attività nella sequenza di attività è impostata una serie di condizioni, come illustrato nella Figura 4.
Figura 4 È possibile disattivare un'attività o impostare condizioni per un'attività nella scheda Opzioni
Figura 4 È possibile disattivare un'attività o impostare condizioni per un'attività nella scheda Opzioni
In questo esempio, l'attività è disattivata per impostazione predefinita, in quanto è stata selezionata la casella di controllo a tal fine. Se l'attività fosse attivata, verrebbe eseguita solo in base alle condizioni correntemente specificate.
Alcune delle attività più comuni che potrebbe essere necessario modificare prima di distribuire Windows Server 2008 consentono di formattare e partizionare includono il disco, convalidare, applicare un'immagine del sistema operativo e applicare le impostazioni di rete.
L'attività di formattazione e partizionamento del disco consente di definire la modalità di creazione della struttura delle partizioni dei dischi per le distribuzioni server. L'impostazione predefinita prevede la creazione di una partizione che utilizza tutto lo spazio disponibile sul primo disco. È possibile che non si desideri distribuire i server con questa configurazione; pertanto, è possibile modificare questa impostazione per specificare il layout del disco che si desidera utilizzare.
L'attività di convalida consente di controllare alcuni requisiti di base, come memoria e velocità del processore. Se, ad esempio, lo standard aziendale per le distribuzioni dei server corrisponde a 2 GB di memoria, è possibile impostare questo valore come requisito; in tal modo, l'installazione non continuerà se il server non soddisfa tale requisito.
L'attività di applicazione di un'immagine del sistema operativo consente di configurare l'immagine specifica da distribuire. Ad esempio, quando si utilizzano i file di origine per Windows Server 2008, è possibile distribuire Server Standard, Server Enterprise, Server Datacenter, Server Standard Core, Server Enterprise Core e Server Datacenter Core. È necessario scegliere l'immagine appropriata da utilizzare, e questo dipende dalla versione di Windows Server 2008 che si desidera distribuire.
L'attività di applicazione delle impostazioni di rete consente di configurare indirizzi IP statici per le schede di rete e di modificare le impostazioni per la partecipazione a un dominio o un gruppo di lavoro. L'impostazione di un indirizzo IP statico utilizzando questa attività, sebbene sia possibile, potrebbe rendere funzionale questa sequenza di attività solo per un server. Più avanti in questo articolo verrà illustrato come impostare gli indirizzi IP statici tramite le variabili in modo da poter utilizzare una singola sequenza di attività per più server.

Installazione e configurazione dei ruoli del server
Finora è stato illustrato come modificare la sequenza di attività per configurare gli elementi correlati all'installazione del sistema operativo. Con Microsoft Deployment Toolkit, tuttavia, è anche possibile installare e configurare i ruoli del server. Ad esempio, è possibile configurare una sequenza di attività per distribuire Windows Server 2008 su un server di succursale su cui verranno eseguiti un controller di dominio di sola lettura e un file server.
A tal fine, nell'editor delle sequenze di attività accedere all'attività di installazione del software e scegliere Aggiungi | MDT e selezionare l'opzione che consente di installare ruoli e funzionalità. Nell'attività di installazione di ruoli e funzionalità appena creata, selezionare le caselle relative al controller di dominio di Active Directory e file server, come illustrato nella Figura 5.
Figura 5 Installazione di ruoli e funzionalità
Figura 5 Installazione di ruoli e funzionalità
Ora, è necessario configurare le impostazioni per il controller di dominio di sola lettura. Nell'editor delle sequenze di attività scegliere Aggiungi | MDT e selezionare l'opzione che consente di configurare ADDS. Nell'attività di configurazione di ADDS appena creata specificare di creare una nuova replica del controller di dominio di sola lettura, quindi impostare i valori per le seguenti proprietà:
  • Nome del server DNS del dominio esistente
  • Controller di dominio di origine di replica
  • Account
  • Password di ripristino (modalità provvisoria)

Utilizzo delle variabili
Una delle funzionalità più potenti offerte agli utenti dalle sequenze di attività è rappresentata dalla capacità di impostare dinamicamente durante il processo di distribuzione quasi tutte le proprietà nella sequenza di attività come variabile. Configuration Manager e Microsoft Deployment forniscono diversi meccanismi per impostare ed utilizzare le variabili.
Configuration Manager consente di impostare le variabili come variabile Computer, variabile Collection o direttamente all'interno della sequenza di attività. Microsoft Deployment consente di impostare le variabili tramite il file customsettings.ini, un database back-end o un servizio Web. Un elenco di variabili che è possibile impostare è disponibile all'indirizzo technet.microsoft.com/bb632442.aspx.
Si utilizzi l'esempio relativo all'impostazione di un indirizzo IP statico su uno specifico server. In precedenza nell'articolo si è affermato che è possibile impostare l'indirizzo IP statico direttamente nella sequenza di attività nell'attività di applicazione delle impostazioni di rete. Questa, tuttavia, non è la procedura consigliata, in quanto rende la sequenza di attività in questione utile solo per uno specifico server.
È consigliabile invece impostare l'indirizzo IP tramite una variabile, anziché la sequenza di attività. Di seguito vengono riportate istruzioni dettagliate per l'impostazione dell'indirizzo IP statico come variabile Computer:
  1. Nella console di Configuration Manager, accedere a System Center Configuration Manager | Database siti | Gestione computer | Raccolte.
  2. Per assegnare una variabile specifica per il computer a un computer, individuare ed espandere l'insieme a cui il computer appartiene, fare clic con il pulsante destro del mouse sul computer, fare clic su Proprietà, quindi scegliere la scheda delle variabili.
  3. Per specificare le variabili personalizzate e i relativi valori associati, fare clic sull'icona Nuova per aprire la finestra di dialogo <Nuova> variabile.
  4. Nella finestra di dialogo <Nuova> variabile è necessario specificare un nome per la variabile e indicare se questa variabile sarà visibile nella console di Configuration Manager 2007. Per un indirizzo IP statico, occorre aggiungere le seguenti variabili:
  • OSDAdapter0IPAddressList
  • OSDAdapter0SubnetMask
  • OSDAdapter0Gateways
  • OSDAdapter0DNSServerList
Le variabili configurate sono simili a quelle riportate nella Figura 6.
Figura 6 Utilizzo delle variabili specifiche del computer per impostare un indirizzo IP statico
Figura 6 Utilizzo delle variabili specifiche del computer per impostare un indirizzo IP statico

Distribuzione della sequenza di attività
Dopo aver completato la configurazione della sequenza di attività e impostato le variabili, è possibile avviare la distribuzione di Windows Server 2008. Configuration Manager offre diversi meccanismi per la distribuzione di un sistema operativo, come PXE (Pre-boot eXecution Environment), supporti di avvio per la sequenza di attività, supporti autonomi e tramite un annuncio standard per i computer esistenti.
Per semplicità, verrà illustrato come creare una sequenza di attività per supporti di avvio. Nella console di Configuration Manager accedere a Task Sequences, quindi selezionare l'opzione che consente di creare un supporto per la sequenza di attività dal menu Azioni. Nella pagina per la selezione del tipo di supporto selezionare la voce relativa al supporto avviabile e fare clic su Avanti. Nella pagina del tipo di supporto specificare un CD come tipo di supporto e un nome per il file sul supporto. Nella scheda Protezione è possibile specificare una password per proteggere il supporto o un certificato autofirmato. Specificare l'immagine di avvio. Al termine, accedere alla pagina Conferma e fare clic su Fine. Per istruzioni dettagliate su come eseguire la distribuzione tramite questo e altri meccanismi, fare riferimento alla documentazione all'indirizzo technet.microsoft.com/bb681029.aspx.

Conclusioni
In questo articolo è stato illustrato come utilizzare System Center Configuration Manager e Microsoft Deployment per distribuire Windows Server 2008, aggiungere ruoli, come i ruoli di controller di dominio e file server, impostare variabili specifiche del computer e distribuire il sistema operativo utilizzando supporti di avvio per la sequenza di attività. Sebbene le distribuzioni di server effettive possano rivelarsi molto più complesse, le informazioni riportate in questo articolo dovrebbero risultare utili per iniziare a unificare gli strumenti di distribuzione client e server.

Tim Mintner è Senior Software Development Engineer del team Microsoft responsabile degli acceleratori di soluzioni la cui attività è incentrata su Microsoft Deployment Toolkit. Ha accumulato oltre 14 anni di esperienza nell'ambito della distribuzione dei sistemi operativi Microsoft lavorando in stretta collaborazione con i clienti. È possibile contattare Tim all'indirizzo tmintner@microsoft.com.


 Numero speciale Windows Server 2008: Controllo e conformit&#224; in Windows Server 2008
Numero speciale Windows Server 2008 Rob Campbell e Joel Yoker

Controllo e conformità in Windows Server 2008
Panoramica:
  • Aumento dell'importanza della conformità
  • Comprensione delle modifiche nell'ambiente in uso
  • Problemi correlati al controllo degli eventi di protezione
  • Aspetti tecnici del controllo

Nel mondo della tecnologia IT il cambiamento è costante. La maggior parte delle organizzazioni IT si trova oggi sotto la crescente pressione di comprendere i cambiamenti che si verificano nel proprio ambiente. Maggiore è la complessità e la scalabilità degli ambienti IT, più significativo sarà l'impatto di
eventuali errori amministrativi e divulgazioni accidentali dei dati. La società odierna richiede un'assunzione di responsabilità e rendiconto nei confronti di eventi di questo tipo e, pertanto, le organizzazioni sono ora ritenute legalmente responsabili della salvaguardia delle informazioni che gestiscono.
Di conseguenza, il controllo delle modifiche nell'ambiente aziendale ha acquisito un'importanza fondamentale. Perché? Il controllo consente di comprendere e gestire le modifiche negli attuali ambienti IT di grandi dimensioni e a distribuzione elevata. In questo articolo verranno illustrati le problematiche più comuni a cui la maggior parte delle organizzazioni deve far fronte, gli scenari della conformità e delle normative nel settore IT e alcuni dei concetti alla base del meccanismo di controllo di Windows®. Verrà inoltre descritto come le funzionalità di Windows Server® 2008 e il servizio Audit Collection Services (ACS) di Microsoft® System Center Operations Manager 2007 siano in grado di integrare una strategia di controllo completa.

Controllo delle problematiche
Basta dare una rapida occhiata ai titoli dei giornali per rendersi conto che la divulgazione dei dati sta diventano un problema quotidiano. Molti di questi eventi implicano per le organizzazioni responsabili problemi correlati ad azioni legali, perdite finanziarie e relazioni pubbliche. La capacità di spiegare che tipo di modifiche sono state eseguite e di identificare rapidamente i problemi è essenziale per ridurre l'impatto degli episodi di divulgazione accidentale dei dati.
Si supponga, ad esempio, che la propria organizzazione sia responsabile della gestione di informazioni che consentono l'identificazione personale per una determinata base di clienti. Nonostante l'ampia gamma di metodi disponibili per proteggere le informazioni contenute nei sistemi gestiti dalla propria organizzazione, esiste comunque il rischio che i dati vengano compromessi. Un controllo appropriato potrebbe consentire all'organizzazione di determinare con esattezza quali sistemi sono stati compromessi e, probabilmente, quali dati sono andati persi. Senza un sistema di controllo, l'impatto della perdita dei dati potrebbe essere molto più significativo, in particolare perché non si potrebbe in alcun modo stimare l'entità della compromissione.
Perché, dunque, le organizzazioni IT non hanno ancora implementato un sistema di controllo? Il fatto è che la maggior parte delle organizzazioni non è in grado di comprendere appieno gli aspetti tecnici del controllo. Sebbene i responsabili senior siano in grado di comprendere concetti come backup e ripristino, la complessità inerente del controllo delle modifiche nell'ambiente è un concetto piuttosto difficile da convogliare. Di conseguenza, le domande relative al controllo vengono in genere poste solo dopo l'insorgenza di un evento significativo. È possibile, ad esempio, attivare il controllo di base, ma se il sistema non viene configurato per il controllo di una specifica modifica, a causa della mancanza di pianificazione, tali informazioni non verranno raccolte.
Inoltre, gli eventi di protezione controllati presentano alcuni problemi intrinseci che devono essere gestiti dai professionisti IT. Una di queste difficoltà è rappresentata dalla distribuzione di sistemi all'interno dei moderni ambienti informatici di grandi dimensioni, che pone significativi problemi in termini di raccolta e aggregazione, in quanto una modifica può verificarsi in qualsiasi sistema o insieme di sistemi in qualsiasi momento. Una situazione di questo tipo può condurre a un altro problema: la correlazione. La conversione delle relazioni tra gli eventi che si verificano su un singolo sistema o su più sistemi si rende spesso necessaria per fornire un vero significato a ciò che sta accadendo.
Un altro problema è rappresentato dal fatto che il controllo in genere supera i tradizionali confini delle organizzazioni. Strutture di organizzazioni o di team differenti esistono per ragioni differenti e non è sempre semplice stabilire un collegamento tra loro. Molte organizzazioni dispongono di un team per i servizi directory, un team per l'infrastruttura di messaggistica e un team per le applicazioni desktop, ma probabilmente prevedono un unico team di protezione responsabile per tutte queste aree. Inoltre, il personale responsabile della protezione potrebbe non essere fisicamente presente in tutte le sedi di un'organizzazione. Ad esempio, le succursali fanno in genere affidamento su un singolo individuo o un piccolo team per tutte le attività, tra cui la gestione dei registri eventi di protezione.
Infine, l'enorme quantità di eventi rappresenta una vera sfida. Gli eventi di protezione controllati si verificano in volumi molto più elevati rispetto ad altri tipi di registrazione di eventi. Il numero di eventi raccolti rende difficile mantenere ed esaminare in modo efficace i registri. Inoltre, stipulando i requisiti di conservazione per queste informazioni, le normative correnti e proposte non contribuiscono a ridurre questo onere nelle infrastrutture informatiche attuali.
In passato, il controllo dell'accesso alle informazioni poteva essere considerato come un desiderio di "sapere" e un tentativo di garantire la protezione. Ora, poiché le organizzazioni e i dirigenti senior vengono ritenuti legalmente responsabili della perdita di informazioni o della mancanza di misure di protezione appropriate, è fondamentale per gli amministratori IT acquisire dimestichezza con le normative che potrebbero essere applicabili ai relativi ambienti. Per le aziende globali, le sfide sono ancora più complesse, in quanto ogni paese prevede normative specifiche riguardanti le informazioni e la relativa protezione. Alcuni esempi di leggi sulla conformità normativa esistenti sono elencati nella Figura 1, insieme alle aspettative nei confronti delle organizzazioni IT.
Figure 1 Normative e relative implicazioni per i professionisti IT (Close Figure 1)

Normativa | Obiettivo
Sarbanes-Oxley Act del 2002 (SOX) | La sezione 404 riconosce il ruolo dei sistemi informatici e richiede che aziende quotate in borsa forniscano una revisione annuale dei relativi controlli interni sul reporting finanziario.
Health Insurance Portability and Accountability Act (HIPPA) | Regola la protezione e la riservatezza dei dati relativi alla salute; la sezione dedicata alle regole di protezione tratta della tutela amministrativa, fisica e tecnica di tali dati.
Electronic Discovery (eDiscovery) | Definisce gli standard per la conservazione e la consultazione dei documenti, incluso un rendiconto di coloro che accedono ai documenti e delle relative modalità di accesso.
Federal Information Security Management Act (FISMA) del 2002 | Mandato federale per fornire un framework completo sulla protezione delle informazioni (INFOSEC) per i sistemi governativi statunitensi, il coordinamento con diverse autorità giudiziarie competenti, il riconoscimento di prodotti commerciali e le funzionalità software. La sezione 3544 tratta delle responsabilità delle autorità, inclusi i controlli IT.
Federal Information Processing Standards (FIPS) Publication 200 | Specifica i requisiti di protezione minimi per le informazioni federali e i sistemi informatici e delinea l'utilizzo delle raccomandazioni presenti in NIST Special Publication (SP) 800-53. In NIST SP800-53, la sezione AU-2, dedicata agli eventi controllabili (Auditable Events), specifica che i sistemi informatici devono fornire la capacità di compilare record di controllo da più componenti in un audit trail correlato al tempo a livello di sistema, di gestire gli eventi controllati da singoli componenti e di assicurare che l'organizzazione esamini periodicamente gli eventi controllabili.
Considerata tutta la pressione legale, che tipo di azione è necessario che i professionisti IT intraprendano? I responsabili e i tecnici IT devono creare un progetto chiaro e conciso da presentare ai collaboratori interni ed esterni all'organizzazione. Questo include lo sviluppo di una strategia di controllo appropriata che richiede misure e investimenti proattivi. Il concetto principale è che il sistema di controllo non può essere progettato solo dopo il verificarsi di un problema, come spesso accade.
Questi tipi di sfide IT possono essere in genere risolte grazie a una combinazione di persone, processi e tecnologie. Nell'ambito del controllo, il processo rappresenta l'area di maggiore interesse. Pertanto, il primo passo deve prevedere la conoscenza dei concetti di base in modo da poter rispondere alle esigenze e ai requisiti di conformità normativa della propria organizzazione. In questo articolo verranno illustrati i concetti alla base del meccanismo di controllo in Windows, quindi verranno esaminate le modifiche introdotte in Windows Server 2008 e Windows Vista®.

Controllo degli eventi di protezione
Tutti gli eventi controllati vengono registrati nel registro eventi di protezione di Windows. Questi eventi, in genere, non sono immediatamente utilizzabili e spesso sono di natura informativa. Ogni evento registra un semplice risultato di tipo "controllo riuscito" o "controllo non riuscito" per un tipo specifico di accesso. Questo registro è diverso dai registri eventi dell'applicazione e del sistema, in cui i problemi possono essere identificati tramite la codifica con colori (suggerimento: cercare gli eventi rossi per identificare immediatamente il problema).
Il registro eventi di protezione è differente in quanto gli eventi controllati vengono in genere nascosti in base al relativo volume e, come notato in precedenza, la correlazione dei dati di protezione può rivelarsi una sfida significativa. Anche una semplice violazione dei dati su un singolo sistema può causare problemi. È necessario analizzare il registro eventi di protezione per identificare l'account che è stato utilizzato per accedere ai dati, il che richiede che un amministratore esamini l'intero registro per tentare di individuare l'account. Sfortunatamente, i sofisticati attacchi attuali sono in genere coordinati e distribuiti, rendendo piuttosto difficoltoso questo tipo di analisi per la vittima.
Detto questo, è importante acquisire familiarità con gli elementi chiave che consentono di registrare le informazioni nel registro eventi di protezione di Windows: i criteri di controllo e gli elenchi di controllo di accesso di sistema (SACL, System Access Control List). I criteri di controllo sono impostazioni configurabili per un computer locale tramite Criteri di gruppo o Criteri di protezione locali e definiscono l'insieme di eventi riusciti e non riusciti per specifici tipi di accesso. Le seguenti categorie principali dei criteri di controllo sono presenti in Windows da molti anni (ulteriori informazioni sulla nuova funzionalità criteri di controllo granulari (GAP, Granular Audit Policy) di Windows Server 2008 verranno fornite più avanti):
  • Controlla eventi accesso account
  • Controlla gestione degli account
  • Controlla accesso al servizio directory
  • Controlla eventi di accesso
  • Controlla accesso agli oggetti
  • Controlla modifica ai criteri
  • Controlla uso dei privilegi
  • Controlla traccia processo
  • Controlla eventi di sistema
La necessità di definire i criteri di controllo e le categorie associate è in genere compresa dalla maggior parte delle organizzazioni IT, ma i criteri di controllo rappresentano solo una parte della soluzione. Anche gli elenchi di controllo di accesso di sistema giocano un ruolo significativo nell'implementazione di un piano di controllo olistico. Due specifiche categorie dei criteri di controllo, Controlla accesso al servizio directory e Controlla accesso agli oggetti, sono completamente dipendenti dagli elenchi di controllo di accesso di sistema per la restituzione delle informazioni nel registro eventi di protezione. Cosa sono esattamente gli elenchi di controllo di accesso di sistema?
Ogni oggetto, file, Registro di sistema o servizio directory, dispone di un elenco di controllo di accesso (ACL) con una o più voci di controllo di accesso (ACE) suddivise in due tipi: un elenco di controllo di accesso discrezionale (DACL) e un SACL (quest'ultimo definisce le impostazioni che consentono di registrare i tentativi di accesso agli oggetti protetti). Ogni voce di controllo di accesso in un SACL specifica i tipi di tentativi di accesso da parte di un trustee specificato che devono essere registrati nel registro eventi di protezione. Le voci di controllo di accesso definiscono la registrazione dei tentativi di accesso riusciti e/o non riusciti agli oggetti specificati. Nella Figura 2 viene illustrato l'utilizzo di un SACL in un oggetto per generare gli eventi per specifici tipi di accesso.
Figura 2 Utilizzo di un SACL in un oggetto
Figura 2 Utilizzo di un SACL in un oggetto
La comprensione della relazione tra i criteri di controllo e gli elenchi di controllo di accesso di sistema è fondamentale dal momento che la configurazione è necessaria per acquisire gli eventi controllati "corretti" in quanto correlati alle modifiche nell'ambiente. Come menzionato in precedenza, i criteri di controllo Controlla accesso al servizio directory e Controlla accesso agli oggetti consentono la generazione di controlli nel registro eventi di protezione solo per queste specifiche categorie, ma gli eventi vengono generati solo se un oggetto prevede una voce ACE di controllo configurata nel relativo SACL. Gli eventi di protezione vengono generati dall'autorità di protezione locale (LSA) di Windows e scritti nel registro eventi di protezione.
Gli eventi sono composti da due aree distinte: l'intestazione, che è statica ed è predefinita per ciascun identificatore di evento (ID evento), e il corpo, che è dinamico e contiene dettagli differenti per i diversi eventi. Nella Figura 3 questi due elementi vengono riportati in un evento di protezione di Windows Server 2008 di esempio. La comprensione di questi componenti degli eventi è importante per la fase di analisi di qualsiasi progetto di controllo ed è di particolare interesse rispetto alla modalità di restituzione delle informazioni in strumenti come ACS.
Figura 3 Intestazione e corpo di un evento controllato
Figura 3 Intestazione e corpo di un evento controllato

Windows Eventing 6.0
Una volta compreso il problema, in che modo Windows Server 2008 aiuta le organizzazioni ad affrontare queste sfide? Windows Server 2008 è la prima versione server a contenere il nuovo sottosistema di eventi Windows Eventing 6.0, che migliora significativamente lo scenario correlato alla gestione degli eventi di protezione. Notare che, sebbene in questo articolo l'attenzione venga focalizzata su Windows Server 2008, il 95% del nuovo set di funzionalità esiste anche in Windows Vista.
Il primo componente di Windows Eventing 6.0 che molti utenti noteranno è la nuova interfaccia utente. Il nuovo snap-in di Microsoft Management Console (MMC), Visualizzatore eventi, offre una straordinaria pagina Panoramica e riepilogo, visualizzazioni personalizzate flessibili e testo esplicativo notevolmente migliorato. Queste interfacce consentono all'utente finale o all'amministratore di sistema di individuare le informazioni sugli eventi e di configurare importanti opzioni per i registri eventi direttamente dal Visualizzatore eventi.
Un problema chiave che ha di frequente avuto un notevole impatto sui dati di protezione all'interno del registro eventi era rappresentato dal mantenimento dei dati. In precedenza, il sottosistema Registro eventi (che includeva tutti i registri) presentava limiti di scalabilità. Se questi limiti fossero stati superati, l'intero sottosistema avrebbe interrotto la registrazione degli eventi. Questo, tuttavia, non avviene in Windows Eventing 6.0, e le organizzazioni sono ora limitate solo dalla quantità di spazio disponibile su disco. Tuttavia, tenere presente che registri eventi di dimensioni eccessive possono essere difficili da analizzare, in quanto ogni singola voce del registro deve essere valutata durante l'applicazione di filtri; pertanto, è consigliabile mantenere il registro a dimensioni gestibili.
Naturalmente, è compito dell'amministratore IT sviluppare un piano di archiviazione per i registri eventi su più sistemi. Una funzionalità, ora esposta in Windows Eventing 6.0, fornisce assistenza nello svolgimento di questa attività a livello di server locale, ovvero l'opzione "Archivia il registro quando è pieno (non sovrascrivere gli eventi). Nelle versioni precedenti di Windows, questa opzione poteva essere impostata solo direttamente tramite la modifica del valore del Registro di sistema AutoBackupLogFiles. Sebbene questa opzione fornisca un meccanismo per l'archiviazione locale dei registri, non fornisce una soluzione per la gestione di questi file nel tempo, né affronta il problema di aggregazione che si verifica su più sistemi. Audit Collection Services fornisce da questo punto di vista una soluzione completa, che verrà analizzata tra breve.
La nuova interfaccia è solo l'inizio. La vera potenza di Windows Eventing 6.0 è rappresentata dal nuovo servizio Registro eventi di Windows e dal motore basato su XML sottostante. Questi componenti garantiscono opzioni di scalabilità, accesso facilitato e gestione migliorate. Gli eventi vengono ora memorizzati in un formato XML flessibile che rende possibili soluzioni personalizzate in grado di interagire con queste informazioni in modo nativo.
Windows Eventing 6.0 fornisce inoltre la capacità di associare azioni amministrative a specifici eventi. Questo risultato viene ottenuto integrando il servizio Raccolta eventi Windows con il servizio Utilità di pianificazione in modo da garantire eventi basati su attività. Si tratta di un nuovo paradigma per il servizio Utilità di pianificazione, che in precedenza era limitato all'attivazione di eventi in base al tempo. La procedura guidata "Associa attività all'evento" (disponibile nel menu di scelta rapida di qualsiasi evento nel Visualizzatore eventi di Windows Server 2008) fornisce un metodo semplice per avviare un programma, inviare un messaggio di posta elettronica o visualizzare un messaggio ogni volta che viene registrato uno specifico evento. Questa procedura può rivelarsi molto utile quando si tenta di identificare le azioni specifiche eseguite nell'ambiente in uso che possono essere isolate in uno specifico evento di protezione. Se, ad esempio, si stanno controllando le modifiche apportate alla chiave del Registro di sistema per l'autorizzazione dell'aggiornamento dello schema nei controller di dominio, è possibile creare un'attività che consente di inviare un messaggio di posta elettronica a specifici amministratori della protezione per informarli quando questa chiave del Registro di sistema viene modificata.
Oltre alla nuova capacità di raccogliere e archiviare un numero elevato di voci di eventi, è inoltre possibile eseguire un controllo più efficace degli eventi che vengono registrati nel registro eventi. Questa operazione viene resa possibile grazie a una nuova funzionalità, criteri di controllo granulari (GAP). Nelle versioni precedenti di Windows, le nove categorie di controllo disponibili causavano in genere un sovraccarico di eventi. Queste categorie di alto livello possono essere ora controllate da 50 sottocategorie granulari,, ciascuna delle quali rappresenta un sottoinsieme correlato di eventi.
Questo consente di filtrare le informazioni non critiche dal registro eventi senza perdere visibilità a livello di categoria. Ad esempio, se su uno specifico sistema si desidera monitorare solo le modifiche apportate al Registro di sistema, ma non il file system, in precedenza era possibile scegliere solo di riportare gli eventi riusciti o non riusciti nella categoria Accesso agli oggetti. Con GAP, ora è possibile filtrare le sottocategorie, come File system, Servizi di Certificazione e Condivisione file, e riportare solo gli eventi nella sottocategoria Registro di sistema. Per esplorare le sottocategorie di GAP su un sistema Windows Server 2008, è necessario eseguire il comando Auditpol da un prompt dei comandi con privilegi elevati. Per elencare le sottocategorie di GAP disponibili, digitare quanto segue:
auditpol /list /subcategory:*
Per ottenere un elenco di sottocategorie di GAP configurate sul sistema in uso, digitare quanto segue:
auditpol /get /category:*
Tenere presente che la funzionalità GAP non è configurabile tramite l'interfaccia utente di Criteri di gruppo standard e deve essere gestita mediante auditpol.exe. L'articolo della Knowledge Base all'indirizzo support.microsoft.com/kb/921469 contiene indicazioni su come distribuire le impostazioni di GAP tramite Criteri di gruppo per i sistemi Windows Server 2008 e Windows Vista.
Windows Server 2008 è in grado inoltre di acquisire i valori nuovi e precedenti dei tipi specifici presenti nel registro eventi di protezione. Nelle versioni precedenti di Windows, il sottosistema di controllo registrava solo il nome del valore modificato del Registro di sistema o dell'attributo dell'oggetto Active Directory®, ma non registrava i valori precedenti e correnti dell'attributo. Questa nuova funzionalità si applica a Servizi di dominio Active Directory, ad Active Directory Lightweight Directory Services e al Registro di sistema di Windows. Attivando Controllo operazioni riuscite o Controllo operazioni non riuscite nelle sottocategorie "Registro di sistema" o "Modifiche servizio directory" e impostando gli elenchi di controllo di accesso di sistema associati, nel registro eventi verranno generati eventi dettagliati relativi alle azioni su questi oggetti. Questa operazione può essere eseguita utilizzando i seguenti comandi auditpol:
auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service
    Changes" /success:enable
Le modifiche al Registro di sistema vengono visualizzate come eventi ID evento 4657, come illustrato nella Figura 4.
Figura 4 Prima e dopo una modifica del Registro di sistema
Figura 4 Prima e dopo una modifica del Registro di sistema
Questa funzionalità è particolarmente utile quando si tenta di tenere traccia delle modifiche negli oggetti Active Directory. Per la sottocategoria Modifiche servizio directory, queste modifiche vengono visualizzate in un paio di eventi ID evento 5136, come illustrato nella Figura 5. Ogni evento include nel relativo corpo un'operazione, un attributo e un oggetto servizio directory. Per le modifiche agli attributi con i dati esistenti, vengono visualizzate due operazioni: Valore eliminato e Valore aggiunto. Per gli attributi che non sono stati compilati, viene visualizzata solo l'operazione Valore aggiunto quando vengono scritti dati in tali attributi. Ad esempio, quando un'operazione di modifica riuscita viene eseguita su un attributo di un oggetto utente, come telephoneNumber, Active Directory registra i valori precedenti e correnti dell'attributo in voci del registro eventi dettagliate.
Figura 5 Prima e dopo un evento Modifiche servizio directory
Figura 5 Prima e dopo un evento Modifiche servizio directory
Se viene creato un nuovo oggetto, verranno registrati i valori degli attributi che vengono compilati al momento della creazione dell'oggetto. Se un oggetto viene spostato all'interno di un dominio, verranno registrate la nuova posizione e la posizione precedente (sotto forma di nome distinto). Questa funzionalità dei valori nuovi e vecchi viene attivata per impostazione predefinita quando vengono applicate le impostazioni dei criteri di controllo appropriate. Se è presente un attributo che si desidera mantenere privato, come le modifiche al codice dipendente, è possibile escludere specificamente gli attributi eseguendo una semplice modifica dello schema. Modificando la proprietà searchFlags dell'attributo nello schema in 0x100 (valore 256 -NEVER_AUDIT_VALUE), come illustrato nella Figura 6, l'evento Modifiche servizio directory non viene generato quando vengono apportate modifiche all'attributo.
Figura 6 Esclusione di un attributo da Modifiche servizio directory
Figura 6 Esclusione di un attributo da Modifiche servizio directory
Infine, una delle più interessanti funzionalità di Windows Eventing 6.0 è rappresentata dalle sottoscrizioni di eventi. Come affermato in precedenza, l'accesso e l'analisi del registro eventi è un'attività di amministrazione del sistema fondamentale. La nuova funzionalità di sottoscrizione di eventi consente di inoltrare direttamente gli eventi tra i sistemi. Le sottoscrizioni di eventi sono costituite da un servizio Raccolta eventi, che raccoglie gli eventi, e da origini di eventi, che vengono configurate per l'inoltro di eventi agli host specificati. La possibilità di utilizzare gli eventi viene fornita dal servizio Raccolta eventi Windows (una novità di Windows Eventing 6.0), mentre la funzionalità di sottoscrizione è incorporata nel servizio Registro eventi di Windows. È possibile configurare un agente di raccolta per la raccolta di eventi da più origini eventi, che possono essere rappresentate da un sistema Windows Server 2008 o Windows Vista.
Tutti i dati raccolti dalle origini eventi risiedono in un registro eventi discreto, denominato Eventi inoltrati (ForwardedEvents.evtx), e vengono gestiti dal servizio Registro eventi nell'agente di raccolta. La configurazione su entrambi gli endpoint (agente di raccolta e origine) è necessaria e può essere automatizzata (winrm quickconfig –q nell'origine; wecutil qc /q nell'agente di raccolta). È importante notare che la funzionalità di sottoscrizione degli eventi non è stata progettata per le aziende o per sostituire i sistemi che inviano eventi a un database esterno.
Questa funzionalità potrebbe, ad esempio, essere utilizzata con una piccola Web farm. Si supponga di disporre di un piccolo insieme di sistemi associati a uno specifico sito Web, inclusi server Web e server SQL. Tali sistemi possono consolidare le relative informazioni del registro eventi di protezione su un singolo sistema utilizzando la nuova funzionalità di sottoscrizione degli eventi. Gli ambienti di maggiori dimensioni richiedono in genere un set di strumenti di consolidamento del registro eventi più avanzato.

Audit Collection Services
Considerate tutte le nuove funzionalità di Windows Server 2008, la soluzione reale per la gestione e l'archiviazione a lungo termine delle informazioni del registro eventi di protezione è rappresentata da un database centralizzato di informazioni di controllo. Audit Collection Services è una funzionalità fondamentale di System Center Operations Manager 2007. ACS fornisce un meccanismo per l'inoltro, la raccolta, l'archiviazione e l'analisi dei dati degli eventi di protezione. Gli eventi di protezione vengono raccolti quasi in tempo reale e archiviati in un archivio SQL centrale. ACS offre inoltre alle organizzazioni un metodo per fornire l'accesso con privilegi minimi alle informazioni di controllo, in quanto non è necessario l'accesso fisico ai sistemi sottoposti a controllo. Passiamo ora a esaminare il funzionamento di ACS.
ACS include tre componenti principali. Primo, il server di inoltro, che rappresenta il componente dell'agente Operations Manager che trasmette i dati dei registri eventi dal client all'infrastruttura ACS. I server di inoltro trasmettono i dati al secondo componente, l'agente di raccolta, che rappresenta il listener sul lato server. I server di inoltro di ACS si connettono attraverso la porta TCP 51909 per comunicare in modo protetto con l'agente di raccolta ad essi associato. Prima della trasmissione, i dati dei registri eventi vengono normalizzati in formato XML, il che implica che le informazioni in eccesso vengono rimosse, mentre le informazioni sugli eventi vengono riepilogate in campi mappati in base alle informazioni del corpo e dell'intestazione specifiche degli eventi. Una volta raggiunto l'agente di raccolta, le informazioni vengono inviate al terzo e ultimo componente, il database ACS. Questo database diventa l'archivio per l'archiviazione a lungo termine delle informazioni degli eventi di protezione. Una volta memorizzate, è possibile eseguire ricerche nelle informazioni direttamente tramite query SQL o eseguirne il rendering utilizzando i report HTML tramite SQL Server® Reporting Services. ACS fornisce tre visualizzazioni predefinite, come illustrato nella Figura 7.
Figure 7 Visualizzazioni ACS (Close Figure 7)

Nome della visualizzazione ACS | Scopo
AdtServer.dvHeader | Informazioni delle intestazioni da eventi raccolti.
AdtServer.dvAll | Intestazione e tutte le informazioni del corpo dagli eventi raccolti.
AdtServer.dvAll5 | Intestazione e prime cinque stringhe delle informazioni del corpo dagli eventi raccolti.
Dalla prospettiva delle prestazioni, un singolo agente di raccolta ACS può gestire un numero massimo di picco di 100.000 eventi al secondo e un numero massimo continuo di 2.500 eventi al secondo. Ai fini della pianificazione, un singolo agente di raccolta ACS è in grado di supportare fino a 150 controller di dominio, 3.000 server membro o 20.000 workstation in base alle impostazioni predefinite dei criteri di controllo. In uno scenario reale testato, circa 150 controller di dominio hanno riportato un massimo di 140 eventi circa al secondo con una media di picco di 500.000 eventi all'ora. In solo 14 giorni (l'impostazione di mantenimento predefinita per ACS), sono stati archiviati oltre 150 GB di dati di eventi di protezione nel database SQL Server. Una configurazione più "aggressiva" dei criteri di controllo e dei SACL associati genererà ovviamente un numero ancora maggiore di dati (all'ora, al giorno e a livello globale).
Il punto importante da considerare è che con questo volume di dati, nessun essere umano sarebbe in grado di esaminare ogni evento in un tipico ambiente aziendale di grandi dimensioni. Le organizzazioni, al contrario, non devono farsi intimorire dai numeri rappresentati in questo esempio. La comprensione delle modifiche che avvengono nel proprio ambiente presuppone l'inconveniente di analizzare una quantità elevata di dati.
È in tale contesto che ACS si esprime al meglio. Tramite SQL Server Reporting Services e ACS, è possibile trasformare i problemi generalmente nascosti all'interno del registro eventi di protezione in qualcosa facilmente identificabile, come gli eventi codificati a colori presenti nel registro eventi dell'applicazione. Sebbene ACS includa un insieme di report predefiniti, l'estensione di tali report per le esigenze specifiche dell'ambiente in uso è piuttosto semplice.
Si consideri il seguente scenario: a causa della riservatezza dei trust esterni nell'ambiente, il corpo direttivo ha richiesto lo sviluppo di un report in cui venga illustrata in dettaglio la creazione dei trust di Active Directory. Dopo alcune ricerche, si è scoperto che, quando si crea un trust, viene creato un oggetto trustedDomain nel contenitore cn=Sistema all'interno dello specifico contesto di denominazione del dominio in Active Directory. Dopo aver modificato il SACL in questo contenitore per controllare se la creazione di qualsiasi oggetto dominio trusted sia avvenuta in modo corretto, sarà possibile acquisire gli eventi di protezione ogni volta che viene creato un oggetto di questo tipo. Il rendering di queste informazioni viene eseguito nell'evento 566 nel registro eventi di protezione nel controller di dominio in cui è stato creato il trust. Per recuperare queste informazioni da ACS, è possibile scrivere una semplice query SQL:
select * from AdtServer.dvAll
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc
Per includere tali informazioni in un report, utilizzare la versione di Visual Studio® 2005 inclusa in SQL Server 2005 Reporting Services, in quanto specificamente progettata per lo sviluppo di report. Dopo il completamento della procedura guidata, sarà piuttosto semplice creare report molto simili a quello riportato nella Figura 8. Inoltre, qualsiasi modifica nell'ambiente che è possibile rappresentare nel registro eventi di protezione, potrà essere riepilogata in un report dall'aspetto professionale simile a quello riportato in figura.
Figura 8 Report ACS di esempio
Figura 8 Report ACS di esempio

Sviluppo di un piano di controllo
Una volta compresi i problemi e gli aspetti tecnici e legali del controllo, qual è l'iter che gli amministratori IT devono seguire per sviluppare un "piano di controllo" per la relativa organizzazione? Lo sviluppo di un criterio di controllo completo è un processo che prevede più fasi. La prima fase consiste nel determinare gli elementi da controllare. Questo include l'analisi dell'ambiente e la determinazione dei tipi di eventi e modifiche che devono generare i controlli. Questo potrebbe includere elementi semplici, come blocchi di account, modifiche a gruppi riservati e creazione di trust, o modifiche complesse, come la modifica degli elementi di configurazione all'interno delle applicazioni nel proprio ambiente. Il punto chiave è che i dirigenti devono essere coinvolti nella determinazione del "cosa" in un piano di controllo. Questo esercizio deve essere eseguito su carta e ripetuto a intervalli regolari, non solo dopo incidenti significativi.
La seconda fase consiste nell'identificare il metodo con cui le informazioni di controllo relative a specifiche modifiche vengono restituite sotto forma di eventi di protezione. Le informazioni di controllo sono a volte enigmatiche e non facilmente leggibili. Prima dell'implementazione, è necessario stabilire delle correlazioni tra gli eventi di protezione e le varie azioni per comprendere il reale significato degli eventi di protezione. Il momento immediatamente successivo al verificarsi di un problema significativo non rappresenta il momento opportuno per stabilire delle relazioni tra gli eventi e le azioni.
La terza fase prevede l'implementazione dei criteri di controllo e dei SACL. Come discusso in precedenza, è necessario definire le impostazioni dei criteri di controllo (per attivare la generazione di eventi di protezione) e i SACL (per generare gli audit trail per le azioni associate) nella directory, nel file system e nel Registro di sistema in modo da ottenere un quadro completo delle modifiche in queste aree.
Tutto questo ci porta alla quarta e ultima fase: la raccolta, i trigger e l'analisi. A seconda delle dimensioni e delle esigenze dell'organizzazione, è possibile eseguire queste operazioni utilizzando le funzionalità native di Windows Server 2008 o soluzioni avanzate, come la funzionalità Audit Collection Services di System Center Operations Manager. Un errore comune commesso dalla maggior parte delle organizzazioni è impostare solo i criteri di controllo senza definire i SACL. L'ultimo passaggio riguarda sostanzialmente l'implementazione di una soluzione tecnologica per l'inclusione di dati in report e la condivisione dei dati con gli interessati nell'organizzazione. In precedenza si è affermato che la maggior parte delle organizzazioni prevede un'entità stabilita responsabile della protezione e che un piano di controllo, per essere efficace, deve essere strutturato intorno agli elementi organizzativi esistenti. L'elemento chiave per il successo di questo passaggio finale consiste ne raccogliere e nel presentare le informazioni in modo significativo a tutti coloro che hanno la responsabilità di comprendere le modifiche nell'ambiente.
Nella maggior parte delle organizzazioni IT il verificarsi di un evento significativo è ciò che separa la semplice considerazione di un piano di controllo completo dall'effettiva adozione. Windows Server 2008 fornisce, rispetto alle piattaforme precedenti, meccanismi migliorati per la raccolta e l'analisi dei dati degli eventi di protezione. Tecnologie avanzate per la raccolta e la creazione di report, come ACS, espongono problemi una volta nascosti dal volume e dalla distribuzione degli eventi, evidenziando queste modifiche in modo immediato.
Come la maggior parte dei problemi IT, il processo rappresenta la sfida principale. Operazioni aggiuntive di configurazione e analisi sono sempre necessarie per soddisfare le aspettative dei manager IT; pertanto, una conoscenza approfondita dei requisiti dell'ambiente in uso e delle funzionalità della piattaforma Windows consentirà di far fronte a queste problematiche in modo immediato. Ricerca efficace.

Rob Campbell e Joel Yoker Rob Campbell è uno specialista tecnico senior, mentre Joel Yoker è un consulente senior del team federale Microsoft. Joel e Rob si occupano dello sviluppo e della distribuzione di soluzioni di protezione per clienti nel governo federale degli Stati Uniti.


 Dal redattore: Arriva Windows Server 2008
Dal redattore
Arriva Windows Server 2008

I prodotti vengono rilasciati in continuazione. Quando si ha un portfolio di centinaia di prodotti (migliaia, in realtà, se si considera il Web), il concetto di lancio di un prodotto può diventare quasi noioso. Ma non questa volta.
A febbraio, Microsoft ha annunciato il lancio di Windows Server 2008: non potremmo essere più entusiasti. L'attesa per questa versione è stata lunga, ma ne sarà valsa la pena. Il numero di nuove funzionalità e miglioramenti è impressionante. Potremmo parlare di IIS 7.0 (e lo faremo) o di Protezione accesso alla rete (faremo anche questo). Potremmo illustrare Server Manager, le nuove tecniche di distribuzione o le nuove funzionalità di conformità (fatto, fatto e fatto). L'elenco potrebbe andare avanti all'infinito, ma, a dire la verità, la cosa che mi colpisce di più riguardo questa nuova versione è il lavoro che è stato fatto per migliorare la gestibilità di Windows Server.
Abbiamo dedicato molto tempo a capire come potevamo semplificare la vita di un professionista IT. Detto questo, è una vera soddisfazione vedere un prodotto che si concentra così tanto sull'ottimizzazione del lavoro di un professionista IT. Come esempio, consideriamo la nuova infrastruttura per la gestione degli eventi in Windows Server 2008, trattata da Rob Campbell e Joel Yoker nel numero di questo mese. Persino i più fanatici cultori di informatica si demoralizzano quando si parla di gestione degli eventi, ma devo ammettere di essere rimasto senza parole quando ho visto le innovazioni incluse in questa versione. Dati XML, viste personalizzate, descrizioni più dettagliate, creazione di report più semplice, è quasi troppo.
Scherzi a parte, i miglioramenti principali apportati ai prodotti più venduti dall'azienda attraverso questa versione offrono buone ragioni per essere eccitati. I miglioramenti apportati ad Active Directory, IIS, rete, protezione, virtualizzazione e altro rendono questo uno dei lanci di prodotto più significativi della nostra storia. Per questo motivo, il presente numero è dedicato a tutto ciò che è necessario sapere su Windows Server 2008.
In più, abbiamo il piacere di dare il bentornato a Mark Russinovich, Technical Fellow della Platform and Service Division e creatore dei diffusi strumenti Sysinternals. Mark è l'autore di alcuni dei contenuti più ricercati nella storia di TechNet Magazine, in particolare le serie dedicate all'approfondimento delle modifiche al kernel di Windows Vista (numeri di febbraio, marzo e aprile 2007). Questo mese, Mark ha ridiscusso le serie con uno sguardo tecnico e approfondito sulle modifiche che sarà possibile trovare nel kernel di Windows Server 2008. Buon lavoro.
Joshua Hoffman

Si ringraziano i seguenti esperti tecnici Microsoft: Brandon Baker, Mai-lan Tomsen Bukovec, Bryce Cogswell, Nils Dussart, Gregoire Guetat, Brett Hill, Gaby Kaplan, Jason Leznek, Paul Mayfield, Nathan Muggli, Meg Muran, Michael Murgolo, Michael Niehaus, Raja Perumal, David Solomon, Eric Traut, Jim Truher e Landy Wang.


 Lettere: La parola ai lettori
Lettere
La parola ai lettori

Backup Windows Vista Complete PC
Grazie per lo straordinario articolo del numero di settembre 2007 su Backup Windows Vista® Complete PC ("Una guida alle tecnologie di backup di Windows Vista", technetmagazine.com/issues/2007/09/Backup). Tuttavia, non posso dire di averlo provato perché, quando viene chiesto dove posizionare l'immagine di backup, appare un messaggio che dice che l'immagine sarà posizionata sul disco rigido esterno (che è ciò che intendevo fare). Non ho però la possibilità di salvare il file in una cartella specifica sul disco rigido esterno e temo che vengano sovrascritti tutti gli altri file già presenti su tale disco. Devo preoccuparmi?
- Ben B.

Abbiamo girato la domanda all'autore, Christine Fok, che ha risposto che, in realtà, Backup Complete PC crea una cartella per l'archiviazione dell'immagine sull'unità di destinazione. Non c'è motivo di preoccuparsi, quindi, nessun dato verrà sovrascritto.

Riferimento errato alla chiave del Registro di sistema
L'articolo di dicembre 2007 "Individuazione dei problemi di rete più elusivi" (technetmagazine.com/issues/2007/12/Network) contiene un piccolo errore quando si fa riferimento alla chiave del Registro di sistema per regolare lo stack TCP/IP in Windows®. A pagina 70, l'autore, Christopher Stoneff, afferma che è possibile regolare i valori nella chiave HKLM\System\CurrentControlSet\Services\TCPIP. In realtà, la chiave corretta è HKLM\System\CurrentControlSet\Services\TCPIP\ Parameters (deve aver dimenticato di aggiungere "Parameters").
- Ingmar K.

Christopher Stoneff ha confermato che l'utente effettivamente ha ragione. La chiave include \Parameters alla fine. Ci scusiamo per l'omissione di questa parte del percorso del Registro di sistema. L'errore è stato corretto nella versione in linea dell'articolo.

Codifica dei file
Vorrei avere ulteriori informazioni sulla crittografia del file system (EFS) e ho letto l'articolo della sezione Controllo della protezione del mese di marzo 2007 "Distribuzione di EFS: parte 2" (technetmagazine.com/issues/2007/03/SecurityWatch). Dispongo di un ambiente di dominio e alcuni utenti hanno già utilizzato la codifica dei file. Ho quindi introdotto l'autorità di certificazione (CA) e i modelli EFS. La mia domanda è la seguente: se gli utenti che hanno già codificato i file con propri certificati autofirmati hanno necessità di codificare nuovi file, dovranno utilizzare il vecchio certificato autofirmato o dovranno registrare un nuovo certificato dalla mia CA? Inoltre, se tutti gli utenti dispongono di profili mobili, dove verranno archiviate le loro chiavi private?
- Ammar H.

John Morello, autore dell'articolo sulla distribuzione di EFS, ha inviato una risposta alla domanda:
dopo aver effettuato la registrazione per il nuovo certificato EFS, gli utenti inizieranno a utilizzarlo per le nuove operazioni. Tuttavia, i file codificati esistenti continueranno a essere codificati con la vecchia coppia di chiavi fino a quando non verranno aggiornati. Quindi, dopo la registrazione, è possibile eseguire cipher /u, che consente di aggiornare tutti questi file con la nuova coppia di chiavi.
Se si utilizzano profili mobili, le chiavi saranno spostate nei profili. Si consiglia di utilizzare le credenziali mobili, più leggere dei profili comuni. Per ulteriori informazioni, andare al seguente indirizzo: go.microsoft.com/fwlink/?LinkId=107469.

Espressione regolare errata
Riguardo all'articolo del mese di gennaio 2008 di Hey, Scripting Guy! intitolato "Impossibile confondere le espressioni regolari" (technetmagazine.com/issues/2008/01/HeyScriptingGuy), l'esempio che utilizza
objRegEx.Pattern = "[^A-Z][^a-z]"
potrebbe non essere quello previsto. L'esempio era volto a individuare qualsiasi carattere diverso da una lettera minuscola o maiuscola. Questo percorso, invece, viene utilizzato per trovare per una lettera maiuscola seguita da una lettera minuscola. Non funziona con una stringa come "aBcde". Probabilmente questa è la versione corretta:
objRegEx.Pattern = "[^A-Z^a-z]"
- Roger R.

Abbiamo girato la domanda agli Scripting Guy ed ecco qual è stata la risposta:
Salve, Roger. Grazie per aver sollevato la questione. Sembra che la modifica apportata all'articolo non sia stata rilevata. Nella bozza originale (che ancora conservo da qualche parte nel mio computer), in realtà, era scritto che l'operazione aveva lo scopo di trovare una lettera maiuscola seguita da una lettera minuscola. Successivamente abbiamo deciso che questo esempio non era utile quanto il rilevamento di caratteri diversi dalle lettere e, sebbene il testo sia stato modificato, è stato dimenticato di modificare il codice dell'esempio. L'errore verrà corretto nella versione in linea. Siamo spiacenti.


 Casella degli strumenti: Nuovi prodotti per professionisti IT
Casella degli strumenti
Nuovi prodotti per professionisti IT
Greg Steen

Gestione dei database SQL
SQL Sentry Event Manager
sqlsentry.net/event-manager/standard-sql-server.asp
Le dimensioni e la complessità dell'infrastruttura sono direttamente proporzionali all'impegno da dedicare alle attività di gestione e operative, con la conseguente possibilità di causare problemi nello svolgimento dei processi per gli utenti finali. Fortunatamente, esistono alcuni strumenti disponibili per gli amministratori di sistemi e database che aiutano a coordinare le pianificazioni di ambienti complessi.
Uno di questi strumenti da prendere in considerazione per l'ambiente server con più database è SQL Sentry Event Manager, un'applicazione server di Microsoft® .NET Framework che utilizza un'istanza di SQL Server® 2000 o SQL Server 2005 sul back-end. La connessione all'applicazione server viene stabilita tramite l'interfaccia utente della console SQL Sentry, che fornisce una vista unificata dei server gestiti nell'ambiente. L'applicazione server è senza agente, ma ciò, come sempre, implica che questa venga eseguita nel contesto di un utente che dispone dei diritti necessari per collegarsi ai computer e ai servizi da gestire.
Una delle caratteristiche più interessanti dell'applicazione è rappresentata dall'interfaccia utente della console che consente di ripianificare le attività server mediante trascinamento, allineando le attività di gestione e operative per evitare conflitti e tempi di inattività. Sebbene l'interfaccia utente possa sembrare complessa, consente rapidamente di individuare potenziali problemi e trovare una fascia oraria in cui spostare un'attività che crea conflitto e fornisce una vista simile a Microsoft Outlook® dei processi di SQL Agent e delle attività pianificate Windows® per i server da monitorare. La vista del calendario evidenzia le attività a esecuzione prolungata e non riuscite consentendo di individuare e risolvere i problemi che si verificano lungo il percorso.
Oltre alla funzionalità di pianificazione, SQL Sentry dispone anche di un valido sistema di notifica che sostituisce SQL Mail, MAPI, xp_sendmail o sp_send_dbmail. Instrada, inoltre, tutte le notifiche degli eventi dai server gestiti attraverso il sottosistema, fornendo un controllo centralizzato sui tipi, la frequenza e la distribuzione di tali notifiche.
Le notifiche possono essere configurate a livello globale, del server e dell'attività o processo, offrendo la granularità che la maggior parte degli amministratori si aspetta da quel tipo di evento. È possibile impostare diversi tipi di condizioni degli eventi per avviare una notifica, ad esempio quando un processo richiede troppo o troppo poco tempo, quando un indicatore delle prestazioni come l'utilizzo della CPU raggiunge una determinata soglia o quando un processo di SQL Agent viene bloccato per qualche motivo. È anche possibile configurare SQL Sentry in modo che invii notifiche in caso di modifiche della configurazione, in modo da sapere quando un utente modifica una pianificazione, sospende un controllo e così via.
SQL Sentry non gestisce solo processi di SQL Agent ed eventi dell'Utilità di pianificazione di Windows, supporta anche gli eventi di piani di manutenzione, pacchetti DTS, attività SSIS e log agente SQL.
I creatori di questi sistemi solitamente desiderano sapere se le prestazioni sono buone e in caso di tempi di attività eccellenti, desiderano probabilmente anche divulgare la notizia. SQL Sentry dispone di una serie di opzioni di reporting integrate per questo tipo di attività, che consentono di generare e stampare grafici statistici sulle prestazioni e il runtime. È possibile esportare i dati del report nei formati XML, CSV o HTML affinché possano essere inclusi negli strumenti e nei documenti di reporting.
Si noti che la versione Professional Edition consente di gestire i server Oracle oltre ad alcune funzionalità quali il monitoraggio di Reporting Services, l'accodamento dei processi di SQL Agent, il concatenamento di eventi dei server non SQL e la funzionalità di calendario per le risorse condivise.

Prezzo: Standard Edition a partire da 395 dollari.
Pianificazione della gestione con SQL Sentry
Pianificazione della gestione con SQL Sentry

Gestione dei sistemi in modalità remota
Mobile Admin
rovemobile.com/products/ma/features
Poiché non è possibile essere in più posti contemporaneamente, uno strumento di amministrazione server remoto portatile è una valida idea per i professionisti IT costretti a spostarsi frequentemente. Uno di questi strumenti è Mobile Admin di Rove Mobile (in precedenza noto come Idokorro Mobile).
Mobile Admin è una configurazione client-server in cui un server delle comunicazioni (che ha accesso ai server da gestire) interagisce con una serie di dispositivi palmari wireless. La porzione server dell'applicazione è senza agente, il che significa che non è necessario installare niente sui server che si desidera gestire. Sarà necessario, tuttavia, fornire al computer e al contesto dell'applicazione i diritti di amministrazione remota appropriati per consentire la gestione dei computer all'interno dell'infrastruttura.
È possibile accedere al server dalla maggior parte delle principali piattaforme portatili, tra cui Pocket PC e smartphone dotati di Windows Mobile® e smartphone BlackBerry. Inoltre, qualsiasi computer collegato a Internet che disponga di un browser compatibile può connettersi a Mobile Admin (presupponendo che i criteri di protezione impostati lo consentano).
Uno dei principali problemi che qualsiasi professionista di rete o sistema si trova ad affrontare in merito all'amministrazione dei dispositivi portatili è rappresentato dalla protezione. Se si utilizza BlackBerry Enterprise Server, è possibile scegliere di crittografare tutte le comunicazioni con TDES (Triple Data Encryption Standard) o AES (Advanced Encryption Standard), entrambi conformi al Federal Information Processing Standard (FIPS).
Inoltre, Mobile Admin estende la funzionalità "kill" per i dispositivi BlackBerry persi, rimuovendo il software e i dati dal telefono in modalità remota. Per gli altri palmari, è possibile implementare un VPN per proteggere le comunicazioni e/o configurare Mobile Admin in modo che utilizzi un account di accesso Windows, LDAP, RSA SecurID, un'autenticazione RADIUS o un account di accesso specifico di Mobile Admin.
Una volta stabilita la connessione, è possibile eseguire le attività di amministrazione Windows come la visualizzazione e la cancellazione dei registri eventi, il riavvio dei computer, la gestione di file e directory e la visualizzazione e la modifica delle attività pianificate.
Per quanto riguarda l'integrazione di Active Directory®, è possibile visualizzare, creare, modificare, disattivare o eliminare utenti, gruppi e computer. Allo stesso tempo, per l'amministrazione di Exchange, è possibile modificare le impostazioni delle cassette postali, bloccare e sbloccare le code di messaggi e altro ancora.
Con IIS, è possibile riavviare pool di applicazioni o siti Web e modificare le impostazioni della directory virtuale. Per i server SQL, è possibile svolgere attività quali l'esecuzione di query T-SQL, la modifica degli account di accesso e l'avvio e l'arresto dei processi di SQL Agent. Se sono in esecuzione servizi cluster, è possibile spostare gruppi, utilizzare risorse non in linea ed eseguire il failover tra le altre comuni attività amministrative.
Infine, Mobile Admin offre supporto per la gestione di Oracle, Novell LDAP, Lotus Domino, Citrix, HP iLO, Backup Exec e altri ancora.

Prezzo: a partire da 245 dollari per server.

Recensione
Mastering Windows Network Forensics and Investigation
sybex.com
Anche se si dispone di hardware e procedure necessari per rilevare e ridurre le minacce per la rete, è possibile che non si conoscano le procedure o non si disponga dei protocolli necessari per la ricerca e per procedere legalmente contro gli autori di un attacco subìto.
Qui entra in gioco il manuale Mastering Windows Network Forensics and Investigation (Sybex, 2007), redatto per far acquisire le competenze necessarie sulla ricerca delle intrusioni nella rete Windows, da episodi di lieve entità su singoli computer (come l'utilizzo inappropriato dei servizi della società) ad attacchi più diffusi e dannosi contro sistemi critici.
Nel manuale viene illustrato all'utente il processo di raccolta delle prove, mediante un'ampia gamma di argomenti tra cui interviste e tracce di registri ed eventi controllati. Viene spiegato dove e come raccogliere prove dai computer e dalle reti Windows tramite strumenti quali WireShark, LogParser, EnCase e il set di strumenti SysInternals.
Inoltre, vengono esaminate le informazioni che è possibile acquisire dal Registro di sistema, i contenuti e la struttura del file system, i registri basati su testo, i registri eventi e i processi sui computer in questione. Viene illustrato anche come creare un CD di analisi, che contiene gli strumenti necessari all'individuazione delle prove richieste. Infine, nel manuale viene descritto come presentare i risultati della ricerca, illustrando linee guida e procedure per testimoniare in tribunale.

Prezzo: $59.99.

Raccolta dei dati di sistema
MetaLAN
hammer-software.com/metalan.shtml
L'amministrazione centralizzata è uno dei componenti principali di una corretta gestione dei sistemi. Eliminando numerose operazioni inutili, consente di risparmiare tempo prezioso riducendo così lo stress legato al lavoro.
MetaLAN di Hammer Software è uno strumento che consente di gestire e supportare utenti e server sulla rete Windows. Questa applicazione senza agente consente di raccogliere velocemente informazioni, apportare modifiche alla configurazione e gestire in generale i computer Windows. Ciò, naturalmente, richiede i diritti e il contesto utente necessari.
MetaLAN dispone di due modalità operative. È possibile scegliere di eseguire questo strumento direttamente in modalità di amministratore (collegandolo ai computer che si desidera interrogare o di cui si desidera modificare le proprietà) o è possibile utilizzare l'agente/servizio componente aggiuntivo gratuito, ProbeServer, sul computer remoto insieme a MetaLAN in esecuzione in modalità server per controllare continuamente le workstation.
Avviando l'applicazione viene visualizzata l'interfaccia utente del pannello di controllo MetaLAN, che consente di esaminare la rete in uso in cerca di domini da gestire. Qui, è anche possibile avviare i componenti dei diversi strumenti, ad esempio Help Desk, Report, Software e RegCast.
Lo strumento Help Desk fornisce una vista di ricerca ed esplorazione per i computer nel dominio gestito. Selezionando un computer viene visualizzata una serie di informazioni utili sul computer stesso, tra cui il produttore, gli indirizzi IP, i processori, le unità, gli indirizzi MAC e i ruoli del server. A questo punto, è possibile eseguire le query di Strumentazione gestione Windows (WMI), collegarsi ai monitoraggi delle prestazioni in tempo reale, visualizzare il software installato ed eseguire altre utili attività amministrative.
Lo strumento Report fornisce viste grafiche rapide ed esportabili dei nodi gestiti. Ad esempio, è possibile generare un grafico a torta delle velocità della CPU di tutti i computer nella rete o verificare su quali computer è installato Windows XP Service Pack 2.
Lo strumento Software consente di visualizzare ed esportare rapidamente gli elenchi del software installato su un gruppo di N computer nella rete, uno strumento molto utile per i controlli.
Lo strumento RegCast consente di visualizzare (e modificare se si è amministratore dell'organizzazione o di dominio) le informazioni del Registro di sistema sui computer remoti di un determinato gruppo di computer.
MetaLAN contiene anche uno strumento per distribuire e installare in modalità remota i pacchetti di Microsoft Installer (MSI) (se supportano l'installazione invisibile all'utente), una panoramica sull'archiviazione che mostra le unità sui computer e la quantità di spazio disponibile e uno strumento di amministrazione dei servizi che consente di avviare, arrestare e rimuovere i servizi. Se tutto questo non fosse sufficiente, esiste uno strumento di controllo remoto denominato Virtual Network Computing (VNC) che fornisce un piccolo file eseguibile VNC la cui esecuzione garantisce il controllo remoto sul computer (molto simile ad Assistenza remota).

Prezzo: a partire da 75 dollari per un pacchetto licenze di 20 nodi.
Lo strumento Help Desk fornisce una vista di ricerca ed esplorazione
Lo strumento Help Desk fornisce una vista di ricerca ed esplorazione

Attività automatizzate
AutoHotkey
autohotkey.com
L'automazione può essere la migliore amica di un professionista IT in quanto consente di evitare tutte le attività ripetitive per le quali si perde moltissimo tempo. L'utilità AutoHotkey è uno dei tanti strumenti disponibili a tal fine. Questo strumento gratuito open-source consente di semplificare le routine dei desktop automatizzando quasi tutte le attività che richiedono input da tastiera, mouse o joystick. È un tasto di scelta basato su script e uno strumento per le macro avanzato.
AutoHotkey viene eseguito nella barra delle applicazioni, all'avvio esegue la definizione di script creata ed esegue singoli comandi di script nell'ordine in cui vengono visualizzati nel file di script. Ciò è molto utile, ad esempio, per eseguire le applicazioni preferite all'avvio. Un momento, però, c'è dell'altro: è infatti possibile definire un numero qualsiasi di tasti di scelta rapida e stringhe di scelta rapida.
I tasti di scelta rapida sono combinazioni di tasti definite per eseguire un'azione, ad esempio avviare un'applicazione, richiamare finestre in primo piano o simulare l'azione di scorrimento della rotellina del mouse.
Le stringhe di scelta rapida sono invece abbreviazioni di testo utilizzate per espressioni o comandi digitati frequentemente. Queste stringhe di scelta rapida possono essere utilizzate anche per avviare un'azione con script allo stesso modo di un tasto di scelta rapida. Ad esempio, è possibile creare una stringa di scelta rapida con la semplice sequenza di tasti "td" per aprire Microsoft Word e scrivere la data odierna nel formato desiderato. Nel caso invece di un messaggio inviato frequentemente agli utenti, è possibile creare una semplice stringa di scelta rapida per riportare automaticamente il testo in un nuovo messaggio di Outlook.
Il linguaggio di script stesso supporta variabili, espressioni per operazioni di calcolo e di stringa, variabili globali incorporate, funzioni, loop e istruzioni condizionali, consentendo di creare uno script adatto alle esigenze amministrative del sistema. In totale, esistono oltre 100 comandi e costrutti dei linguaggi utili. Ad esempio, è possibile simulare un'operazione di trascinamento con il mouse, mostrare finestre di messaggi, eseguire operazioni asincrone, inviare messaggi di posta elettronica, modificare il Registro di sistema, impostare i timer all'interno dei loop in modo da effettuare controlli ricorrenti, aprire applicazioni, chiudere finestre ed eliminare processi.
Un'altra importante funzionalità di AutoHotkey consente di compilare gli script per riutilizzarli e distribuirli una volta adattati alle proprie esigenze. In questo modo, gli utenti che non dispongono di AutoHotkey possono comunque sfruttare i collegamenti e gli script. Grazie alla licenza del progetto open source, è possibile distribuirli o venderli senza limitazioni.
Nell'organizzazione interna, è possibile distribuire facilmente agli utenti finali uno script eseguibile che effettua alcune personalizzazioni che altrimenti dovrebbero essere effettuate manualmente sui computer desktop. Inoltre, se si desidera adattare tali script per ogni utente, AutoHotkey accetta anche parametri e opzioni della riga di comando in modo da ottenere risultati utile e riutilizzabili nel dominio.
A differenza di molti progetti open source, che spesso mancano di documentazione approfondita, la documentazione di AutoHotkey è esauriente e ben strutturata e illustra come trasferire le attività automatizzate fornendo molti esempi utili. Inoltre, sul sito Web del progetto, è possibile trovare un forum attivo per gli utenti che può essere d'aiuto per qualsiasi domanda e un wiki che contiene script, esercitazioni e una guida di riferimento dei comandi. Esiste anche una pagina di presentazione degli script che offre alcuni validi esempi forniti dagli utenti.

Prezzo: gratuito.
AutoHotKey può compilare gli script per il riutilizzo e la distribuzione
AutoHotKey può compilare gli script per il riutilizzo e la distribuzione

Greg Steen è un professionista IT oltre ad essere un appassionato imprenditore. È sempre alla ricerca di nuovi strumenti che aiutino a rendere più semplici le operazioni e lo sviluppo per i professionisti IT.


 Utilit&#224; in primo piano: Windows Server Logo Certification
Utilità in primo piano
Windows Server Logo Certification
Venkat Krishnamachari
Scarica il codice per questo articolo: Works with Windows Server 2008 (KB)

Con Windows Server® 2008 Software Certification, Microsoft desidera aiutare gli sviluppatori a seguire le procedure consigliate e consente ai professionisti IT di valutare le applicazioni prima dell'acquisto, per ridurre i tempi ed evitare eventuali problemi. Per consentire ai clienti di valutare la compatibilità delle applicazioni, Microsoft ha creato il programma "Works with Windows Server 2008", che include strumenti gratuiti per effettuare test e che consentono di garantire la prevedibilità delle prestazioni di un'applicazione.
Lo strumento "Works with" raccoglie i dati relativi all'impatto di un'applicazione sul sistema operativo durante il ciclo di vita monitorando lo stato del file system, del Registro di sistema, dei servizi e dei driver. Successivamente lo strumento analizza questi dati e registra l'esito positivo o negativo dei test case specifici. Per ulteriori informazioni, consultare il documento relativo al framework di test di "Works with" e altri strumenti disponibili alla pagina windowsservercatalog.com/ready. Tali strumenti mettono gli ISV in condizione di poter garantire la compatibilità di un'applicazione, consentendo al contempo ai professionisti IT di valutare l'idoneità di un'applicazione alla distribuzione in Windows Server 2008.
Per utilizzare questi strumenti, è necessario installare innanzitutto l'ultima versione di Windows Server 2008 in un computer di test, scaricare lo strumento "Works with" da windowsservercatalog.com/ready e accertarsi di aver selezionato anche lo strumento Application Verifier. La GUI dello strumento presenta quattro semplici funzioni che consentono di creare un test, riprendere un test esistente, visualizzare i risultati del test e creare un pacchetto di invio (per gli ISV che cercano la convalida "Works with" da un fornitore di test autorizzato).
Report dei risultati in formato testo
Report dei risultati in formato testo
Per creare un test, è necessario esaminare l'intero ciclo di vita di un'applicazione: installazione, configurazione, esecuzione e disinstallazione. Lo strumento "Works with" viene eseguito principalmente in background, verificando la stabilità del sistema operativo e la compatibilità del programma di installazione, inoltre controlla se le funzionalità vengono eseguite correttamente rispettando i nuovi requisiti di protezione e altre funzionalità configurabili della piattaforma. In genere è preferibile completare il test e generare l'intero report, operazione che richiede di solito dalle due alle quattro ore. Tuttavia, è possibile interrompere il test, generare un report veloce e riprendere il test in un secondo momento.
Al termine, si ottengono i report sullo stato contrassegnati dal colore rosso o verde per ciascun test case con risultati dettagliati, come quelli illustrati nella screenshot. I test contrassegnati dal colore verde indicano la compatibilità. Per i risultati in rosso, invece, è possibile riesaminare un file di registro e cercare di capire la condizione di errore. Accertarsi di aver salvato i log generati in locale su un altro computer in modo da potervi fare riferimento dopo aver ripulito il computer di test. Lo strumento "Works with" viene eseguito su qualsiasi applicazione server e può anche valutare i componenti client e gli strumenti di gestione progettati per Windows Vista®.
Se si utilizza un software commerciale, lo strumento "Works with" consente di pianificare la migrazione di applicazioni compatibili. È possibile utilizzare i risultati del test per interrogare i fornitori sui piani di supporto, consentendo al tempo stesso agli sviluppatori di ridurre i tempi per il rilevamento dei problemi di compatibilità e l'assegnazione delle priorità alle correzioni. Per le applicazioni personalizzate, è possibile fornire ai team di sviluppo commenti e suggerimenti estremamente specifici. Inoltre, è possibile garantire una compatibilità costante man mano che vengono rilasciate nuove patch e documentare i dati sulla configurazione dell'applicazione per il reparto IT. Alcuni clienti hanno utilizzato gli strumenti per documentare i file utilizzati dalle applicazioni di sistema.
Sono graditi eventuali commenti o suggerimenti per migliorare i test case o gli strumenti al fine di aumentare l'utilizzabilità nell'ambiente. Scrivici all'indirizzo wslogofb@microsoft.com.

Venkat Krishnamacharilavora dal 2005 come responsabile tecnico di Windows Server Software Certification mentre in passato ha collaborato con il team di SQL Server 2005.


 The Cable Guy: Eseguire la migrazione di Intranet a IPv6 con ISATAP
The Cable Guy
Eseguire la migrazione di Intranet a IPv6 con ISATAP
Joseph Davies
Questo articolo è basato su una versione non definitiva di Windows Server 2008. Tutte le informazioni riportate sono soggette a modifica.

Un dubbio comune relativo al protocollo IPv6 riguarda il fatto che, per utilizzarlo, è necessario distribuire indirizzamento e routing IPv6 nativi, il che richiede un'analisi dettagliata degli schemi di indirizzamento IPv6, configurazione e aggiornamenti del router e una pianificazione dell'implementazione. Sebbene queste operazioni andrebbero eseguite per la
connettività IPv6 nativa, è possibile distribuire con facilità la connettività IPv6 con tunnel tramite Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). Con la connettività IPv6 con tunnel, gli host che supportano ISATAP possono comunicare utilizzando il traffico IPv6 incapsulato con un'intestazione IPv4 (il campo del protocollo IPv4 è impostato su 41). Il traffico ISATAP può attraversare una Intranet solo IPv4, è così possibile iniziare a testare immediatamente le applicazioni compatibili con IPv6, senza dover attendere un'infrastruttura IPv6 nativa.
ISATAP è una tecnologia di assegnazione degli indirizzi e di tunneling automatico definita in RFC 4214 che fornisce la connettività IPv6 unicast tra gli host IPv6/IPv4 attraverso una Intranet solo IPv4. Gli host ISATAP utilizzano un'interfaccia di tunneling logica assegnata agli indirizzi ISATAP, che dispone del modulo UnicastPrefix:0:5EFE:w.x.y.z (quando w.x.y.z è un indirizzo IPv4 privato assegnato all'host ISATAP) o UnicastPrefix:200:5EFE:w.x.y.z (quando w.x. y.z è un indirizzo IPv4 pubblico assegnato all'host ISATAP). UnicastPrefix indica qualsiasi prefisso di indirizzo unicast a 64 bit, inclusi i prefissi locali al collegamento, globali e locali univoci. 2001:DB8::98CA:200:131.107.28.9 e 2001:DB8::98CA:0:10.91.211.17 sono esempi di indirizzi ISATAP.

Migrazione di Intranet a IPv6 con ISATAP
Una distribuzione ISATAP è costituita da una o più subnet ISATAP logiche, reti solo IPv4 assegnate al prefisso di subnet IPv6 a 64 bit. Su una subnet ISATAP logica vi sono host ISATAP e router ISATAP. Un host ISATAP utilizza un'interfaccia di tunneling ISATAP per incapsulare il traffico IPv6. Questo traffico può essere inviato direttamente ad altri host ISATAP sulla stessa subnet ISATAP logica. Per raggiungere destinazioni che si trovano su altre subnet ISATAP o su subnet IPv6 native, il traffico viene inviato a un router ISATAP. Un router ISATAP è un router IPv6 che annuncia i prefissi di subnet agli host ISATAP e inoltra il traffico IPv6 tra gli host ISATAP e gli host su altre subnet IPv6. Nella Figura 1 vengono illustrati i componenti di ISATAP su una Intranet semplificata.
Figura 1 Porzioni compatibili con IPv6 e solo IPv4 della rete Intranet
Figura 1 Porzioni compatibili con IPv6 e solo IPv4 della rete Intranet
ISATAP consente di distribuire le funzionalità di indirizzamento e routing IPv6 nativi sulla rete Intranet in tre fasi.
Fase 1: Intranet solo IPv4 In questa fase, l'intera rete Intranet può essere un'unica subnet ISATAP logica. Nella Figura 2 viene riportato un esempio con una rete Intranet solo IPv4 con un router ISATAP che annuncia esclusivamente un prefisso di indirizzo locale univoco o globale agli host ISATAP.
Figura 2 Una Intranet solo IPv4
Figura 2 Una Intranet solo IPv4
Fase 2: porzioni compatibili con IPv6 e solo IPv4 della rete Intranet In questa fase intermedia, la rete Intranet dispone di una porzione solo IPv4 (la subnet ISATAP logica) e di una porzione compatibile con IPv6. La porzione compatibile con IPv6 dell'Intranet supporta IPv4 ed è stata aggiornata per supportare l'indirizzamento e il routing IPv6 nativi. Questa configurazione è illustrata nella Figura 1.
Fase 3: Intranet compatibile con IPv6 In questa fase finale, l'intera Intranet supporta sia IPv4 che l'indirizzamento e il routing IPv6 nativi. Si noti che ISATAP non è più necessario. Nella Figura 3 viene riportato un esempio.
Figura 3 Intranet compatibile con IPv6
Figura 3 Intranet compatibile con IPv6
Con ISATAP, è possibile disporre di connettività IPv6 tra gli host e le applicazioni durante le prime due fasi della transizione da una rete Intranet solo IPv4 a una compatibile con IPv6.

Windows Server 2008 e Windows Vista
Il protocollo IPv6 per Windows Server® 2008 e Windows Vista® supporta ISATAP sia sotto forma di host ISATAP che come router ISATAP. Esiste un'interfaccia di tunneling ISATAP separata per ogni interfaccia LAN installata sul computer che dispone di un suffisso DNS differente. Ad esempio, se un computer su cui è in esecuzione Windows Vista dispone di due interfacce LAN entrambe associate alla stessa rete Intranet e assegnate allo stesso suffisso DNS, vi sarà solo un'interfaccia di tunneling ISATAP. Se queste due interfacce LAN sono associate a due reti diverse con suffissi DNS diversi, vi saranno due interfacce di tunneling ISATAP. Per i computer su cui è in esecuzione Windows Server 2008 o Windows Vista SP1, le interfacce di tunneling ISATAP sono posizionate in uno stato di supporto disconnesso a meno che il nome "ISATAP" non possa essere risolto.
Per impostazione predefinita, il protocollo IPv6 per Windows Vista senza Service Pack installati configura automaticamente gli indirizzi ISATAP locali al collegamento (FE80::5EFE: w.x.y.z o FE80::200:5EFE:w.x.y.z) sulle interfacce tunnel ISATAP per gli indirizzi IPv4 assegnati alle interfacce LAN corrispondenti.
Il protocollo IPv6 per Windows Server 2008 e Windows Vista SP1 configura gli indirizzi ISATAP locali al collegamento sulle interfacce tunnel ISATAP solo se il nome "ISATAP" può essere risolto.
Per ricevere un messaggio di annuncio router dal router ISATAP, l'host ISATAP deve inviare al router ISATAP un messaggio di richiesta router. Su una subnet Ethernet, un host IPv6 nativo invia un messaggio di richiesta router multicast e, successivamente, i router sulla subnet rispondono con un messaggio di annuncio router. Poiché ISATAP non utilizza il traffico multicast IPv4 né richiede un'infrastruttura compatibile con il multicast IPv4, l'host ISATAP deve trasmettere in unicast il messaggio di richiesta router al router ISATAP.
Per trasmettere in unicast il messaggio di richiesta router al router ISATAP, l'host ISATAP deve prima determinare l'indirizzo IPv4 unicast dell'interfaccia del router ISATAP sulla subnet ISATAP logica. Per il protocollo IPv6 per Windows Server 2008 e Windows Vista, un host ISATAP ottiene l'indirizzo IPv4 unicast del router ISATAP attraverso la risoluzione del nome host "ISATAP" in un indirizzo IPv4 o con il comando netsh interface isatap set router.

Migrazione della rete Intranet: Fase 1
Per distribuire ISATAP sulla rete Intranet per la fase 1 della migrazione a IPv6, procedere come segue:
Determinare il prefisso di subnet ISATAP È necessario determinare il prefisso di subnet a 64 bit da assegnare alla subnet ISATAP logica corrispondente alla rete Intranet. È possibile ottenere un prefisso a 48 bit da un ISP o un registro Internet o derivare il proprio prefisso locale univoco a 48 bit (vedere la specifica RFC 4193 in linea all'indirizzo tools.ietf.org/html/rfc4193).
Dal prefisso a 48 bit, scegliere un ID di subnet a 16 bit per la subnet ISATAP logica. La combinazione del prefisso a 48 bit e dell'ID di subnet a 16 bit è il prefisso della subnet ISATAP a 64 bit. Ad esempio, il prefisso locale univoco a 48 bit FD8A:219C:052A::/48 e l'ID di subnet 1 formano il prefisso di subnet a 64 bit FD8A:219C:052A:1::/64.
Specificare un computer router ISATAP Determinare quale computer sarà il router ISATAP. Sebbene molti router commerciali supportino la funzionalità di router ISATAP, le informazioni qui riportate riguardano i computer su cui è in esecuzione Windows Server 2008.
Il computer router ISATAP non necessita di più interfacce LAN, né di essere collegato a una porzione compatibile con IPv6 della rete Intranet per la fase 1; tuttavia, il computer successivamente deve poter essere aggiornato con un'interfaccia LAN aggiuntiva collegata alla porzione compatibile con IPv6 della rete Intranet.
Configurare il computer router ISATAP Sul computer router ISATAP, l'uso del comando che segue consente di posizionare le interfacce di tunneling ISATAP sul computer router ISATAP in uno stato di supporto connesso:
netsh interface isatap set router IPv4Address
IPv4Address indica l'indirizzo IPv4 assegnato all'interfaccia LAN del computer router ISATAP associato alla subnet ISATAP logica.
Successivamente, determinare il nome o l'indice di interfaccia dell'interfaccia di tunneling ISATAP corrispondente all'interfaccia LAN del computer router ISATAP associato alla subnet ISATAP logica, tutto tramite l'output di questo comando:
netsh interface ipv6 show interfaces
Successivamente, utilizzare questo comando per attivare la funzionalità di annuncio sull'interfaccia ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex advertise=enabled
ISATAPInterfaceNameOrIndex è il nome o l'indice di interfaccia dell'interfaccia di tunneling ISATAP.
Successivamente, utilizzare questo comando per configurare il computer router ISATAP in modo che annunci il prefisso di subnet ISATAP agli host ISATAP:
netsh interface ipv6 add route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex publish=yes
ISATAPSubnetPrefix indica il prefisso di subnet ISATAP determinato
Configurare il DNS Nel DNS, aggiungere un record (A) di indirizzi per il nome ISATAP ai domini appropriati affinché gli host ISATAP sulla rete Intranet possano risolvere il nome "ISATAP". Ad esempio, se gli host Intranet utilizzano il suffisso DNS contoso.com, è necessario aggiungere un record A al dominio contoso.com per il nome isatap.contoso.com con l'indirizzo IPv4 assegnato all'interfaccia LAN del router ISATAP sulla rete Intranet solo IPv4.
Se sul server DNS è in esecuzione Windows Server 2008, utilizzare l'editor del registro di sistema (regedit.exe) sul server DNS per rimuovere la voce ISATAP dal valore del Registro di sistema HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList.
Testare gli host ISATAP Da un host ISATAP sulla rete Intranet, utilizzare lo strumento Ipconfig per visualizzare gli indirizzi assegnati. Gli host ISATAP devono disporre di un indirizzo con il formato ISATAPSubnetPrefix:: 5EFE:w.x.y.z o ISATAPSubnetPrefix:: 200:5EFE:w.x.y.z. Ad esempio, se il prefisso di subnet ISATAP è FD8A:219C: 052A:1::/64 e un host ISATAP dispone dell'indirizzo IPv4 10.1.31.97, l'host ISATAP deve avere l'indirizzo FD8A: 219C:052A:1::5FE:10.1.31.97 assegnato alla relativa interfaccia di tunneling ISATAP.
Se un host ISATAP non dispone di un indirizzo ISATAP basato sul prefisso di subnet ISATAP, verificare che l'host possa risolvere il nome "ISATAP". In caso negativo, verificare che i record A siano stati creati nei domini appropriati e, per i server DNS su cui è in esecuzione Windows Server 2008, verificare che il valore del Registro di sistema GlobalQueryBlockList sia stato modificato per rimuovere la voce ISATAP. Se il nome può essere risolto, verificare che il computer router ISATAP sia stato configurato correttamente. In caso positivo, verificare che i router sulla rete Intranet consentano l'inoltro del traffico 41 del protocollo IPv4.
Quando gli host ISATAP possono configurarsi correttamente con indirizzi basati sul prefisso di subnet ISATAP, registrano questi indirizzi ISATAP come record AAAA in DNS e iniziano a utilizzarli per la connettività basata su IPv6.

Migrazione della rete Intranet: Fase 2
Nella fase 2 della migrazione a IPv6, è necessario modificare la configurazione del router ISATAP per eseguire l'inoltro tra le porzioni solo IPv4 e compatibili con IPv6 della rete Intranet.
Sul computer router ISATAP, inserire il comando seguente:
netsh interface ipv6 show interfaces
Dall'output del comando sopra riportato, determinare il nome o l'indice di interfaccia dell'interfaccia LAN associata alla porzione compatibile con IPv6 della rete Intranet e l'interfaccia di tunneling ISATAP.
Utilizzare questo comando per attivare l'inoltro sull'interfaccia ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=enabled
Utilizzare questo comando per attivare l'inoltro sull'interfaccia LAN:
netsh interface ipv6 set interface LANInterfaceNameOrIndex forwarding=enabled
LANInterfaceNameOrIndex è il nome o l'indice di interfaccia dell'interfaccia LAN.
Utilizzare il comando seguente per aggiungere una route predefinita al router ISATAP:
netsh interface ipv6 add route ::/0 LANInterfaceNameOrIndex NextHopAddress publish=yes
NextHopAddress è l'indirizzo IPv6 di un vicino router IPv6 nativo sulla porzione compatibile con IPv6 della rete Intranet.
Per rendere la subnet ISATAP logica raggiungibile dalla porzione compatibile con IPv6 della rete Intranet, è importante configurare i router IPv6 nativi con una route per il prefisso di subnet ISATAP che si riferisca al computer router ISATAP.
Per disattivare in modo selettivo ISATAP per i computer sulla porzione compatibile con IPv6 della rete Intranet, manipolare i record A per il nome ISATAP nel DNS affinché i computer sulla porzione compatibile con IPv6 della rete Intranet non possano risolvere il nome ISATAP.
Un'altra possibilità consiste nel creare e impostare il valore del Registro di sistema HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents su 0x4 (tipo DWORD).

Migrazione della rete Intranet: Fase 3
Per la fase 3, quando l'intera rete Intranet è compatibile con IPv6, sarà necessario rimuovere la distribuzione di ISATAP attraverso DNS e riconfigurare il computer router ISATAP. Per DNS, rimuovere tutti i record A per il nome ISATAP. Ciò impedirà a tutti gli host di determinare l'indirizzo IPv4 del router ISATAP.
Per il computer router ISATAP, eseguire il comando seguente:
netsh interface isatap set router default
Questo comando reimposta il componente ISATAP sullo stato predefinito.
Determinare il nome o l'indice di interfaccia dell'interfaccia di tunneling ISATAP dall'output di questo comando:
netsh interface ipv6 show interfaces
Utilizzare questo comando per disattivare le funzionalità di inoltro e annuncio sull'interfaccia ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=disabled advertise=disabled
Utilizzare questo comando per rimuovere la route del prefisso di subnet ISATAP dal computer router ISATAP:
netsh interface ipv6 delete route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex
ISATAPSubnetPrefix indica il prefisso di subnet ISATAP.
Per ulteriori informazioni sulla distribuzione di ISATAP, nonché considerazioni sui router ISATAP ridondanti e sul firewall, vedere la "Guida alla distribuzione di Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)" all'indirizzo go.microsoft.com/fwlink/?LinkId=106926.

Joseph Davies è un autore tecnico di Microsoft. Dal 1992 tiene corsi e scrive su argomenti legati alle reti Microsoft. Ha scritto otto libri per Microsoft Press ed è autore della rubrica mensile Cable Guy di TechNet. È possibile trovare ulteriori informazioni sulla rubrica The Cable Guy all'indirizzo microsoft.com/technet/community/columns/cableguy/about.mspx.


 Windows PowerShell: Report di stato
Windows PowerShell
Report di stato
Don Jones

Di recente mi è capitato di scrivere uno script di Windows PowerShell piuttosto lungo e complicato che, man mano che veniva eseguito, funzionava sempre meno. Tale script doveva essere eseguito come un'attività pianificata, dunque non ha prodotto di fatto un output visibile. Quando ho eseguito lo script per sottoporlo al primo grande test, ho iniziato tuttavia a preoccuparmi
di aver scritto accidentalmente un ciclo infinito o un tipo di script problematico.
E vedendo la Shell immobile, con il cursore che lampeggiava pateticamente, mi sono chiesto: "L'ho uccisa?" Non avendo alcuna fiducia in me stesso ho premuto rapidamente la combinazione di tasti Ctrl+C per interrompere lo script. Tempo necessario per aggiungere il report di stato.

Parole, parole, parole
Cmdlet del mese: Tee-Object
Nell'articolo di questo mese intendo esaminare uno dei miei cmdlet preferiti per la risoluzione dei problemi. Prendiamo, ad esempio, questa riga:
Get-WMIObject Win32_Service | Where { $_.State -ne "Running"
-and $_.StartMode -eq "Automatic" } | ForEach-Object { $_.Start() }
In apparenza, sembrerebbe avviare tutti i servizi impostati su avvio automatico, ma che per un motivo non precisato non sono stati ancora avviati. In effetti lo script non funziona e cercare di scoprirne il motivo non è facile poiché non è possibile analizzare a fondo la pipeline. O meglio, non è possibile analizzare a fondo la pipeline a meno che non si utilizzi Tee-Object.
Tee-Object reindirizza gli oggetti a un file (o in una variabile) e li passa alla pipeline. Ad esempio:
Get-WMIObject Win32_Service | Tee-Object AllServices.csv | Where
{ $_.State -ne "Running" -and $_.StartMode -eq "Automatic" } |
Tee-Object FilteredServices.csv | ForEach-Object { $_.Start() }
Questa modifica mi consente di capire cosa accade dopo ogni comando della pipeline e scopro quasi subito che il mio file FilteredServices.csv non contiene nulla! Non c'è da meravigliarsi se questo script non funziona! Una ricerca più approfondita rivela la causa principale del problema: StartMode è "Auto" non "Automatico" e Tee-Object mi consente di individuare esattamente dove risiede il problema.

La prima cosa da fare è aggiungere un gruppo di messaggi di stato che mi consentano di conoscere esattamente il funzionamento dello script. Questa operazione è resa possibile dalla Shell con il cmdlet Write-Verbose. Procediamo e proviamolo nella Shell:
Write-Verbose "Test Message"
Se hai già provato, avrai notato che non funziona. Ciò avviene perché Write-Verbose invia gli oggetti alla pipeline Verbose speciale che, per impostazione predefinita, non visualizza l'output. Una variabile Shell incorporata, $VerbosePreference, controlla questa pipeline. Il valore predefinito di questa variabile è SilentlyContinue, che elimina l'output dettagliato. Se viene impostata su Continue, tuttavia, apre la pipeline:
$VerbosePreference = "Continue"
A questo punto, è possibile aggiungere allo script un gruppo di istruzioni Write-Verbose ed esaminare più a fondo cosa accade durante la relativa esecuzione. Uno degli aspetti più affascinanti di questa tecnica è che, una volta terminate le fasi di verifica e di risoluzione dei problemi, è possibile impostare $VerbosePreference nuovamente su SilentlyContinue all'inizio dello script.
Non è affatto necessario rimuovere tutte le istruzioni Write-Verbose. Infatti, poiché rimangono nello script, se fosse necessario eseguire lo script manualmente, sarebbe possibile attivare nuovamente la pipeline Verbose.

Ma la cosa importante è che lo script possa proseguire
Una volta stabilito che lo script non era stato imprigionato in un ciclo infinito e che, di fatto, funzionava bene, ho interrotto la pipeline Verbose e ho eseguito nuovamente lo script, tanto per essere sicuro.
Il problema a questo punto è che nonostante fosse noto che lo script funzionava perfettamente bene, non potevo sopportare di rimanere incantato davanti a un cursore lampeggiante. (Per affrontare i miei problemi di attenzione, ho cercato disperatamente della vernice, mi sono seduto e l'ho guardata mentre si asciugava.)
Ciò di cui avevo bisogno era un'indicazione generale sullo stato di avanzamento dello script e un'idea su quando sarebbe terminato. Fondamentalmente, desideravo qualcosa di simile a un indicatore di stato
e, fortunatamente, Windows PowerShellTM contiene il cmdlet Write-Progress. Questo cmdlet non fornisce un indicatore di stato come quello di Windows® ma ciononostante produce un indicatore di stato utile, come illustrato nella Figura 1. Si presenta più o meno come l'indicatore di stato della copia di file utilizzato dall'impostazione basata sul testo di Windows Server® 2003 o Windows XP.
Figura 1 Qual è lo stato di avanzamento dello script?
Figura 1 Qual è lo stato di avanzamento dello script?
L'utilizzo di Write-Progress richiede alcune spiegazioni. Anzi, in realtà, penso sia meglio un esempio. Prendiamo in considerazione questo script:
for ($a=1; $a -lt 100; $a++) {
  Write-Progress -Activity "Working..." `
   -PercentComplete $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
Lo script in questione utilizza Write-Progress per visualizzare un indicatore di stato. Ho utilizzato Start-Sleep affinché lo script si interrompesse per un secondo, questo per ogni iterazione del ciclo, in modo che la sua esecuzione fosse sufficientemente lenta da consentire di visualizzarne lo stato; senza pausa, il ciclo passa da 0 a 100 così rapidamente che l'indicatore di stato lampeggia brevemente sullo schermo.
Come si può notare, l'attività, impostata su Working, viene illustrata nella parte superiore dell'indicatore di stato, seguita dallo stato, mentre CurrentOperation viene illustrato nella parte inferiore. La Shell supporta soltanto un unico indicatore di stato alla volta. Qualsiasi utilizzo di Write-Progress crea un nuovo indicatore di stato, nel caso non ve ne fosse già uno, o aggiorna l'indicatore esistente attualmente visualizzato.
Ciò che non ho fatto qui è far sparire la barra al termine dello script. A tale scopo, è possibile aggiungere semplicemente quanto segue alla fine dello script:
Write-Progress -Activity "Working..." `
 -Completed -Status "All done."
In generale, al termine dello script l'indicatore di stato svanisce automaticamente ma, se lo script non è stato completato, è possibile nascondere l'indicatore di stato mediante il parametro -Completed che rimuove semplicemente l'indicatore dal display.

Tick, Tick, Tick
Write-Progress viene utilizzato comunemente anche per creare un display che visualizza i "secondi restanti", invece dell'effettivo indicatore di stato. Ecco un esempio:
for ($a=100; $a -gt 1; $a--) {
  Write-Progress -Activity "Working..." `
   -SecondsRemaining $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
Ho semplicemente modificato il ciclo affinché l'esecuzione avvenisse da 100 a 1 e ho utilizzato il parametro SecondsRemaining di Write-Progress, invece di PercentComplete. Il risultato è illustrato nella Figura 2. Come si può notare, il misuratore di stato è sparito, sostituito da un orologio per il conto alla rovescia. La Shell converte automaticamente il numero totale dei secondi in ore, minuti e secondi, offrendo informazioni più utili. La percentuale di completamento illustrata di seguito parte da 100, proprio per il parametro CurrentOperation fornito. In realtà non è stato completato alcun calcolo di percentuale; Windows PowerShell visualizza semplicemente il valore corrente di $a seguito dalla stringa "% complete".
Figura 2 Quanto tempo occorre perché lo script sia completo?
Figura 2 Quanto tempo occorre perché lo script sia completo?

Script che comunicano
Sono un grande fan della creazione di script che comunicano cosa sono in grado di fare. Tali script possono assumere la forma di un output dettagliato o semplicemente di un indicatore di stato. Possono essere utili per sopperire alle carenze di attenzione o per chiunque desideri eseguire sin d'ora il mio script del mese. Per concludere, è sicuramente un enorme vantaggio poter visualizzare qualsiasi tipo di informazione sullo stato e sull'avanzamento.

Don Jones collabora con TechNet Magazine come redattore ed è coautore del libro Windows PowerShell: TFM (SAPIEN Press, 2007). È docente di corsi su Windows PowerShell (www.ScriptingTraining.com) ed è possibile contattarlo sul sito Web ScriptingAnswers.com.


 Hey, Scripting Guy!: I giochi di Shell preferiti
Hey, Scripting Guy!
I giochi di Shell preferiti
Microsoft Scripting Guys
Scarica il codice per questo articolo: HeyScriptingGuy2008_03.exe (150KB)

Come dice il vecchio proverbio: anche il passero più piccolo non può cadere in terra all'insaputa del cielo. Ora, ciò che gli Scripting Guy suggeriscono non è che la gente va in giro a colpire i passeri che volano nel cielo. Anche se qualcuno volesse prendersi cura di quegli stupidi corvi che ogni sabato mattina alle 7:00 si siedono sul tetto e stridono, questa è tutta un'altra storia. [L'editor di script ama i corvi, dunque siamo sicuri che l'espressione "prendersi cura di" utilizzata dagli Scripting Guy in questo articolo significa "accertarsi che essi siano al sicuro". -Ed.] Tuttavia, è confortante sapere che c'è sempre qualcuno che si preoccupa di te, non importa quanto tu sia piccolo o insignificante, c'è sempre qualcuno che ti sorveglia. [Anche se quel qualcuno è solo un editor. -Ed.]
Ciò che è vero per i passerotti vale anche per gli script per l'amministrazione del sistema. Si può dedurre che, nel mondo degli script, l'attenzione viene focalizzata principalmente sul kahunas di script di grandi dimensioni: Windows PowerShellTM, VBScript, WMI, ADSI, persino FileSystemObject. È comprensibile che queste tecnologie siano fortemente pubblicizzate; dopo tutto consentono di fare molte cose veramente eccellenti e utili. Ciò non significa, però, che queste siano le sole tecnologie disponibili per gli autori di script. Lungi da noi affermare una cosa del genere.
Si pensi ad esempio all'oggetto Shell. Nonostante l'oggetto Shell potrebbe non essere altrettanto noto o ampiamente pubblicizzato quanto Windows PowerShell, è comunque importante e utile.
Molto probabilmente qualcuno, prima o poi, chiederà di scrivere uno script per l'amministrazione del sistema che utilizzi l'oggetto Shell. Ciò porta a una domanda ovvia: cosa si può fare esattamente con l'oggetto Shell? Ebbene, ci sono tante cose interessanti che è possibile fare con l'oggetto Shell, alcune delle quali (come la gestione delle quote disco e la visualizzazione di un indicatore di stato durante la copia o lo spostamento dei file) sono state trattate nella Guida sugli script di Microsoft® Windows® 2000, (microsoft.com/technet/scriptcenter/guide). Nell'articolo di questo mese, verranno illustrate altre piccole ingegnosità, cose che non si pensava affatto fosse possibile fare, tantomeno tramite l'oggetto Shell.

Modifica della data dell'ultima modifica di un file
Probabilmente molti di voi leggendo questo titolo stanno pensando: "Hey, aspetta un secondo. Non è possibile modificare la data dell'ultima modifica di un file utilizzando uno script, o perlomeno non utilizzando VBScript". A queste persone possiamo dire una sola cosa: hai mai sentito parlare di un'idea del genere?
Beh, in effetti, noi Scripting Guy abbiamo probabilmente affermato qualcosa del genere in passato, vero? Ebbene, ci sbagliavamo. Sconvolgente, vero? È possibile modificare la data dell'ultima modifica di un file utilizzando VBScript. Occorre semplicemente utilizzare l'oggetto Shell.
Nota: non preoccuparti di chiedere in che modo gli Scripting Guy abbiano potuto sbagliarsi; dopo tutti questi anni, dovrebbe essere piuttosto ovvio. Ecco una domanda molto più interessante: quando siamo riusciti a fare qualcosa di giusto?
Dunque, vuoi modificare la data dell'ultima modifica di un file, eh? Utilizza questo script:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")

objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
Come puoi vedere, non c'è nulla di così terribilmente complicato. Iniziamo creando un'istanza dell'oggetto Shell.Application. Attenti a non confondere Shell.Application con Wscript.Shell, l'oggetto Shell di Windows Script Host. L'oggetto Shell che utilizziamo oggi è l'oggetto Shell di Windows. Dopo aver attivato l'istanza dell'oggetto Shell, utilizziamo il metodo Namespace per creare un'associazione alla cartella C:\Scripts, quindi utilizziamo il metodo ParseName, dal nome bizzarro, per creare un'associazione a un file specifico all'interno di quella cartella. In questo caso, stiamo collegando un'immagine JPEG al nome file Dr_Scripto.jpg:
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")
Dopo aver creato un'associazione al file stesso, cosa facciamo? La risposta è semplice; assegniamo semplicemente una nuova data e una nuova ora alla proprietà ModifyDate:
objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
Ecco fatto.
L'operazione è riuscita. Molto interessante, vero? Una volta eseguito lo script, la data dell'ultima modifica del file verrà impostata su 01 gennaio 2008, ore 8:00. Per fare una verifica, è possibile aprire la cartella C:\Scripts di Windows Explorer.
Naturalmente, alcuni di voi staranno pensando, "Grande! Posso modificare la data dell'ultima modifica di un file. Ma per quale motivo al mondo dovrei voler modificare la data dell'ultima modifica di un file?" In molti casi gli utenti utilizzano la data dell'ultima modifica come una specie di sistema di controllo della versione; se, ad esempio, ci sono più copie di uno script in circolazione, un modo per tenere traccia della versione ufficiale è verificare la data dell'ultima modifica. Controllando la data dell'ultima modifica è possibile stabilire se una determinata copia di script è una versione modificata o meno dello script originale.
Nota: è vero che qualcuno può eseguire lo script appena illustrato e modificare la data dell'ultima modifica, ma oltre alla firma del codice, qualcuno potrebbe addirittura trovare un modo per colpire il sistema. Se i propri script sono condivisi con alcuni colleghi dotati di una certa etica, questo approccio risulta ragionevole.
A un certo punto potresti decidere di voler aggiornare e standardizzare la data dell'ultima modifica per tutti i tuoi script. Come puoi fare? Supponendo che tutti gli script si trovino nella cartella C:\Scripts, è possibile eseguire semplicemente il seguente frammento di codice:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set colItems = objFolder.Items

For Each objItem In colItems
    objItem.ModifyDate  = _
      "01/01/2008 8:00:00 AM"
Next
Come puoi notare, questo script inizia in un modo molto simile al primo script illustrato. Tuttavia, in questo caso, dopo aver creato un'associazione alla cartella C:\Scripts, non utilizziamo ParseName per creare un'associazione a un singolo file all'interno di quella stessa cartella. Utilizziamo, invece, questa riga di codice per restituire una raccolta di tutti i file trovati in quella cartella:
Set colItems = objFolder.Items
Una volta ottenuta la nostra raccolta, impostiamo un ciclo For Each per eseguire tutti gli elementi nella raccolta. All'interno del ciclo For Each, utilizziamo questa utile riga di codice per modificare il valore della proprietà ModifyDate del primo file nella raccolta con 01 gennaio 2008, 8:00:
objItem.ModifyDate  = _
  "01/01/2008 8:00:00 AM"
Il ciclo prosegue e il processo viene ripetuto con il file successivo della raccolta. Al termine di questo ciclo, tutti i file presenti nella cartella C:\Scripts (ad eccezione dei file nascosti) avranno la stessa data dell'ultima modifica. Visto quanto è facile? Chi ha detto che non è possibile modificare la data dell'ultima modifica di un file mediante VBScript?
Ok, lasciamo perdere.

A proposito di errori...
Tanto tempo fa, quando gli Scripting Guy hanno iniziato a utilizzare per la prima volta gli script per l'amministrazione dei sistemi, non era possibile accedere in alcun modo a tutte le informazioni sul file che venivano allegate a un file nel file system NTFS. Ad esempio, se fai clic con il pulsante destro del mouse su un file wav e poi su Proprietà, vengono visualizzate informazioni simili a quelle presenti nella Figura 1.
Figura 1 Riepilogo delle proprietà del file
Figura 1 Riepilogo delle proprietà del file
In che modo è possibile recuperare valori come Velocità in bit o Dimensioni campione audio mediante uno script? Non è possibile, a meno che non utilizzi l'oggetto Shell. Oppure Windows Desktop Search 3.0, dando per scontato che tale software sia stato scaricato e installato. La possibilità di recuperare tutte le informazioni sulla proprietà di un file è stata aggiunta all'oggetto Shell, ma gli Scripting Guy hanno trascurato questo aspetto. Di conseguenza, continuano a dire che non è possibile utilizzare uno script per stabilire la velocità in bit di un file wav, anche se, come dimostrato dal codice nella Figura 2, è di fatto possibile.
Figure 2 Utilizzare uno script per individuare la velocità in bit di un file wav (Close Figure 2)
Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = objFolder.ParseName("J0388563.wav")

For i = 0 to 33
    strHeader = objFolder.GetDetailsOf(objFolder.Items, i)
    strValue = objFolder.GetDetailsOf(objFolderItem, i)
    If strValue <> "" Then
        Wscript.Echo strHeader & vbTab & strValue
    End If
Next
Come funziona lo script? Anche questo script inizia allo stesso modo del primo, già illustrato in precedenza: si crea un'istanza dell'oggetto Shell.Application e un'associazione alla cartella C:\Scripts, successivamente si utilizza il metodo ParseName per creare un'associazione al file in questione (in questo caso, J0388563.wav).
A questo punto, le cose diventano un po' più complicate. Per iniziare, viene impostato un ciclo For Next che viene eseguito da 0 a 33 volte; ciò avviene perché i file supportano altrettante 31 proprietà estese differenti a cui sono stati associati numeri di indice da 0 a 33. (Tenere presente che ci sono alcuni numeri, come 27 e 28, che sono numeri di indice validi ma non contengono alcun valore della proprietà). Infatti, i file supportano le proprietà illustrate nella Figura 3.
Figure 3 Proprietà del file (Close Figure 3)

Indice | Proprietà
0 | Nome
1 | Dimensione
2 | Tipo
3 | Data di modifica
4 | Data di creazione
5 | Data di accesso
6 | Attributi
7 | Stato
8 | Proprietario
9 | Autore
10 | Titolo
11 | Oggetto
12 | Categoria
13 | Pagine
14 | Commenti
15 | Copyright
16 | Artista
17 | Titolo album
18 | Anno
19 | Numero del brano
20 | Genere
21 | Durata
22 | Velocità in bit
23 | Protetto
24 | Modello di macchina fotografica
25 | Data della foto
26 | Dimensioni
29 | Nome episodio
30 | Descrizione programma
32 | Dimensioni campione audio
33 | Frequenza campionamento audio
Che cosa viene eseguito all'interno del ciclo For Next? Per prima cosa viene eseguita la riga di codice riportata di seguito:
strHeader = _
  objFolder.GetDetailsOf(objFolder.Items, i)
Si tratta di utilizzare il metodo GetDetailsOf per richiamare il nome della proprietà 0 (non dimenticare che il ciclo viene eseguito da 0 a 33 volte). Tale nome viene poi memorizzato in una variabile definita strHeader e questa riga di codice viene utilizzata per recuperare il valore della proprietà dell'elemento 0, archiviando le informazioni restituite in una variabile definita strValue:
strValue = _
  objFolder.GetDetailsOf(objFolderItem, i)
Visto come funziona? L'elemento 0 è il nome della proprietà Name. Alla prima esecuzione del ciclo, strHeader conterrà lo stesso valore di Name. Nel frattempo, il nome reale (ossia, il valore della proprietà Name) per il primo file è J0388563.wav. Pertanto, alla prima esecuzione del ciclo, strValue conterrà lo stesso valore di J0388563.wav. Posto in questo modo, non sembra così complicato, vero?
Come forse si saprà, non tutti i tipi di file supportano tutte le proprietà estese. Ad esempio, un file jpg non disporrà di un valore tipo Titolo album o Frequenza campionamento audio. Pertanto, nella prossima riga di codice, si verifica se un valore restituito è una stringa vuota:
If strValue <> "" Then
Se il valore è una stringa vuota, occorre semplicemente tornare all'inizio del ciclo e ripetere il processo con la successiva proprietà estesa. Se il valore non è una stringa vuota, vengono restituiti il nome e il valore della proprietà, come illustrato di seguito:
Wscript.Echo strHeader & vbTab & strValue
Il risultato finale? Qualcosa molto simile a quanto segue:
Name    j0388563.wav
Size    169 KB
Type    Wave Sound
Date Modified   1/19/2004 8:56 AM
Date Created    3/6/2006 2:02 PM
Date Accessed   12/3/2007 10:41 AM
Attributes      A
Status  Online
Owner   FABRIKAM\kenmyer
Bit Rate        90kbps
Audio Sample Size       4 bit
Audio Sample Rate       11 kHz
Bene.
Il tempo e lo spazio a nostra disposizione per l'esecuzione è breve, ma se si è alla ricerca di un metodo ancora più semplice per restituire i valori delle proprietà più importanti, provare con lo script della Figura 4.
Figure 4 Un modo semplice per restituire i valori della proprietà (Close Figure 4)
Const colInfoTip = -1

Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("01. Out On The Weekend (Album Version).wma)")

Wscript.Echo objFolder.GetDetailsOf(objFolderItem, colInfoTip)
Cosa fa questo script? Se si utilizza Windows Explorer e con il puntatore del mouse ci si sofferma su un file, viene visualizzata una descrizione comando contenente informazioni utili sul file, come quelle illustrate nella Figura 5. Come è possibile ottenere tali informazioni della descrizione comando utilizzando uno script? Proprio così. Utilizzare lo script appena illustrato:
Figura 5 Proprietà illustrate in una descrizione comando
Figura 5 Proprietà illustrate in una descrizione comando
Artist: Neil Young
Album Title: Harvest
Year: 1972
Track Number: 1
Duration: 0:04:35
Type: Windows Media Audio file
Bit Rate: 256kbps
Protected: Yes
Size: 5.31 MB
Questo è tutto per questo mese. Ancora un ultimo appunto sui passerotti. Ecco un motivo valido per tenere traccia dei piccoli passeri: in alcune parti del mondo, c'è una credenza secondo la quale un passero che entra nella propria casa è indice di malaugurio. Perché? Significa che uno degli abitanti di quella casa sta per morire. In alcuni casi tale credenza è vera solo se il passero atterra su un pianoforte. Ma non si tratta di una superstizione, è più che altro qualcosa di misterioso. Ma ecco la parte davvero interessante: in altre parti del mondo, se un passero entra in casa significa che uno dei membri di quella famiglia si sposerà a breve. Come trovarsi tra l'incudine e il martello, vero?

Il rompicapo di script del Dottor Scripto.
La sfida mensile che verifica non solo le tue capacità di risoluzione degli enigmi, ma anche le tue competenze di scripting.

Marzo 2008: Script enigmatico
L'enigma di questo mese è un crittogramma, vale a dire che ogni lettera è stata sostituita da una lettera diversa. Tutti i simboli e i numeri sono stati lasciati intatti. La stessa lettera rappresenterà sempre una lettera sostituita. Ad esempio, tutte le occorrenze della lettera a potrebbero essere sostituite dalla lettera b, tutte le occorrenze della lettera b verrebbero sostituite dalla z e così via. Ecco un semplice esempio:
tdsjqu dfoufs
prova a decodificare quanto segue:
script center
La decodifica in questo caso è stata eseguita sostituendo ogni lettera dell'alfabeto con quella che la precede, così la t è stata sostituita dalla s, la d dalla c, e così via.
L'enigma non è proprio così lineare. Se si decodifica questo script si ottiene uno script che apre un'istanza di Microsoft Excel®, aggiunge un nuovo foglio di calcolo, assegna quattro valori alla prima colonna del foglio di calcolo e ordina tale colonna in modo crescente.
Buon divertimento.

L'enigma
kqyjs edfjkzyrlyg = 1
kqyjs edyq = 2
kqyjs edjqtstqmj = 2

jzs quwzekzd = ktzfszquwzks("zekzd.faadlkfslqy")
quwzekzd.iljludz = stcz

jzs quwmqtxuqqx = quwzekzd.mqtxuqqxj.frr
jzs quwmqtxjozzs = quwmqtxuqqx.mqtxjozzsj(1)

quwmqtxjozzs.kzddj(1, 1) = "kfs"
quwmqtxjozzs.kzddj(1, 2) = "rqg"
quwmqtxjozzs.kzddj(1, 3) = "ufs"
quwmqtxjozzs.kzddj(1, 4) = "faz"

jzs quwtfygz = quwzekzd.fkslizkzdd.zysltztqm
quwtfygz.jqts quwtfygz, edfjkzyrlyg, , , , , , edyq, , , edjqtstqmj

Il rompicapo di script del Dottor Scripto.
Risposta: Script enigmatico, marzo 2008
Ecco la chiave per decodificare lo script:
Actual Letter	a	b	c	d	e	f	g	h	i	j	k
Coded Letter	f	u	k	r	z	b	g	o	l	w	x

Actual Letter	l	m	n	o	p	q	r	s	t	u	v	w	x	y	z
Coded Letter	d	n	y	q	a	h	t	j	s	c	i	m	e	v	p
Mentre questo è lo script effettivamente decodificato:
Const xlAscending = 1
Const xlNo = 2
Const xlSortRows = 2

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True

Set objWorkbook = objExcel.Workbooks.Add
Set objWorksheet = objWorkbook.Worksheets(1)

objWorksheet.Cells(1, 1) = "Cat"
objWorksheet.Cells(1, 2) = "Dog"
objWorksheet.Cells(1, 3) = "Bat"
objWorksheet.Cells(1, 4) = "Ape"

Set objRange = objExcel.ActiveCell.EntireRow
objRange.Sort objRange, xlAscending, , , , , , xlNo, , , xlSortRows

Microsoft Scripting GuysGli Scripting Guy lavorano per Microsoft, o meglio... sono dipendenti Microsoft. Quando non si dedicano al baseball (o a varie altre attività) da giocatori, allenatori o semplici spettatori, gestiscono il TechNet Script Center. Consultare la pagina www.scriptingguys.com.


 Controllo della protezione: Utilizzo di Configurazione guidata impostazioni di sicurezza in Windows Server 2008
Controllo della protezione
Utilizzo di Configurazione guidata impostazioni di sicurezza in Windows Server 2008
Jesper M. Johansson
Questo articolo è basato su una versione non definitiva di Windows Server 2008. Tutte le informazioni riportate sono soggette a modifica.

Nel 2005 Microsoft ha rilasciato Windows Server 2003 SP1. Con il Service Pack è stato introdotto il primo strumento di gestione della protezione basato sui ruoli per Windows: Configurazione guidata impostazioni di sicurezza. Microsoft ha progettato Configurazione guidata impostazioni di sicurezza anzitutto e soprattutto come strumento di riduzione della superficie di attacco. Lo scopo dello strumento consisteva nell'analizzare le operazioni eseguite
con il computer e configurare automaticamente il supporto dei ruoli necessari, disattivando invece i ruoli e i servizi non utilizzati.
In Windows Server® 2008 Configurazione guidata impostazioni di sicurezza è stato confermato e aggiornato con nuovi ruoli e con l'integrazione con il nuovo Windows® Firewall. Tuttavia, resta lo strumento di amministrazione avanzato che è sempre stato.
In Windows Server 2008 sono disponibili anche uno strumento simile, Server Manager, basato sui ruoli e le procedure guidate per l'aggiunta di ruoli e funzionalità. In Windows Server 2008 invece di aggiungere i singoli componenti tramite Installazione componenti di Windows nel Pannello di controllo, ora è possibile utilizzare gli strumenti di gestione dei ruoli per configurare il server. Byron Hynes descrive questi strumenti nell'articolo "Configurazione dei ruoli con Server Manager" in questo numero di TechNet Magazine.
Le procedure guidate per l'aggiunta di ruoli e funzionalità sono state progettate per configurare il server con i componenti corretti per supportare i ruoli scelti. Con le procedure guidate si configura anche il firewall incorporato in modo che i ruoli funzionino in modo corretto. Detto questo, viene da chiedersi a cosa serva ancora Configurazione guidata impostazioni di sicurezza. Di certo molti amministratori non utilizzeranno più Configurazione guidata impostazioni di sicurezza. Tuttavia, esistono due gruppi di persone per cui Configurazione guidata impostazioni di sicurezza resta uno strumento di inestimabile utilità. Il primo è il gruppo dei paranoici della protezione. Si tratta di persone che apprezzano molto il modo in cui Configurazione guidata impostazioni di sicurezza affronta il problema della protezione.
È possibile immaginare le procedure guidate di aggiunta di ruoli e funzionalità come a strumenti che acquisiscono un server predefinito e lo configurano in modo da supportare i ruoli e le funzioni desiderate per la protezione. Configurazione guidata impostazioni di sicurezza, d'altra parte, è lo strumento che configura il server in modo che supporti solo i ruoli e le funzionalità desiderate. Inoltre Configurazione guidata impostazioni di sicurezza ha un effetto pedagogico, poiché aiuta a comprendere meglio le modalità di configurazione dei server. È dunque consigliabile eseguire Configurazione guidata impostazioni di sicurezza dopo che il server è stato configurato con il necessario complemento di ruoli e funzionalità.
Il secondo gruppo di persone è costituito dagli utenti che desiderano comprendere le relazioni tra i vari componenti. Configurazione guidata impostazioni di sicurezza è dotato di una serie di file XML che documentano le relazioni tra ruoli e funzionalità, servizi e porte della rete. Chi è interessato a comprendere cosa è necessario per i vari componenti, considera Configurazione guidata impostazioni di sicurezza uno strumento molto valido.
Nell'articolo si descriverà il funzionamento di Configurazione guidata impostazioni di sicurezza e gli utilizzi possibili per la protezione del server. Verrà inoltre proposto un confronto tra Configurazione guidata impostazioni di sicurezza e gli strumenti di Server Manager. L'articolo è tratto dal mio libro Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008).

Panoramica su Configurazione guidata impostazioni di sicurezza
Per iniziare, è utile presentare alcune statistiche sulla superficie di attacco in Windows Server 2008. Prima che si configuri un server, aggiungendo la propria selezione personale di ruoli e funzionalità, il sistema operativo presenta ancora una superficie abbastanza significativa. Per impostazione predefinita, in Windows Server 2008 vengono utilizzati 105 servizi, 42 dei quali sono impostati in modo da essere avviati automaticamente, 55 sono manuali e 8 sono disattivati. È possibile confrontare questi numeri con un'installazione pulita di Windows Server 2003 R2 SP2, che prevede 86 servizi installati per impostazione predefinita, 34 dei quali vengono avviati automaticamente, 32 richiedono un avvio manuale e 20 sono disattivati.
Anche con il supporto di metafora dei ruoli e riduzione nei ruoli predefiniti, Windows Server 2008 presenta ancora una superficie maggiore e richiede ulteriore attenzione nella progettazione della protezione avanzata dei server. Configurazione guidata impostazioni di sicurezza consente di creare una configurazione di protezione personalizzata per i propri server.
L'approccio adottato da Configurazione guidata impostazioni di sicurezza per la protezione avanzata dei server è completamente diverso rispetto agli strumenti esistenti. Viene utilizzata la metafora dei ruoli per configurare il sistema in modo che supporti i ruoli desiderati e poco, o nulla, altro. Come le procedure guidate per l'aggiunta di ruoli e funzionalità, Configurazione guidata impostazioni di sicurezza aiuta a configurare il firewall, ma inoltre consente di disattivare i servizi inutili e configurare alcune impostazioni di protezione aggiuntive. Infine, mentre con le procedure guidate per l'aggiunta di ruoli e funzionalità si possono installare e configurare solo i ruoli incorporati in Windows, Configurazione guidata impostazioni di sicurezza è estendibile. Uno sviluppatore o un amministratore può scrivere un ruolo o un file di configurazione della funzionalità personalizzato e utilizzare Configurazione guidata impostazioni di sicurezza per configurare qualsiasi prodotto.
Configurazione guidata impostazioni di sicurezza è stata progettata per un utilizzo successivo all'installazione di tutti i ruoli e le funzionalità che il server deve contenere. Se sul server sono presenti anche applicazioni di terze parti, è necessario installare anche queste prima di eseguire Configurazione guidata impostazioni di sicurezza.
Per dimostrarne il funzionamento, è stato configurato un server con tre ruoli (Server applicazioni, Server DNS e Server Web) e due funzionalità (Funzionalità di Microsoft® .NET Framework 3.0 e Servizio Attivazione processo Windows). Non è una serie particolarmente logica di ruoli e funzionalità, ma costituisce un buon esempio per l'argomento dell'articolo.
Per eseguire la Configurazione guidata impostazioni di sicurezza, avviarla dal menu Strumenti di amministrazione. Verrà visualizzata la finestra di dialogo riportata nella Figura 1.
Figura 1 Configurazione guidata impostazioni di sicurezza chiede che operazione si desidera eseguire
Figura 1 Configurazione guidata impostazioni di sicurezza chiede che operazione si desidera eseguire
La prima azione da eseguire è scegliere se si desidera creare un nuovo criterio di protezione, modificare o applicare un criterio esistente oppure eseguire il rollback di un criterio in modo da riconfigurare il sistema in base alle impostazioni originali. Le scelte disponibili si spiegano da sole.
Quando si sceglie di creare un nuovo criterio di protezione, Configurazione guidata impostazioni di sicurezza crea un nuovo criterio utilizzando un computer come modello per ciò che il criterio deve supportare. Il computer viene analizzato e vengono individuati i ruoli e le funzionalità che supporta, garantendo il funzionamento di questi ma anche la disattivazione di molte funzionalità inutili.
Configurazione guidata impostazioni di sicurezza funziona in base a un modello di prototipo. Utilizza dei file XML per specificare l'aspetto di ruoli e funzionalità, in termini di quali file vengono installati, quali servizi vengono configurati e così via. È per questo motivo che è necessario avere già installato tutto sul computer a fronte del quale si intende sviluppare i criteri. Se si utilizzano dei programmi di terze parti che durante la procedura di installazione installano delle definizioni di Configurazione guidata impostazioni di sicurezza, questi verranno integrati senza problemi. Tuttavia, se i programmi di terze parti non installano le definizioni di Configurazione guidata impostazioni di sicurezza, sarà necessario configurarli manualmente.
Come si può vedere, è possibile creare un criterio su un sistema e applicarlo quindi a molti altri sistemi. Quando si crea una rete con molti sistemi, è necessario definire prima le classi host che vengono tutte configurate separatamente. Dopo sarà possibile creare un criterio utilizzando un sistema come prototipo e applicare facilmente il criterio a tutti gli altri sistemi con nessuna o poche modifiche.
Quando si sceglie Avanti (nella finestra di dialogo nella Figura 1), la procedura guidata chiede quale computer si intende utilizzare come base o prototipo per il nuovo criterio. In genere come prototipo si sceglie il computer locale, ma è possibile anche utilizzare un computer remoto.
Dopo aver specificato il sistema da utilizzare, si passa alla fase di analisi. Configurazione guidata impostazioni di sicurezza raccoglie informazioni sui ruoli e le funzionalità installati, che confronta quindi con il database dei ruoli e delle funzionalità. Il database contiene informazioni relative ai servizi utilizzati da ciascun ruolo e funzionalità, alle porte di rete necessarie e altre importanti informazioni di configurazione. Al termine dell'analisi, è possibile scegliere Visualizza il database di configurazione per visualizzare i risultati trovati da Configurazione guidata impostazioni di sicurezza. Si tratta di una visualizzazione di sola lettura con le informazioni complete sulla configurazione del computer. In effetti, chi è davvero interessato a comprendere le funzionalità di un computer, potrebbe trascorrere alcune ore studiando queste informazioni.

Configurazione del server con Configurazione guidata impostazioni di sicurezza
Quando si fa clic su Avanti, si passa alla prima delle quattro sezioni di Configurazione guidata impostazioni di sicurezza: Configurazione dei servizi in base ai ruoli. I ruoli che si trovano in Configurazione guidata impostazioni di sicurezza, come illustrato nella Figura 2, non sono gli stessi che si trovano in Aggiunta guidata ruoli. La maggior parte dei ruoli disponibili in Aggiunta guidata ruoli sono anche presenti qui e Configurazione guidata impostazioni di sicurezza ne offre altri che non sono contenuti in Aggiunta guidata ruoli. Ad esempio, il ruolo Server applicazioni scelto non è presente, perché Configurazione guidata impostazioni di sicurezza utilizza una metafora leggermente diversa per i ruoli. Questo aspetto verrà esaminato in dettaglio tra breve.
Figura 2 Utilizzo di Configurazione guidata impostazioni di sicurezza per scegliere i ruoli che il server deve supportare
Figura 2 Utilizzo di Configurazione guidata impostazioni di sicurezza per scegliere i ruoli che il server deve supportare
Nella finestra di dialogo spesso sarà disponibile l'insieme di ruoli corretto già selezionato. Quindi è sufficiente verificare che l'analisi abbia trovato quanto previsto. In caso di problemi, verificare se il ruolo è stato installato e, se manca, installarlo prima di rieseguire Configurazione guidata impostazioni di sicurezza. Se si fa un errore, non è il caso di allarmarsi. La funzionalità di rollback di Configurazione guidata impostazioni di sicurezza consente di ripristinare la situazione iniziale, annullando tutte le modifiche apportate ai criteri.
Le risposte che si forniscono in questa sezione sono molto importanti, perché determinano le opzioni che vengono visualizzate in seguito nella sezione della rete. Per fortuna, la logica di rilevamento è abbastanza efficace e in genere viene selezionata l'insieme di ruoli corretto.
Per impostazione predefinita, inoltre, vengono visualizzati i ruoli installati, ovvero i ruoli che il server è in grado di supportare in base ai bit archiviati sul disco. I ruoli selezionati sono quelli supportati al momento. È possibile anche decidere di visualizzare tutti i ruoli del database. A tal fine, scegliere Tutti i ruoli dall'elenco a discesa. La visualizzazione di tutti i ruoli è utile soprattutto quando si deve creare un criterio utilizzando un server di prototipo su cui non sono ancora stati installati tutti i ruoli necessari.
Dopo la configurazione dei ruoli, si selezionano le funzionalità client da supportare. L'insieme di funzionalità è simile, ma non identico, a quello di Aggiunta guidata funzionalità e nell'insieme sono presenti meno funzionalità. Anche in questo caso, le metafore non sono identiche e la Configurazione guidata impostazioni di sicurezza può essere estesa, quindi ciò che viene visualizzato è diverso rispetto ad Aggiunta guidata funzionalità.
Quando si fa clic su Avanti nella pagina Funzionalità client della Configurazione guidata impostazioni di sicurezza, si passa alla finestra di dialogo Seleziona opzioni di amministrazione e altre opzioni, come illustrato nella Figura 3. Un'opzione in Configurazione guidata impostazioni di sicurezza è qualcosa di leggermente diverso da un ruolo o una funzionalità. Può fornire supporto amministrativo o essere un singolo servizio, come Rilevamento servizi interattivi. Anche in questo caso, la maggior parte delle opzioni necessarie dovrebbero essere selezionate qui. È inoltre utile esaminare il menu a discesa, che contiene le opzioni pertinenti ai ruoli e alle funzionalità selezionate in precedenza e risulta diverso per ciascun computer.
Figura 3 Selezione di altri servizi e funzionalità in Configurazione guidata impostazioni di sicurezza
Figura 3 Selezione di altri servizi e funzionalità in Configurazione guidata impostazioni di sicurezza
Si passa quindi alla finestra di dialogo Seleziona servizi aggiuntivi. Sebbene Configurazione guidata impostazioni di sicurezza sia dotato di un database di servizi molto esteso, non vi sono descritti tutti i servizi. I servizi che Configurazione guidata impostazioni di sicurezza trova su un computer e che non sono presenti nel database vengono visualizzati nella pagina Servizi aggiuntivi. In genere vengono descritti tutti i servizi incorporati e questa finestra di dialogo non viene visualizzata, a meno di non aver installato dei servizi di terze parti.
La procedura guidata consente di scegliere l'operazione da eseguire con i servizi che non si configurano. Questa opzione si rivela utile quando si intende applicare il criterio creato a un altro computer. Se tale computer utilizza servizi diversi da quelli in base ai quali è stato creato il criterio, Configurazione guidata impostazioni di sicurezza deve acquisire informazioni su come gestirli. Una possibile opzione è non eseguire alcuna operazione, che è l'impostazione predefinita. Un'altra opzione consiste nel disattivarli, che è una strada più sicura ma si rischia di influire sul corretto funzionamento del sistema. Se però si segue il consiglio di applicare i criteri solo ai server identici a quello su cui sono stati creati, la scelta in questa pagina diventa irrilevante.
La parte relativa alla configurazione dei ruoli di Configurazione guidata impostazioni di sicurezza è terminata e nella procedura guidata viene visualizzato un riepilogo delle scelte operate. Come è possibile notare nella Figura 4, anche limitandosi ad accettare tutte le impostazioni predefinite, si riduce in modo considerevole la superficie di attacco del computer. Poiché il computer non è un Server di stampa, ad esempio, e non è stata installata alcuna stampante, non è necessario eseguire il servizio di Spooler di stampa. Configurazione guidata impostazioni di sicurezza disattiva tutti i servizi non necessari. Sul server di test, Configurazione guidata impostazioni di sicurezza disattiva 17 servizi impostati come ad avvio automatico e disattiva 42 servizi ad avvio manuale. I risultati, ovviamente, variano in base alla configurazione del server, ma è facile rilevare come Configurazione guidata impostazioni di sicurezza consenta di creare criteri personalizzati specifici per i propri server, riducendone drasticamente la superficie di attacco.
Figura 4 Configurazione guidata impostazioni di sicurezza riepiloga le modifiche apportate
Figura 4 Configurazione guidata impostazioni di sicurezza riepiloga le modifiche apportate
Si passa ora alla sezione probabilmente più importante di Configurazione guidata impostazioni di sicurezza: la rete: Dopo la pagina di benvenuto iniziale, viene visualizzata la finestra di dialogo Regole di protezione di rete, illustrata nella Figura 5. Questa contiene un elenco di tutte le regole firewall proposte da Configurazione guidata impostazioni di sicurezza, che sono basate sul supporto dei ruoli scelti nelle sezioni precedenti.
Figura 5 L'elenco di tutte le regole necessarie secondo Configurazione guidata impostazioni di sicurezza
Figura 5 L'elenco di tutte le regole necessarie secondo Configurazione guidata impostazioni di sicurezza
Se non si eseguono altre configurazioni nella sezione Rete, Configurazione guidata impostazioni di sicurezza creerà le regole firewall che bloccano le interfacce di rete in modo che siano supportati solo i ruoli e le funzionalità impostati, ma che tutti i client possano accedervi. Ma per ottimizzare davvero la protezione dei server, è necessario utilizzare Configurazione guidata impostazioni di sicurezza come parte integrante nella definizione di una strategia di isolamento del server. Per ulteriori informazioni sull'isolamento del server (e sull'isolamento del dominio), consultare technet.microsoft.com/network/bb545651.
Nel Resource Kit della protezione di Windows Server 2008 è presente un capitolo relativo alla protezione della rete con l'isolamento di server e dominio. Viene inoltre illustrato l'utilizzo dei modelli di rischio della rete per analizzare la rete e facilitare la distribuzione dell'isolamento del server. Configurazione guidata impostazioni di sicurezza è uno strumento molto utile in questo processo.
È possibile configurare delle restrizioni sulle regole proposte, selezionando la regola e scegliendo Modifica. Verrà visualizzata la finestra di dialogo riportata nella Figura 6. Questa è la prima delle quattro pagine che consentono di imporre ulteriori restrizioni sulle regole della connessione in rete. È possibile, ad esempio, richiedere l'autenticazione IPsec. In tal caso è possibile legare la porta esclusivamente a determinati endpoint. È possibile configurarla, ad esempio, in modo da consentire l'amministrazione remota solo da determinati host. Come si può comprendere, questo è un vantaggio chiave rispetto alle procedure guidate di aggiunta di ruoli e funzionalità.
Figura 6 Configurazione guidata impostazioni di sicurezza consente di creare regole per firewall e IPSEC
Figura 6 Configurazione guidata impostazioni di sicurezza consente di creare regole per firewall e IPSEC
La potenzialità di creare regole di protezione della connessione in base ai ruoli selezionati assolve a due scopi importanti. Rappresenta prima di tutto un'eccellente opportunità di apprendimento, per comprendere a fondo il funzionamento dei server. Non è nemmeno necessario creare un server, ma è sufficiente eseguire la procedura guidata, selezionare gli elementi desiderati e vedere in che modo di influisce sulle opzioni delle pagine successive. Consente inoltre di legare il concetto molto astratto di una porta a un altro concetto, molto più logico, di un servizio e di configurare le restrizioni della rete in base alle azioni effettivamente eseguite dal sistema.
Se ben sfruttata, questa possibilità consente di sviluppare configurazioni molto rigorose per i server. La sezione dedicata alla rete di Configurazione guidata impostazioni di sicurezza è indubbiamente l'area a cui dedicare più tempo durante la creazione dei criteri di protezione per i server.
Il resto di Configurazione guidata impostazioni di sicurezza consente di configurare il controllo e alcune impostazioni del Registro di sistema. Le impostazioni predefinite di questi parametri sono adeguate per la maggior parte delle organizzazioni e, a meno di non avere requisiti speciali, non è necessario apportare molte modifiche.
Dopo aver creato il proprio criterio, è possibile salvarlo e applicarlo al computer che si sta utilizzando o ad altri computer. È possibile trasformare il criterio in un oggetto Criteri di gruppo (GPO) utilizzando il comando scwcmd.exe /transform.
Tuttavia, se nel criterio sono configurate impostazioni specifiche per i computer, l'operazione potrebbe non avere esito positivo o produrre risultati imprevisti. Se, ad esempio, si creano restrizioni dell'endpoint che comprendono delle schede locali nella sezione dedicata alla rete, il criterio viene ritenuto specifico del computer e non viene trasformato con successo. Questo comportamento dipende dal fatto che tali schede devono essere specificate utilizzando i GUID. Il GUID per una scheda di un computer non ha alcun significato in un altro computer.
Ne consegue che Configurazione guidata impostazioni di sicurezza si rivela particolarmente utile in scenari server per server e come strumento di formazione. Per le grandi server farm, è possibile utilizzare Configurazione guidata impostazioni di sicurezza come metodo di apprendimento e di sviluppo dei criteri di base. È quindi possibile implementare il criterio utilizzando qualsiasi strumento si preferisca per configurare i server, come Criteri di gruppo o un sistema di gestione aziendale (come Microsoft Systems Center).

Configurazione guidata impostazioni di sicurezza e Server Manager a confronto
Un aspetto già chiarito fino ad ora è che le metafore utilizzate per ruoli e funzionalità differiscono. Una "funzionalità" in Configurazione guidata impostazioni di sicurezza è un'operazione che il computer esegue per agire come un client. Un "ruolo" è invece un'operazione che il computer esegue per agire come un server.
La metafora utilizzata negli strumenti di Server Manager è diversa, poiché in questo caso un ruolo è una raccolta di servizi e funzionalità che può essere immaginata come un'unità e una funzionalità è un elemento che supporta dei ruoli. In pratica per Server Manager il ruolo corrisponde al motivo per cui si è acquistato il server. Le funzionalità sono importanti, ma non sono lo scopo a cui è destinato il server. Le due metafore e i due diversi utilizzi degli stessi termini sono destinati a generare qualche confusione. Prima di passare da uno strumento all'altro, questo aspetto deve essere assolutamente chiaro.
Inoltre, gli strumenti di Server Manager non sono estendibili, ma sono progettati in modo da gestire solo i componenti di cui è dotato Windows. Al contrario, i programmi di terze parti che si installano possono aggiungere ruoli e funzionalità a Configurazione guidata impostazioni di sicurezza. È addirittura possibile scrivere ruoli e funzionalità personalizzate. Nel white paper "Estensione di Configurazione guidata impostazioni di sicurezza" (disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=107397) si illustra come eseguire queste operazioni.
Configurazione guidata impostazioni di sicurezza disattiva i componenti non necessari. Gli strumenti di Server Manager, invece, si limitano a distribuire i componenti richiesti, senza apportare altre modifiche al computer. Se si ritiene di aver bisogno di un aiuto per determinare quali sono i componenti non necessari, Configurazione guidata impostazioni di sicurezza è lo strumento da utilizzare.
Inoltre, sia gli strumenti di Server Manager che Configurazione guidata impostazioni di sicurezza consentono di configurare la rete, ma Configurazione guidata impostazioni di sicurezza è molto più potente. Se si intende adottare una strategia di isolamento del server, Configurazione guidata impostazioni di sicurezza può diventare una miniera d'oro di informazioni e il migliore ausilio per la distribuzione. Questo è senza dubbio un argomento di amministrazione della protezione avanzata, ma Configurazione guidata impostazioni di sicurezza è uno strumento di protezione avanzato.
Infine, Configurazione guidata impostazioni di sicurezza consente di configurare anche alcune altre impostazioni di protezione che gli strumenti di Server Manager non sono in grado di configurare. Tuttavia, questa potenzialità è ampiamente controbilanciata dai controlli più efficaci (o già definiti per impostazione predefinita) in Windows Server 2008.

Jesper M. Johansson, Principal Security Engineer, si occupa dei problemi di protezione software e collabora con TechNet Magazine in qualità di redattore. Ha conseguito il titolo di PhD in MIS e ha oltre 20 anni di esperienza nel settore della protezione.


 Desktop file: Non si &#232; mai troppo ricchi o troppo magri
Desktop file
Non si è mai troppo ricchi o troppo magri
Wes Miller

Chi ha visitato un campus Microsoft, ha visto probabilmente sistemi installati in chioschi multimediali a utilizzo condiviso nelle aree di accoglienza della maggior parte degli edifici. Questi sistemi sono stati creati con un front-end basato su Web collegato a Servizi terminal di Windows affinché i collaboratori di passaggio da un edificio all'altro potessero consultare la posta elettronica e disporre della
connettività. In origine, furono realizzati utilizzando i PC più vecchi, fuori servizio e riciclati. L'hardware troppo lento, la scarsa capacità della memoria e i dischi rigidi non adeguati per altri scopi erano invece perfetti per le applicazioni thin client. Se per qualsiasi motivo si dispone di hardware obsoleto, è possibile riutilizzarlo come workstation nelle sale riunioni, come computer per la formazione e altro ancora. Invece di aggiungere altra spazzatura alle discariche, è possibile scegliere un approccio più rispettoso dell'ambiente e sfruttare al massimo l'investimento.
Se nell'organizzazione si pensa a un aggiornamento a Windows Vista®, si potrebbe scoprire di possedere hardware più vecchio del previsto. In questo caso, potrebbe non essere fornito supporto per i servizi Trusted Platform Module (TPM) o Aero®. Tuttavia, se tutto quello di cui necessitano i sistemi è un disco rigido più potente o una quantità maggiore di RAM, è il caso di aggiornare l'hardware. Alcuni sistemi, invece, potrebbero semplicemente non essere in grado di eseguire Windows Vista perché la potenza dell'hardware è troppo ridotta o perché mancano alcune funzionalità principali. Questo è il tipo di hardware ideale da utilizzare come thin client Windows®. Nella Figura 1 vengono elencati i requisiti hardware per Windows Vista che consentono di sapere a quale categoria appartiene l'hardware in uso.
Figure 1 Requisiti hardware di Windows Vista (Close Figure 1)

Requisiti | hardware
CPU | Almeno 1 GHz consigliato. La velocità della CPU può determinare l'utilizzabilità di Windows Vista. Una singola CPU principale lenta non basta, ma può diventare un buon thin client. Se si sta valutando di passare a un sistema x64, prima di intraprendere qualsiasi passo è opportuno aggiornare tutto l'hardware a Windows Vista.
Memoria | Almeno 1 GB consigliato. Generalmente è possibile aggiungere memoria a un sistema. Tuttavia, è necessario valutare la convenienza economica dell'installazione di memoria aggiuntiva su decine, centinaia o migliaia di sistemi.
GPU | Almeno 128 MB di memoria grafica, compatibile con DirectX® 9.0 con un driver WDDM e il supporto Pixel Shader 2.0. Questo requisito non dovrebbe avere particolari conseguenze poiché riduce solo il supporto per Aero.
HDD | Almeno 40 GB di spazio sul disco rigido. Problemi legati a questo requisito possono presentarsi in particolare per i sistemi portatili piuttosto che desktop.
Problemi legati ai driver | I driver di Windows Vista sono disponibili per tutto l'hardware che si trova nei sistemi?
TPM | Per ottenere supporto per BitLocker che non richieda un'unità di memoria flash USB, è necessario disporre di hardware TPM 1.2.

Quindi, cosa è possibile fare con un thin client?
Utilizzando l'hardware obsoleto e i sistemi operativi più piccoli, è possibile creare chioschi multimediali di ricezione in aree comuni che consentano agli utenti di controllare la posta elettronica, come fanno negli uffici Microsoft. È possibile realizzare sistemi con desktop remoto o un'istanza ben gestita di Internet Explorer®. È possibile installare sistemi di riproduzione di presentazioni nelle sale riunioni con Microsoft PowerPoint®, desktop remoto e poco altro. È anche possibile utilizzare combinazioni di hardware obsoleto/thin client per sistemi nei punti vendita o in chioschi multimediali di collocamento. Quale thin client deve essere utilizzato?

Windows XP Embedded
Negli articoli precedenti, è stato illustrato lo sviluppo di Windows XP Embedded come versione flessibile e strutturata in componenti di Windows XP. Come riportato nell'articolo redatto da Don Jones dell'aprile 2007 (vedere technetmagazine.com/issues/2007/04/XPe), esistono diversi strumenti utilizzati per creare le immagini di Windows XP Embedded. Lo strumento principale è Target Designer (vedere la Figura 2). Target Designer consente di creare la propria immagine personalizzata di Windows XP Embedded.
Figura 2 Immagine di Windows XP Embedded con Target Designer
Figura 2 Immagine di Windows XP Embedded con Target Designer
Target Designer viene fornito con diversi modelli di progettazione che supportano l'utente nella fase iniziale di utilizzo. Naturalmente è possibile utilizzarlo autonomamente, ma un modello semplifica notevolmente l'operazione. Nella Figura 2 vengono mostrate due soluzioni valide per iniziare: il componente Kiosk/Gaming Console e i modelli Terminal basati su Windows. Windows XP Embedded fornisce anche pieno supporto dei dispositivi e funzionalità native di risparmio energetico, esattamente come nell'immagine del sistema operativo completo (è sufficiente creare il supporto per questi elementi nell'immagine). Naturalmente, più funzionalità vengono aggiunte, più hardware sarà necessario; per questo motivo è importante scegliere con consapevolezza. È possibile trovare maggiori informazioni su Windows XP Embedded sul sito Web Microsoft: microsoft.com/windows/embedded/eval/xpe/default.mspx.

Windows Embedded for Point of Service
Windows Embedded for Point of Service (WEPOS) fornisce un modello completamente standardizzato per i sistemi point-of-service (POS) basato su Windows XP Embedded. WEPOS fornisce supporto incorporato per numerose periferiche correlate a POS ed è particolarmente adatto nei punti di vendita al dettaglio e nei luoghi aperti al pubblico. A differenza di Windows XP Embedded, fornisce una serie di funzionalità prestabilite, progettate appositamente per questo ruolo che non possono essere personalizzate come accade in Windows XP Embedded.
La piattaforma WEPOS è progettata per un sistema ridotto al minimo, che richiede solo un processore Pentium II a 233 MHz o superiore, 64 MB di RAM e solo 280 MB per l'immagine del sistema operativo principale. È possibile trovare informazioni dettagliate su WEPOS e collegamenti per ordinare una versione di valutazione all'indirizzo microsoft.com/windows/embedded/wepos.

Windows Fundamentals for Legacy PCs
A differenza di Windows XP Embedded e WEPOS, progettati per essere incorporati nei dispositivi direttamente dal produttore, Windows Fundamentals for Legacy PCs (FLP) viene fornito con licenza come componente di Software Assurance ed è destinato principalmente a questo specifico scenario. Nella Figura 3 viene mostrata la schermata di installazione di Windows FLP, che offre quattro opzioni di configurazione agli utenti: Minima, Tipica, Completa, Personalizzata.
Figura 3 Installazione di Windows FLP
Figura 3 Installazione di Windows FLP
Windows FLP richiede 64 MB di RAM, almeno 500 MB di spazio su disco rigido e una risoluzione del monitor di almeno 800x600. Gli attuali requisiti di sistema relativi allo spazio sul disco rigido possono cambiare in base ai componenti del sistema operativo che si decide di installare.
Se si desidera un sistema operativo minimo e relativamente flessibile da utilizzare su hardware legacy e si dispone di Software Assurance, Windows FLP è una buona scelta. Visitare l'indirizzo microsoft.com/licensing/sa/benefits/fundamentals.mspx per ulteriori informazioni sul modo in cui Windows FLP consente una facile migrazione all'hardware e al sistema operativo più recenti.

Versione semplificata di Windows XP
Oltre a queste versioni più ridotte, è possibile utilizzare anche Windows XP. Se non si dispone di molta RAM, la disattivazione di servizi come Temi di Windows e altri consente di ridurre il sovraccarico affinché il sistema funzioni in modo adeguato. Accertarsi, comunque, di sapere cosa si sta disattivando in modo da non compromettere la protezione (disattivando Windows Firewall, ad esempio).

Opzioni sicuramente non efficaci
Sfortunatamente, gli utenti spesso tentano di utilizzare una serie di altre opzioni Windows per alleggerire i sistemi. Di seguito vengono riportate le scelte più ovvie e le specifiche che spiegano perché queste opzioni non funzionano come dovrebbero.
Windows XP Starter Edition può essere utilizzato in sistemi con restrizioni, ma è stato originariamente progettato per i mercati di tecnologie di sviluppo. In questi mercati, viene fornito da un OEM insieme ai nuovi PC come copia di Windows concessa in licenza. Di conseguenza, è un'opzione che andrebbe evitata. Per ulteriori informazioni, andare al seguente indirizzo: microsoft.com/presspass/newsroom/winxp/WinXPStarterFS.mspx.
Un discorso analogo può essere fatto riguardo a Windows PE. È interessante notare che, durante la fase di sviluppo, Microsoft aveva pensato di fornire Windows PE come sistema operativo leggero. Tuttavia, alla fine si è scelto di progettarlo come ambiente minimo di preinstallazione mirato alla distribuzione. Ad esempio, Windows PE non dispone di altre shell oltre al prompt dei comandi (e non è semplice aggiungerne una che risulti funzionale), né di serie di API definite, di funzionalità di risparmio energetico o di supporto audio.
Nemmeno una versione ridotta di Windows XP è una buona soluzione. Qualcuno sostiene che una soluzione realizzabile sia "sfoltire" Windows. Con questo non si intende solo la disattivazione dei servizi, bensì la rimozione effettiva delle applicazioni allo scopo di ottenere un'installazione di Windows più leggera. Questa opzione è assolutamente da scoraggiare. Rimuovendo i file binari da Windows allo scopo di ridurlo, si corre il rischio di renderlo meno stabile o protetto. Se occorre una versione ridotta di Windows, è consigliabile utilizzare Windows XP Embedded. È necessario dedicare un po' di tempo all'apprendimento e al perfezionamento dell'immagine, ma è un sistema molto potente e, soprattutto, supportato da Microsoft.
Come per la versione ridotta di Windows XP, utilizzare una versione precedente di Windows può risultare interessante, ma la mancanza di supporto, aggiornamenti e protezione dovrebbe scoraggiare questa scelta. Le soluzioni già supportate da Microsoft sono sufficienti a soddisfare la richiesta di un sistema informatico più leggero che consenta di sfruttare al meglio l'hardware obsoleto senza sacrificare le funzionalità o i livelli di protezione indispensabili.

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.


 Taccuino: Preparazione di IT 2.0
Taccuino
Preparazione di IT 2.0
Romi Mahajan

In La vita della ragione, il grande filosofo e saggista George Santayana scrisse che "chi non sa ricordare il passato è condannato a ripeterlo", sottolineando l'estrema importanza di imparare dagli errori del passato per costruire attivamente un futuro migliore. L'applicazione di questo pensiero è chiara nel mondo della politica, della cultura, della storia e anche della scienza. Infatti, il concetto di "imparare dagli errori" è talmente comune da essere diventato un cliché. Tuttavia, quanti di noi nel settore IT (Information Technology) pensano veramente al passato e a imparare da esso? Se non lo facciamo, siamo completamente preparati al mondo IT del futuro? E come sarà davvero questo mondo futuro?
Immaginiamolo, usando la memoria. Negli ultimi 30 anni ci sono stati profondi cambiamenti. Il settore IT si è evoluto passando da grandi mainframe a informatica basata su browser, dalla concentrazione alla proliferazione dei dispositivi, dall'immaturità e dalla limitazione delle conoscenze a un'iper-specializzazione e a una diffusione capillare, da una relativa semplicità a una straordinaria complessità delle informazioni. Partendo da questi presupposti, possiamo prevedere che l'IT del futuro sarà più complesso, specializzato e democratizzato. Dovrà supportare un crescente numero di dispositivi e piattaforme di ogni tipo. Tutto questo richiederà una pianificazione molto più dettagliata di quella attuale.
Queste nozioni sono state interiorizzate da tutti? Non proprio.
Consideriamo, ad esempio, alcuni interventi a un convegno che ho recentemente condotto sulla "IT consumerization" (tendenza delle aziende a utilizzare soluzioni destinate agli utenti privati) durante una conferenza sulla tecnologia svoltasi nel novembre 2007. Le premesse del dibattito erano semplici: i confini tra le tecnologie per le aziende e per gli utenti privati stanno sgretolandosi, i dispositivi e le applicazioni per gli utenti privati guidano lo sviluppo del settore IT, che deve mettersi in moto per affrontare fenomeni su scala globale quali Facebook, iTunes e BlackBerry. Troppo semplice? Ovvio? Antiquato?
Affatto, a giudicare dalla reazione dei miei interlocutori. Su un centinaio di persone, solo 4 hanno dichiarato di essere iscritti a Facebook. "È per i giovani", ha affermato un partecipante. "Perché? I dipendenti a cui fornisce supporto il settore IT della tua azienda non sono giovani e iscritti a Facebook?" ha chiesto uno dei relatori. Questo ha generato confusione e dinieghi. Solo un ristretto numero di responsabili IT presenti al convegno aveva reputato necessario assumere persone che sapessero come creare e supportare applicazioni e dispositivi legati alle nuove piattaforme che occupano la maggior parte del tempo dedicato alla tecnologia delle persone.
Quando è stato chiesto come creare criteri IT efficaci per regolare l'utilizzo e la protezione di tecnologie con un duplice utilizzo (professionale e privato) come telefoni cellulari e computer portatili, dal rumoreggiare della folla è emersa sostanzialmente un'unica opinione. Il sentimento comune è stato espresso da una persona che ha detto, nel tipico stile dell'IT 1.0, che se qualcuno del suo ufficio avesse collegato un lettore MP3 a un computer portatile utilizzato per lavoro o avesse accidentalmente lasciato il cellulare aziendale al bar, lo avrebbe licenziato.
Interessante. Continua così.
Questa mentalità ristretta si evidenzia anche nell'aridità delle conferenze per i leader IT. Se assisto a un'altra serie di conferenze dedicate a nozioni vaghe di allineamento aziendale dell'IT o di scorecard comuni, credo che smetterò di viaggiare. Perché non ci sono più persone che si chiedono cosa sia l'IT 2.0 e cosa sia necessario fare per non rimanere indietro? Perché non ci stiamo chiedendo quali siano le competenze e le attitudini necessarie ai professionisti IT di nuova generazione per creare un futuro dinamico? Perché non ci lamentiamo del fatto che nemmeno una società considera il proprio reparto IT allo stesso modo in cui le società innovative considerano i propri reparti R&D? Invece di discutere di accentramento e decentramento, perché non affrontiamo il nodo reale: totalitarismo IT contro democratizzazione IT?
Dobbiamo avere più stima di noi stessi dimostrando di preoccuparci del futuro. Tutti hanno sentito parlare di Web 2.0. È arrivato il momento di pensare all'IT 2.0 se vogliamo davvero realizzare qualcosa che si avvicini almeno un po' al potenziale della tecnologia.

Romi Mahajan è direttore del team Technical Audience and Platform Marketing di Microsoft. Romi ha pubblicato saggi in molti campi, tra cui politica, ambiente, tecnologia e sociologia.


 Windows Confidential: Come le versioni Beta sono diventate RC
Windows Confidential
Come le versioni Beta sono diventate RC
Raymond Chen

In passato, le versioni preliminari dei prodotti Windows® seguivano una progressione standard relativamente semplice. Prima venivano rilasciate le versioni alfa, utilizzate internamente e, se possibile, in condivisione con i partner di sviluppo software esterni al team del prodotto Windows.
Successivamente venivano rilasciate le versioni beta destinate a un pubblico più ampio. Una delle principali differenze tra le versioni alfa e beta riguardava i destinatari: le versioni beta non erano rivolte agli sviluppatori di software, ma, ad esempio, a utenti che desideravano testare il software preliminare e ad aziende che desideravano iniziare a valutare il nuovo sistema operativo per determinare la compatibilità del nuovo prodotto non solo con le applicazioni critiche interne esistenti, ma anche con la rete aziendale, le configurazioni hardware standard e gli strumenti di gestione di sistema.
Infine, venivano rilasciate le versioni finali candidate. Si trattava, come suggerisce il nome stesso, delle versioni del codice candidate per la versione finale. In altre parole: "se tutto va bene, distribuiremo questa creatura". Se la procedura veniva interrotta a causa di errori gravi, una volta risolto l'errore veniva creata una nuova versione finale candidata e il ciclo di test ricominciava da capo. Windows 95 è arrivato alla sesta versione finale candidata.
Mi è stato raccontato che per Windows NT® è stato seguito lo stesso percorso di denominazione della versione, ma si è verificato un problema: le aziende non si preoccuparono di testare le applicazioni critiche di cui disponevano sulle versioni beta di Windows NT. A grandi linee, l'approccio fu questo: "Perché preoccuparsi? È solo una versione beta. Le versioni beta sono per i fanatici. Tanto cambierà tutto nella versione finale. Qualsiasi test fatto adesso sarebbe solo una perdita di tempo".
Analogamente, le società di software non dedicarono attenzione ai problemi riscontrati durante i test della versione beta di Windows NT. "Non supportiamo le versioni beta dei sistemi operativi", avrebbero risposto.
Queste società iniziarono a condurre effettivamente i test una volta rilasciata la versione finale candidata, riscontrando inevitabilmente una serie di problemi. Alcuni furono risolti dalle stesse società, altri risultarono più complessi poiché riguardavano la "scarsa compatibilità" di Windows NT con la precedente versione del sistema operativo. Emersero anche problemi minori legati al funzionamento di una particolare funzionalità del progetto, alcuni dei quali furono tuttavia risolti in breve tempo. Alcuni problemi, però, erano talmente seri da causare il rinvio del rilascio del prodotto per consentire al team di risolverli.
Queste versioni finali candidate generarono anche molti suggerimenti. Microsoft ha ricevuto commenti su come migliorare l'interfaccia utente disponendo in modo diverso i pulsanti oppure su come riformulare un determinato messaggio per renderlo più chiaro ai dipendenti. Se fossero arrivati durante la fase beta, questi suggerimenti sarebbero stati preziosi. Una volta rilasciata la prima versione finale candidata, invece, non è più possibile effettuare modifiche all'aspetto dell'interfaccia. I file della guida e della documentazione sono già stati scritti, il prodotto è stato tradotto in decine di lingue, le schermate per il manuale e la confezione del prodotto sono già state definite, finalizzate, separate per colore e stampate. Tutto questo lavoro non può essere buttato e rifatto solo per spostare un pulsante.
Ricordo una riunione durante l'epoca di Windows XP nella quale si discuteva di una di queste modifiche dell'ultimo minuto. Se implementata, sarebbe stato necessario modificare un file della guida da 20 KB in modo che le istruzioni corrispondessero alla nuova interfaccia utente. Il responsabile della localizzazione e della traduzione ci informò che ritradurre il file della guida modificato in un periodo di tempo così limitato sarebbe costato centinaia di migliaia di dollari.
Per contrastare il pensiero comune della scarsa utilità delle versioni beta, il team di Windows NT ricorse all'innalzamento di grado delle versioni. Esistono ancora versioni beta, ma le ultime versioni beta vengono rilasciate come versioni finali candidate quando è ancora possibile (sebbene per un breve periodo di tempo) apportare qualche cambiamento. Le ex versioni finali candidate adesso vengono chiamate versioni escrow (depositate). Il termine "escrow" (depositato) suggerisce l'effettivo stato della versione: "è finita e non verrà toccata se non in caso di reale emergenza".

Raymond Chen, The Old New Thing, così come nell'omonimo libro (Addison-Wesley, 2007), vengono illustrate la storia di Windows e la programmazione in Win32. Pensa di poter vedere la sua casa da qui.