 TechNet Magazine February 2007
TechNet Magazine February 2007
FEBRUARY 2007
Amministrazione di Windows

Questo mese, Mark Russinovich esamina il kernel di Windows Vista per spiegare gli algoritmi di misurazione delle prestazioni di thread e processi per avere un quadro più accurato di come viene impiegato il tempo CPU. Spiega, inoltre, il Servizio Utilità di pianificazione classi multimediali che fornisce agli utenti un'esperienza di riproduzione più intuitiva grazie alla migliore gestione delle attività in background quali anti-virus e indicizzazione dati.

Sempre questo mese verranno esaminate le funzionalità di delega in Active Directory e i modelli di Criteri di gruppo in Windows Vista, in modo da poter utilizzare al meglio i Criteri di gruppo. E, naturalmente, saranno presenti i soliti habitué, tra cui The Cable Guy, The Scripting Guys e Windows Confidential.
FUNZIONALITÀ
Amministrazione di Windows Il Kernel di Windows Vista: Parte 1

Con Windows Vista, le modifiche al kernel del sistema operativo comportano dei progressi in molte aree, dalla gestione della memoria all'affidabilità fino alla protezione. Si dia inizio a questa serie prendendo in considerazione il modo in cui il kernel può offrire dei miglioramenti nelle aree relative a processi, thread e I/O.

Mark Russinovich Delega dell'autorità in Active Directory

L'implementazione della delega in Active Directory può migliorare la protezione e semplificare le attività di gestione; iniziare sarà un gioco da ragazzi. Ecco alcuni semplici modelli di delega che funzionano nella maggior parte delle infrastrutture IT con qualche piccola modifica.

Joel Yoker e Rob Campbell Nuovi modelli di Criteri di gruppo in Windows Vista

Windows Vista introduce delle modifiche significative ai modelli di Criteri di gruppo. Scopri tutto quello che c'è da sapere sul nuovo formato, chiamato ADMX, e in che modo queste modifiche possono migliorare l'amministrazione delle configurazioni di sistema.

Darren Mar-Elia Guida alla risoluzione dei problemi di Criteri di gruppo

Un esame approfondito dei problemi di Criteri di gruppo può essere un processo difficile, ma se si è a conoscenza del funzionamento di Criteri di gruppo e di dove possono insorgere i problemi, tutto diventa più facile. Con questi cenni preliminari sarà possibile risolvere brillantemente i problemi su indicati.

Derek Melber Monitoraggio di Active Directory con MOM

Con i management pack di Microsoft Operations Manager 2005 sarà possibile monitorare in modo ancora più efficace l'infrastruttura IT. Scopri come questi cinque management pack possono aiutarti a tenere d'occhio l'integrità, la protezione e l'affidabilità dell'ambiente Active Directory.

John Hann Gioco in un ambiente protetto

Sia che si lavori o che si giochi a casa, l'esecuzione come utente con limitazioni presenta numerosi vantaggi per la sicurezza. Sfortunatamente, alcuni giochi non funzionano se non sono eseguiti come amministratore. Ecco alcuni problemi comuni e le relative soluzioni.

Matt Clapham
COLONNE
Dal redattore

Dietro le quinte

Joshua Trupin Casella degli strumenti

Nuovi prodotti per professionisti IT

Greg Steen SQL: Domande&Risposte

Dimensione del database, mirroring, transazioni contrassegnate e altro

A cura di Nancy Michell Funzione Spotlight

Inventario dei criteri di gruppo

Greg Steen The Cable Guy

Supporto QoS in Windows

Joseph Davies 		Windows PowerShell

Esecuzione di script una riga per volta

Don Jones Hey, Scripting Guy!

Chasing Cars... e XML

Gli Scripting Guys di Microsoft Controllo protezione

Distribuzione di EFS: Parte 1

John Morello Desktop File

Estensione di Windows PE

Wes Miller Appunti

Non funziona più

R'ykandar Korra'ti Windows Confidential

Una situazione abbastanza favorevole

Raymond Chen


 Amministrazione Windows: Nel kernel di Windows Vista: Parte 1:
Amministrazione Windows Mark Russinovich

Nel kernel di Windows Vista: Parte 1:
Panoramica:
  • Pianificazione e priorità dei thread
  • Collegamenti simbolici basati su file
  • Annullamento di operazioni I/O

Questa è la prima parte di una serie dedicata alle novità del kernel di Windows Vista. In questo numero, affronterò la questione delle modifiche a processi, thread e I/O. Prossimamente mi occuperò di gestione della memoria, avvio e arresto del sistema, affidabilità, ripristino e protezione.
Questo articolo comprende solo le modifiche al kernel Windows Vista™, in particolare Ntoskrnl.exe e relativi componenti associati. Si ricordi che esistono molte altre importanti modifiche in Windows Vista che non riguardano strettamente il kernel e che quindi non verranno trattate in questa occasione. Tali modifiche includono miglioramenti alla shell (ad esempio la ricerca desktop integrata), alla rete (come il nuovo stack IPv6 e il firewall bidirezionale), il modello di grafica della prossima generazione (come Aereo™ Glass, Windows® Presentation Foundation, la Gestione finestre desktop e il nuovo modello di driver di grafica). Inoltre non verranno trattati i nuovi UMDF e KMDF (User-Mode e Kernel-Mode Driver Framework) di Windows perché sono installabili su versioni precedenti di Windows.

Conteggio cicli CPU
Windows Vista fornisce molti miglioramenti relativi a processi e thread, tra cui l'utilizzo del contatore di cicli CPU per un'assegnazione equa delle CPU e il nuovo Servizio Utilità di pianificazione classi multimediali (MMCSS) che consente alle applicazioni multimediali di ottenere una riproduzione senza problemi.
Tutte le versioni di Windows NT® compreso Windows Vista, programmano una routine di interrupt con timer intervallo che viene eseguita approssimativamente ogni 10 o 15 millisecondi, a seconda della piattaforma hardware. La routine analizza il thread che ha interrotto e ne aggiorna le statistiche di utilizzo della CPU, come se il thread fosse stato eseguito per tutto l'intervallo, mentre in realtà l'esecuzione avrebbe potuto iniziare poco prima della fine dell'intervallo. Inoltre è possibile che la CPU sia stata assegnata tecnicamente al thread e che questo non sia stato eseguito a causa delle routine di interrupt hardware e software.
Mentre il conteggio del tempo in base all'orologio può funzionare per strumenti di diagnostica che rilevano l'utilizzo della CPU per thread e processi, l'uso di tale metodo da parte dell'utilità di pianificazione dei thread può determinare una allocazione della CPU non corretta. Per impostazione predefinita, nelle versioni client di Windows i thread possono essere eseguiti fino a 2 cicli macchina (6 se in primo piano). Tuttavia, il thread potrebbe virtualmente non disporre di alcun intervallo di tempo per la CPU o solo un massimo di 6 cicli (18 se in primo piano), a seconda del suo comportamento e delle altre attività nel sistema.
Nella Figura 1 viene illustrato cosa si verifica quando due thread con la stessa priorità sono pronti per essere eseguiti contemporaneamente. Il thread A viene eseguito fino al termine dell'intervallo di tempo successivo, quando l'utilità di pianificazione presume che sia stato eseguito per tutto l'intervallo e decide pertanto che il turno del thread A sia terminato. Inoltre, il thread A viene penalizzato per l'interruzione avvenuta durante il suo turno. All'intervallo successivo, l'utilità di pianificazione seleziona il thread B che viene eseguito per un intero intervallo.
Figura 1 Pianificazione dei thread non bilanciata
Figura 1 Pianificazione dei thread non bilanciata
In Windows Vista, l'utilità di pianificazione utilizza il registro del contatore di cicli dei moderni processori per tenere traccia con esattezza del numero di cicli CPU eseguiti dal thread. Valutando il numero di cicli che la CPU può eseguire in un intervallo di tempo, è possibile ripartire i turni della CPU con maggiore precisione. Inoltre l'utilità di pianificazione di Windows Vista non conta l'esecuzione delle interruzioni nel turno del thread. Ciò significa che in Windows Vista un thread ottiene sempre almeno un turno sulla CPU e mai più di un intervallo di esecuzione extra, il che determina un maggiore equilibrio e un comportamento più deterministico dell'applicazione. Nella Figura 2 viene illustrato il modo il cui Windows Vista risponde allo scenario della Figura 1, assegnando ad entrambi i thread almeno un intervallo di esecuzione.
Figura 2 Pianificazione di Windows Vista basata su cicli
Figura 2 Pianificazione di Windows Vista basata su cicli
Nella sezione "Watching Process CPU Usage" della barra laterale viene spiegato come sia possibile monitorare l'utilizzo del ciclo CPU processo utilizzando l'utilità Process Explorer.

Servizio Utilità di pianificazione classi multimediali
Gli utenti si aspettano che le applicazioni multimediali, compresi i lettori audio e video, offrano una riproduzione senza interruzioni. Tuttavia la richiesta di CPU da parte di altre applicazioni eseguite simultaneamente, quali antivirus, indicizzazione del contenuto o anche client di posta elettronica, può causare spiacevoli interruzioni. Per fornire un'esperienza di riproduzione migliore, Windows Vista introduce MMCSS per gestire le priorità delle CPU dei thread multimediali.
Un'applicazione multimediale come Windows Media® Player 11 si registra con MMCSS utilizzando nuove API che indicano le relative caratteristiche multimediali che devono corrispondere a una di quelle elencate per nome nella seguente chiave del Registro di sistema:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

Figura A Visualizzazione del tempo CPU e dei Delta Cycles (Cicli delta) in Process Explorer (Fare clic sull'immagine per ridurla)
Figura A Visualizzazione del tempo CPU e dei Delta Cycles (Cicli delta) in Process Explorer
Figura A Visualizzazione del tempo CPU e dei Delta Cycles (Cicli delta) in Process Explorer (Fare clic sull'immagine per ingrandirla)

Figura 3 Definizione dell'attività audio dell'unità di pianificazione delle classi multimediali
Figura 3 Definizione dell'attività audio dell'unità di pianificazione delle classi multimediali (Fare clic sull'immagine per ridurla)
Figura 3 Definizione dell'attività audio dell'unità di pianificazione delle classi multimediali
Figura 3 Definizione dell'attività audio dell'unità di pianificazione delle classi multimediali (Fare clic sull'immagine per ingrandirla)
MMCSS, implementato in %SystemRoot%\System32\Mmcss.dll ed eseguito in un processo Host servizio (Svchost.exe), dispone di un thread di gestione delle priorità che viene eseguito con priorità 27 (le priorità dei thread in Windows variano da 0 a 31). Questo thread aumenta la priorità dei thread multimediali registrati nell'intervallo associato al valore Scheduling Category della relativa chiave del Registro di sistema delle attività, come illustrato nella Figura 4. In Windows, le priorità dei thread a partire da 16 sono comprese nell'intervallo di priorità in tempo reale e a un livello superiore di tutti gli altri thread del sistema (ad eccezione dei thread di lavoro del Memory Manager del kernel, che viene eseguito alle priorità 28 e 29). Solo gli account amministrativi, come l'account Sistema locale in cui viene eseguito MMCSS, godono del privilegio Increase Priority (Aumenta priorità), richiesto per impostare le priorità di thread in tempo reale.
Figure 4 Priorità thread di MMCSS (Close Figure 4)

Categoria di pianificazione | Priorità di thread incrementata
Alta | 23-26
Media | 16-23
Quando si riproduce un file audio, Windows Media Player registra i thread di attività Audio, mentre quando si riproduce un video, registra i thread di attività Riproduzione. Il servizio MMCSS fa avanzare tutti i thread che hanno indicato di eseguire un flusso mentre vengono eseguiti nel processo proprietario della finestra di primo piano e quando il relativo valore BackgroundOnly è impostato su True nella chiave di definizione dell'attività.
Se da un lato il servizio MMCSS consente ai thread multimediali di ottenere il tempo CPU di cui necessitano, dall'altro garantisce che anche gli altri thread ottengano almeno una parte di tempo CPU, in modo da mantenere la velocità di risposta del sistema e delle altre applicazioni. MMCSS riserva quindi una percentuale del tempo CPU per altre attività, specificata nel seguente valore del Registro di sistema:
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
Per impostazione predefinita, questo valore è pari al 20 percento. MMCSS controlla l'utilizzo della CPU per assicurare che i thread multimediali non siano eseguiti per più di 8 - 10 ms, se altri thread richiedono la CPU. Per lasciare da parte i thread multimediali per i rimanenti 2 ms, l'utilità di pianificazione riduce le rispettive priorità nell'intervallo 1-7.
Per vedere come MMCSS incrementa la priorità dei thread, è possibile leggere "Watching MMCSS Priority Boosting" nella barra laterale.

Collegamenti simbolici basati su file
Le modifiche in Windows Vista associate a I/O includono collegamenti simbolici basati su file, elaborazione del completamento I/O più efficiente, supporto completo per l'annullamento I/O e I/O con priorità.
In Windows Vista è finalmente disponibile una funzione del file system che molti ritenevano mancasse in NTFS, il collegamento simbolico ai file (o collegamento soft, come viene chiamato in UNIX). La versione Windows 2000 di NTFS ha introdotto collegamenti simbolici a directory, chiamati giunzioni di directory, che consentono di creare una directory che ne indica un'altra, ma fino alla versione di Windows Vista, NTFS supportava soltanto collegamenti reali ai file.
Una delle principali differenze nel modo in cui Windows risolve i collegamenti simbolici e le giunzioni di directory consiste nel punto in cui avviene l'elaborazione. Windows elabora i collegamenti simbolici nel sistema locale, anche quando fanno riferimento a una posizione su un file server remoto. Windows elabora le giunzioni di directory che fanno riferimento a un file server remoto sul server stesso. I collegamenti simbolici su un server possono dunque fare riferimento a posizioni accessibili soltanto da un client, come altri volumi di client, mentre le giunzioni di directory non lo possono fare. Per risolvere questo problema, Windows Vista supporta il nuovo tipo di collegamento simbolico sia per i file che per le directory.
Molti comandi del file system sono stati aggiornati per capire le implicazioni dei collegamenti simbolici. Ad esempio, il comando Elimina non segue mai i collegamenti, perché causerebbe l'eliminazione della destinazione, ma elimina il collegamento. Tuttavia, poiché non tutte le applicazioni possono gestire correttamente i collegamenti simbolici, la creazione di questi ultimi richiede il nuovo privilegio Create Symbolic Link (Crea collegamento simbolico) di cui dispongono solo gli amministratori per impostazione predefinita.
È possibile creare un collegamento simbolico da un prompt dei comandi con il comando Mklink. Il comando della directory incorporata del prompt dei comandi identifica un collegamento simbolico contrassegnandolo con <SYMLINK> e mostrando la destinazione tra parentesi, come indicato nella Figura 5. Anche Esplora risorse riconosce i collegamenti simbolici e li visualizza con un'apposita freccia. È possibile visualizzare la destinazione di un collegamento in Esplora risorse aggiungendo la colonna per le destinazioni di collegamento nella finestra di ricerca.Osservazione dell'avanzamento delle priorità in i MMCSS
È possibile osservare gli avanzamenti dei thread applicati dal servizio MMCSS a Windows Media Player riproducendo un video o clip audio, eseguendo il Performance Monitor, impostando la scala del grafico su 31 (la priorità massima dei thread di Windows) e aggiungendo alla visualizzazione il contatore Priorità corrente per tutte le istanze di oggetti thread di Windows Media Player (Wmplayer.exe). Uno o più thread verrà eseguito con priorità 21.
Figura B Avanzamento delle priorità thread per Windows Media Player
Figura B Avanzamento delle priorità thread per Windows Media Player (Fare clic sull'immagine per ridurla)
Figura B Avanzamento delle priorità thread per Windows Media Player
Figura B Avanzamento delle priorità thread per Windows Media Player (Fare clic sull'immagine per ingrandirla)

Figura 5 Utilizzo di Mklink per creare un collegamento simbolico
Figura 5 Utilizzo di Mklink per creare un collegamento simbolico (Fare clic sull'immagine per ridurla)
Figura 5 Utilizzo di Mklink per creare un collegamento simbolico
Figura 5 Utilizzo di Mklink per creare un collegamento simbolico (Fare clic sull'immagine per ingrandirla)

Completamento e annullamento I/O
Sono state apportate molte modifiche interne al sistema I/O che consentono di migliorare le prestazioni delle applicazioni server. Queste applicazioni utilizzano generalmente un oggetto di sincronizzazione chiamato porta di completamento, che attende il completamento delle richieste I/O asincrone. Prima di Windows Vista, un I/O sarebbe stato completato dallo stesso thread che lo aveva emesso, comportando quindi il passaggio al processo cui apparteneva il thread e l'interruzione di tutte le altre attività in corso. Il sistema I/O avrebbe quindi aggiornato lo stato della porta di completamento per riattivare il thread in attesa della modifica.
In Windows Vista, l'elaborazione del completamento dell'I/O non viene eseguita necessariamente dal thread che lo ha emesso, ma dal thread in attesa di essere attivato dalla porta di completamento. Questa modifica di piccola entità consente di evitare una superflua pianificazione dei thread e commutazioni di contesto che possono ridurre le prestazioni globali dell'applicazione e del sistema. Per migliorare ulteriormente le prestazioni, un server può recuperare i risultati di diverse operazioni I/O da un completamento in una richiesta, evitando transizioni alla modalità kernel.
Probabilmente la modifica più visibile del sistema I/O, per l'utente finale, è il supporto di Windows Vista per l'annullamento di operazioni I/O sincrone. Se è stato eseguito un comando net view o si è tentato di accedere a una condivisione in un sistema remoto non in linea utilizzando Windows XP o Windows Server® 2003, si saranno sicuramente riscontrati problemi con le operazioni I/O che non è possibile annullare: il comando o il browser di file non rispondono fino allo scadere del timeout di rete. Un'applicazione non può che rimanere in attesa finché l'operazione termina con esito negativo, in quanto non esistono modi per comunicare al driver del dispositivo che esegue l'I/O che l'applicazione non se ne occupa più.
In Windows Vista la maggior parte delle operazioni I/O può essere annullata, compreso l'I/O del file aperto utilizzato da Net View ed Esplora risorse. Tuttavia, le applicazioni devono essere aggiornate per rispondere alle richieste di annullamento I/O dell'utente finale e molte delle utilità di Windows Vista che interagiscono con i dispositivi dotati di timeout dispongono del supporto necessario. Ad esempio, le finestre di dialogo per aprire e salvare i file, utilizzate da tutte le applicazioni Windows e di terze parti, attualmente attivano il pulsante Annulla mentre tentano di visualizzare il contenuto di una cartella. Premendo Ctrl+C, il comando Net annulla inoltre l'I/O sincrono.
Per osservare i vantaggi dell'annullamento I/O, è necessario aprire un prompt dei comandi su Windows Vista e digitare:
net view (\\nonexistentmachine)
Il comando rimane in sospeso mentre Windows tenta di contattare il sistema inesistente, tuttavia per terminare l'operazione basta premere Ctrl+C. In Windows XP, Ctrl+C non ha effetto e il comando non viene riattivato finché l'operazione di rete non scade.
Un altro tipo di I/O che in precedenti versioni di Windows ha causato problemi agli utenti è quello che i driver del dispositivo non hanno annullato correttamente, in quanto non esisteva un facile metodo che ne indicasse la necessità. Sarà forse capitato di terminare un processo e di vederlo comparire successivamente in certi strumenti di visualizzazione dei processi: in questo caso, il driver del dispositivo non aveva risposto correttamente alla richiesta di terminazione di un processo e di annullamento dell'operazione I/O emessa dal processo non completato. Windows non può eseguire la pulizia finale di un processo finché tutte le operazioni I/O del processo stesso non siano terminate o annullate. In Windows Vista, i driver del dispositivo si registrano facilmente per la notifica della terminazione dei processi: ciò risolve, pertanto, la maggior parte dei problemi relativi ai processi che non si riesce a chiudere.

Priorità I/O
Mentre Windows ha sempre supportato l'impostazione delle priorità per l'utilizzo della CPU, non ha mai previsto il concetto di priorità I/O. In assenza di priorità I/O, le attività in background come l'indicizzazione ricerca, la ricerca di virus e la deframmentazione del disco possono avere un notevole effetto sulla velocità di risposta delle operazioni di primo piano. Ad esempio, quando si avvia un'applicazione o si apre un documento mentre un altro processo sta eseguendo un I/O del disco, si possono verificare ritardi se l'attività di primo piano rimane in attesa di accedere al disco. La stessa interferenza si verifica inoltre sul flusso di riproduzione del contenuto multimediale, ad esempio canzoni, dal disco rigido.
Windows Vista introduce due nuovi tipi determinazione delle priorità I/O per consentire di assegnare una preferenza alle operazioni I/O di primo piano: priorità delle singole operazioni I/O e delle prenotazioni di larghezza di banda I/O. Il sistema I/O di Windows Vista comprende il supporto per cinque priorità I/O come indicato nella Figura 6, tuttavia ne vengono utilizzate solo quattro (le versioni future di Windows supporteranno la priorità Alta).
Figure 6 Priorità I/O di Windows Vista (Close Figure 6)

Priorità I/O | Utilizzo
Critica | Gestore della memoria
Alta | Non utilizzato
Normale | Priorità predefinita
Bassa | Priorità attività predefinita
Molto bassa | Attività in background
La priorità I/O predefinita è Media e Memory Manager utilizza Critico quando scrive sul disco dati di memoria modificati in situazioni di memoria insufficiente, al fine di creare spazio nella RAM per altri dati e codici. L'Utilità di pianificazione di Windows imposta la priorità I/O per le attività con priorità impostata su Bassa e la priorità specificata dalle applicazioni scritte per Windows Vista che eseguono l'elaborazione in background è impostata su Molto bassa. Tutte le operazioni in background di Windows Vista, comprese l'analisi di Windows Defender e l'indicizzazione ricerca desktop, utilizzano Molto bassa come priorità I/O.Visualizzazione della priorità I/O Molto bassa
Process Monitor, un'utilità di monitoraggio del Registro di sistema e del file system di Sysinternals, raccoglie informazioni dettagliate per operazioni di lettura e di scrittura del file system, comprese le relative priorità I/O in Windows Vista. La riga evidenziata mostra un esempio di un I/O con priorità Molto bassa, emesso da SuperFetch (di cui tratterò nella prossima puntata).
Figura C Visualizzazione della priorità I/O Molto bassa in Process Monitor
Figura C Visualizzazione della priorità I/O Molto bassa in Process Monitor (Fare clic sull'immagine per ridurla)
Figura C Visualizzazione della priorità I/O Molto bassa in Process Monitor
Figura C Visualizzazione della priorità I/O Molto bassa in Process Monitor (Fare clic sull'immagine per ingrandirla)

Il driver del dispositivo per le classi di archiviazione (%SystemRoot%\System32\Classpnp.sys) attiva delle priorità I/O, pertanto queste vengono applicate automaticamente agli I/O diretti alla maggior parte delle periferiche di archiviazione. I driver di classe e archiviazione impostano la priorità I/O su Media, anteponendola ai valori Bassa e Molto bassa che sono in coda, tuttavia emettono almeno un I/O con priorità Bassa o Molto bassa in attesa ogni secondo, in modo che i processi in background possano avanzare. I dati letti utilizzando la priorità I/O Molto bassa fanno sì che il gestore della cache scriva immediatamente le modifiche sul disco e ignori la logica della lettura in avanti per operazioni di lettura che altrimenti verrebbero lette in maniera preventiva accedendo al file. Per un esempio di come impostare la priorità I/O Molto bassa utilizzando l'utilità Process Monitor, vedere "Seeing Very Low I/O Priority" (in inglese) nella barra laterale.
Il supporto di prenotazione della larghezza di banda di Windows Vista è utile per i lettori multimediali e viene utilizzato da Windows Media Player insieme agli incrementi di priorità di MMCSS per ottenere una riproduzione di contenuto locale quasi completamente priva di problemi. Un lettore multimediale chiede al sistema I/O di garantire che sia possibile leggere i dati a una determinata velocità e, se il dispositivo è in grado di recapitare dati alla velocità richiesta e le prenotazioni esistenti lo consentono, fornisce indicazioni all'applicazione sulla velocità e la dimensione degli I/O. Il sistema I/O non eseguirà altri I/O a meno che non riesca a soddisfare i requisiti delle applicazioni che hanno effettuato prenotazioni per la periferica di archiviazione di destinazione.
Un'ultima modifica nel sistema I/O che vale la pena di ricordare riguarda le dimensioni delle operazioni I/O. Dalla prima versione di Windows NT, il gestore della memoria e il sistema I/O hanno limitato l'entità dei dati elaborati da una richiesta I/O di archiviazione singola a 64 KB. Pertanto, anche se un'applicazione emette una richiesta di I/O di dimensioni superiori, questa viene suddivisa in singole richieste con dimensione massima di 64 KB. Ogni I/O incorre in un overhead per le transizioni in modalità kernel e nell'avvio di un trasferimento di I/O sulla periferica di archiviazione, pertanto in Windows Vista le dimensioni delle richieste I/O di archiviazione non sono più limitate. Diversi componenti in modalità utente di Windows Vista sono stati modificati per sfruttare il supporto per I/O di dimensioni maggiori, compresa la funzionalità di copia di Esplora risorse e il comando Copia del prompt dei comandi, che attualmente emettono I/O da 1 MB.

Nella prossima puntata
Finora abbiamo esaminato due aree in cui il kernel di Windows Vista è stato migliorato. È possibile trovare informazioni approfondite nella prossima edizione del mio libro, Windows Internals (redatto in collaborazione con David Salomone) (in inglese), che verrà pubblicato insieme alla prossima versione di Windows Server, il cui nome in codice è "Longhorn". Nella prossima puntata continuerò la presentazione del nuovo kernel con riferimento alla gestione della memoria e all'avvio e arresto del sistema.

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


 Amministrazione di Windows: Delega dell'autorit&#224; in Active Directory
Amministrazione di Windows Joel Yoker and Rob Campbell

Delega dell'autorità in Active Directory
Panoramica:
  • Definizione dei ruoli amministrativi
  • Sviluppo di un modello dell'unità organizzativa e dei gruppi di protezione
  • Uso degli account secondari
  • Strumenti per la delega dei diritti

Le funzionalità di delega in Active Directory sono molto potenti, risolvono numerosi problemi di protezione e semplificano le attività di gestione. Delegando adeguatamente i diritti in Active
Directory® è possibile applicare ruoli specificati nell'ambiente, limitare l'impatto e la probabilità di errori amministrativi, nonché applicare il principio del privilegio minimo in tutta l'infrastruttura. Nonostante questo, molte delle organizzazioni che utilizzano Active Directory non sfruttano ancora il potere della delega. Ciò è dovuto in parte al fatto che lo sviluppo di un modello di delega in Active Directory per l'organizzazione appare a prima vista piuttosto complicato. Da una parte, il maggiore ostacolo è sviluppare un modello di delega adatto alle esigenze specifiche dell'organizzazione; ma in realtà esistono modelli molto semplici che possono essere applicati con poche modifiche alla maggior parte delle infrastrutture IT.
Anche se ogni ambiente è diverso in qualche modo, in realtà la maggior parte delle grandi organizzazioni sono simili per molti aspetti e devono affrontare le stesse problematiche nel campo IT. Ad esempio, molte organizzazioni sono divise in regioni geografiche, si sono sviluppate da team di progettazione o assistenza IT separati e hanno unità aziendali indipendenti. Inoltre, molte grandi organizzazioni devono affrontare questioni come l'escalation dei privilegi, l'uso scorretto degli account di servizio e l'"attendibilità".
"Attendibilità" è un termine interessante che spesso viene usato per giustificare l'esistenza di insiemi di strutture di Active Directory multiple. I problemi relativi all'attendibilità derivano spesso dalla capacità di una divisione o di una regione di incidere sulla disponibilità del sistema di un'altra divisione o regione. Spesso i livelli di competenze sono diversi nelle varie suddivisioni dell'organizzazione e manca una conoscenza approfondita dei sistemi specifici necessari per supportare una determinata regione o Business Unit. Di conseguenza le divisioni solitamente non vogliono rinunciare ai propri diritti amministrativi a favore di un gruppo centrale.
Nel frattempo, per qualsiasi implementazione di Active Directory, gli amministratori devono definire le regole di base per le applicazioni che utilizzano l'infrastruttura di Active Directory. Purtroppo un approccio comune, spesso citato nelle guide di installazione delle applicazioni consiste nell'assegnare a un account di servizio l'appartenenza al gruppo Domain Admins. Il problema di questo approccio è che gli account di servizio sono essenzialmente account generici. Concedendo questi diritti di amministratore del dominio si crea un rischio significativo per l'ambiente IT. Gli account di servizio possono facilmente essere utilizzati in modo scorretto dagli amministratori, per errore o intenzionalmente, o essere utilizzati per attacchi che sfruttano i problemi di sicurezza sottostanti all'interno di un'applicazione.
Anche se questi ostacoli possono sembrare insormontabili, essi rappresentano uno scenario perfetto per l'implementazione di un modello di delega in Active Directory. Lo sviluppo di un modello di delega è un processo di progettazione iterativo, in cui è consigliabile seguire questa procedura:
  1. Definire i ruoli amministrativi IT all'interno dell'organizzazione.
  2. Sviluppare un modello per unità amministrative e gruppi di protezione.
  3. Definire gli account secondari per gli amministratori IT.
  4. Delegare i diritti.
Esaminiamo ora nei dettagli i vari passaggi.

Definire i ruoli
Il processo di definizione dei ruoli deve partire da una comprensione totale dell'amministrazione dei servizi e dei dati. Questi concetti sono l'elemento fondamentale di qualunque modello di delega in Active Directory.
Essenzialmente, per amministrazione dei servizi si intende la gestione dei componenti critici del servizio directory, come i controller di dominio e i server Exchange. Per amministrazione dei dati si intende la gestione di oggetti che risiedono in questi servizi, come le cassette postali e gli account utente. Per quanto riguarda Active Directory, gli amministratori dei servizi sono responsabili in ultima analisi della fornitura e disponibilità dei servizi directory, mentre gli amministratori dei dati gestiscono account di utenti e server, gruppi e altre risorse del dominio.
Active Directory supporta la delega granulare dell'autorità attraverso le unità organizzative. Le unità amministrative spesso possono essere costruite su misura per fornire agli amministratori lo stesso livello di autorità disponibile all'interno dei modelli esistenti di servizio directory o di dominio. Ma è importante capire che alcune funzioni non possono assolutamente essere delegate e devono essere gestite da un singolo gruppo o entità affidabile.
Anche l'analisi delle attività è molto importante. È necessario sapere quali attività di Active Directory sono eseguite dagli amministratori e in che modo tali attività corrispondono ai ruoli. Ad esempio, la creazione di sito di Active Directory è un'attività di amministrazione dei servizi, mentre la modifica dell'appartenenza al gruppo di protezione generalmente rientra nell'amministrazione dei dati. Ogni attività deve essere valutata dal punto di vista della frequenza, dell'importanza e della difficoltà. Questi sono aspetti fondamentali della definizione delle attività, perché determinano l'opportunità o meno di delegare un diritto. Le attività più adatte alla delega sono quelle che vengono eseguite regolarmente, presentano rischi limitati e sono facili da eseguire. Al contrario, le attività che vengono eseguite raramente, che hanno notevoli effetti in tutta l'organizzazione e che richiedono competenze di alto livello, sono poco adatte alla delega. La soluzione appropriata per queste attività è invece l'escalation, ossia l'elevazione temporanea di un account al ruolo richiesto o la riassegnazione dell'attività.
Poiché le grandi organizzazioni hanno molte caratteristiche simili, solitamente è possibile implementare un modello di delega comune. Ai fini di questo articolo, forniremo una serie di ruoli campione che consentono le funzionalità di gestione e, allo stesso tempo, rispettano i confini dell'organizzazione e cercano di limitare i problemi legati all'attendibilità, come ad esempio la disponibilità di risorse applicabili all'intera organizzazione quali i controller di dominio. Tenere presente che questo modello è solo un esempio: è ideale per avviare la discussione sui ruoli all'interno dell'organizzazione in cui si lavora, ma non sarà necessario seguire alla lettera queste indicazioni.
Alcuni ruoli sono già definiti da Active Directory, mentre altri devono essere creati da zero per completare il modello di delega. Una serie di ruoli campione adatta a molti grandi ambienti di Active Directory potrebbe includere Enterprise Admins, Domain Admins e amministratori di livello 4 per l'amministrazione dei servizi, e amministratori di livello 3, amministratori regionali e amministratori di livello 2 e di livello 1 per l'amministrazione dei dati. Vedere la Figura 1 per un elenco di questi ruoli con le rispettive responsabilità.
Figure 1 Definire ruoli e responsabilità (Close Figure 1)

Amministratori dei servizi | Descrizione
Enterprise Admins | Responsabili dell'amministrazione dei servizi al livello più alto in tutta l'organizzazione. Non deve contenere membri permanenti.
Domain Admins | Responsabili dell'amministrazione dei servizi al livello più alto in tutto il dominio. Deve contenere solo un numero ridotto e gestibile di amministratori di fiducia.
Tier 4 Admins | Responsabili dell'amministrazione dei servizi in tutto il dominio. Dotati solo dei diritti necessari per gestire i servizi necessari. Funge da punto di escalation per gli amministratori dei dati.
Amministratori dei dati | Descrizione
Tier 1 Admins | Responsabili della gestione generale degli oggetti di directory e dell'esecuzione di attività come reimpostazione delle password, modifica delle proprietà degli account utente e così via.
Tier 2 Admins | Responsabili della creazione e/o eliminazione selettiva di account utente e computer per la propria sede o organizzazione.
Regional Admins | Responsabili della gestione della struttura dell'unità amministrativa locale. Dotati delle autorizzazioni a creare la maggior parte degli oggetti all'interno della propria unità amministrativa.
Tier 3 Admins | Responsabili della gestione di tutti gli amministratori dei dati. Fungono da supporto tecnico di livello superiore e da punto di escalation per tutti gli amministratori regionali.

Amministratori dei servizi
Esaminiamo ora nel dettaglio i ruoli degli amministratori dei servizi. Gli amministratori dei servizi gestiscono i componenti critici dell'infrastruttura e tutti gli amministratori compresi in questa categoria hanno molti privilegi. In questo caso quindi è decisamente consigliata una strategia di privilegio minimo, che significa concedere solo le autorizzazioni necessarie per eseguire le attività richieste.
Enterprise Admins e Domain Admins. Active Directory definisce due gruppi di amministratori speciali il cui contesto di protezione è necessario per funzioni critiche all'interno della directory. I gruppi Enterprise Admins e Domain Admins sono responsabili dell'amministrazione dei servizi principale. Per ridurre i rischi associati a gruppi con tali privilegi, è consigliabile limitare strettamente l'appartenenza a questi gruppi. In pratica, il gruppo Enterprise Admins non deve avere membri permanenti, mentre il gruppo Domain Admins deve contenere solo un numero ridotto e facilmente gestibile di individui di fiducia che lavorano a tempo pieno per l'organizzazione.
Quando devono essere eseguite attività di amministrazione dell'organizzazione, come l'autorizzazione del server DHCP o la creazione del sito di Active Directory, i Domain Admins nel dominio principale dell'insieme di strutture di Active Directory possono aumentare i privilegi attraverso la gestione dell'appartenenza al gruppo Enterprise Admins. Questi privilegi devono essere concessi solo per brevi periodi, per evitare la creazione di membri permanenti del gruppo Enterprise Admins. Naturalmente tutti i membri di un gruppo Domain Admins in un insieme di strutture di Active Directory devono essere ugualmente affidabili.
Un errore commesso dalla maggior parte delle organizzazioni nello sviluppo di un modello di delega consiste nel disattivare o ridurre l'efficacia di questi ruoli incorporati. La modifica dei ruoli predefiniti può causare risultati imprevedibili; inoltre non vi sono garanzie che tali impostazioni vengano mantenute dalle revisioni dei Service Pack o dagli aggiornamenti dei prodotti. In più, questo tipo di modifica crea un ambiente non supportato al di fuori dell'organizzazione. Un approccio pratico consiste nell'utilizzare i gruppi e i ruoli incorporati ma limitarne l'appartenenza. A tal fine, sarà necessario probabilmente creare nuovi ruoli per gli amministratori che in precedenza utilizzavano l'appartenenza a gruppi come Domain Admins.
Tier4 Admins. Il gruppo Tier4 Admins dovrà comprendere amministratori dei servizi centralizzati che forniscono assistenza per tutti i servizi dell'organizzazione. Poiché questo è un ruolo creato, le autorizzazioni di accesso al servizio directory e al sistema possono essere adattate perfettamente alle esigenze specifiche dell'organizzazione. I membri di questo gruppo sono amministratori dei servizi, ma possono a volte eseguire anche attività di gestione dei dati a livello dell'insieme di strutture. Poiché vi sono molte classi di sistemi e aree diverse di responsabilità, i ruoli Tier4 sono suddivisi in vari sottogruppi nella directory. Ad esempio, è bene creare gruppi Tier4 separati per fornire la gestione separata di sistemi specifici, come i server Exchange. Questo gruppo serve anche da punto di escalation per gli amministratori dei dati.
Un motivo per cui spesso gli utenti vogliono appartenere al gruppo Domain Admins è per ottenere diritti amministrativi su ogni sistema in un dato dominio. Il sistema per mantenere questi amministratori di servizio in un contesto di privilegio minimo è assegnare a Tier4 Admins il controllo dei server dell'organizzazione senza renderli Domain Admins. Per evitare l'escalation dei privilegi, a Tier4 Admins non deve essere concessa l'appartenenza al gruppo BUILTIN\Administrators sui controller di dominio, dato che tale gruppo dispone di molti diritti sottostanti al servizio directory che non possono essere separati. Ad esempio, un membro del gruppo BUILTIN\Administrators di un dato dominio può gestire l'appartenenza al gruppo Domain Admins, consentendo ai membri un'escalation dei privilegi senza controlli e valutazioni.
Il rischio di ridurre l'efficacia delle autorizzazioni predefinite può essere ridotto rendendo i gruppi Tier4 membri nidificati dei gruppi di dominio incorporati, Server Operators e DNS Admins. Questo consente la gestione locale dei controller di dominio e allo stesso tempo limita la capacità di escalation dei privilegi da parte di Tier4 Admins. Per la maggior parte dei sistemi (ad eccezione di controller di dominio, server dei certificati e così via), il gruppo Tier4 Admins dovrà essere membro del gruppo Administrators locale. È possibile automatizzare l'appartenenza nidificata ai gruppi locali tramite la funzionalità Gruppi con restrizioni in Criteri di gruppo.

Amministratori dei dati
Esaminiamo ora i ruoli di amministrazione dei dati. Questi dovranno essere progettati con diritti cumulativi, ossia in modo che un gruppo Tier2 Admin abbia tutti i diritti di un gruppo Tier1 Admin con in più alcuni privilegi aggiuntivi, e così via. Per questo motivo analizzeremo questi gruppi a partire dal basso.
Tier1 Admins. Il gruppo Tier1 Admins deve fornire la gestione generale degli oggetti di directory creati in precedenza. Questo gruppo comprende gli amministratori meno esperti o chi effettua attività isolate, come la reimpostazione delle password. Concedere a questo gruppo i diritti necessari all'interno della propria unità organizzativa per modificare le proprietà degli account utente, reimpostare le password degli account utente, sbloccare gli account, attivare/disattivare gli account utente, aggiungere e azzerare gli account delle workstation e modificare l'appartenenza all'oggetto gruppo per i gruppi non amministrativi.
Tier2 Admins. Questo gruppo deve consentire la gestione e la creazione selettiva di oggetti, consentendo la creazione degli oggetti solo quando questi possono essere gestiti da Tier1 Admins. Ad esempio, i gruppi di protezione possono essere creati solo nell'unità organizzativa Gruppi. Tier2 Admins può aggiungere e modificare gli account Tier1 Admins; aggiungere, modificare ed eliminare gli account utente per un'unità organizzativa; eliminare gli oggetti Workstation; aggiungere, modificare ed eliminare gli oggetti Server, Contatto e Cartella condivisa.
Regional Admins. Questo gruppo dispone di diritti esclusivi sulla struttura dell'unità organizzativa locale. Pertanto, non può gestire altre strutture di unità organizzative regionali all'interno della directory. Gli account Regional Admin devono essere considerati altamente privilegiati e, di conseguenza, vengono memorizzati in una gerarchia di unità organizzative separata e gestiti dagli amministratori dei servizi Tier4 Admin. Regional Admins può creare la maggior parte degli oggetti senza restrizioni all'interno della struttura dell'unità organizzativa (con l'eccezione significativa della creazione di altre unità organizzative), il che comporta il rischio aggiuntivo di creare oggetti non gestibili dai livelli inferiori.
Tier3 Admins. Molte organizzazioni hanno un supporto tecnico centralizzato o di livello superiore. Questo ruolo completa l'elenco degli amministratori dei dati e fornisce un gruppo di amministratori dei dati per tutti i Regional Admins. I diritti non sono delegati specificamente a questi gruppi all'interno della directory; vengono invece assegnati attraverso l'appartenenza nidificata a ogni gruppo di Regional Admin. Questo fornisce un punto di escalation di livello superiore per tutti gli amministratori dei dati e un punto di ingresso per i problemi da trasferire ai gruppi di amministrazione dei servizi.

Sviluppare un modello di unità organizzativa e di gruppi di protezione
Una volta definiti i ruoli nell'organizzazione, è necessario definire un modello dell'unità organizzativa e dei gruppi di protezione. Vi sono due motivi principali per creare un'unità organizzativa in Active Directory: delegare i diritti e creare un punto a cui possono essere collegati gli oggetti Criteri di gruppo. Le unità organizzative definiscono un ambito di gestione all'interno della directory e possono essere utilizzate per limitare i diritti agli oggetti a vari livelli. Di conseguenza, il modo in cui si decide di delegare l'autorità dovrà essere uno dei fattori principali nella scelta di come implementare la struttura delle unità organizzative.
Tenendo presente questo fatto, sarà necessario creare un'unità organizzativa (o una serie di unità organizzative) di primo livello subito sotto il dominio che conterrà tutti gli oggetti. Questa unità organizzativa ha lo scopo specifico di definire l'ambito di gestione di massimo livello per Tier4 Admins. Creando un'unità amministrativa di primo livello, i diritti sul servizio directory possono iniziare esplicitamente a livello dell'unità amministrativa piuttosto che a livello di dominio. La delega da un'unità organizzativa di primo livello invece che dal dominio riduce il rischio che gli utenti possano effettuare un'escalation dei privilegi manipolando i gruppi di dominio incorporati come osservato in precedenza.
Sotto alle unità organizzative di primo livello si dovranno creare gerarchie separate di unità organizzative secondarie che rappresentino ogni regione o unità aziendale dotata di un team di amministrazione dei dati separato. Ogni unità organizzativa secondaria regionale dovrà avere una gerarchia di unità organizzative comune non estensibile per la gestione degli oggetti di directory. L'uniformità è essenziale per la gestione continuativa, dato che gran parte della delega dei diritti verrà automatizzata. Questo non è un compito facile, dato che ogni regione potrebbe volere unità organizzative specifiche. Ma gli amministratori IT devono tenere duro; se un'estensione è necessaria per una regione, la struttura dell'unità organizzativa secondaria dovrà essere estesa per tutte le regioni. Questo può sembrare difficile all'inizio, ma se l'organizzazione offre un alloggiamento generico per gli oggetti, col tempo le situazioni anomale tendono a risolversi.
Infine, creare gruppi e account di amministrazione secondari separati per rimuovere la possibilità di escalation dei privilegi degli amministratori: un gruppo Tier1 Admins, uno Tier2 Admins e uno Regional Admins per ogni gerarchia di unità organizzative secondarie. Collocando questi account in unità organizzative separate è possibile limitarne l'amministrazione al proprio livello e ai livelli inferiori. In questo modo, se tutti gli account Tier1 Admins e il gruppo di protezione associato risiedono in un'unità organizzativa in cui non hanno diritti, gli amministratori non saranno in grado di impadronirsi di altri account amministrativi o aumentare i privilegi di altri amministratori portandoli al proprio livello. Qualunque membro del gruppo Domain Admins, ad esempio, può fare di qualsiasi altro account utente nel dominio un Domain Admin. Tuttavia, adottando questo modello di unità organizzative si riduce tale rischio. La Figura 2 mostra un esempio di struttura di unità organizzative con i gruppi di protezione associati.
Figura 2 Struttura di unità organizzative e gruppi di protezione associati
Figura 2 Struttura di unità organizzative e gruppi di protezione associati

Definire gli account secondari
L'elemento chiave per il successo di un modello di delega è l'applicazione del principio di privilegio minimo. In pratica questo significa che un'entità di protezione deve avere solo la capacità di eseguire le attività richieste per il ruolo assegnato e niente di più. Purtroppo molti amministratori IT utilizzano la stessa entità di protezione per l'amministrazione di directory e per le attività quotidiane come l'esplorazione del Web e la lettura della posta elettronica. La creazione di account separati riduce la probabilità che un amministratore nel sistema a più livelli danneggi il servizio directory per errore o sia vittima di un attacco effettuato attraverso applicazioni di uso quotidiano ma diretto all'amministratore della directory.
Per fare ciò senza che l'utente debba disconnettersi ed eseguire nuovamente l'accesso, si usa il servizio Accesso secondario (Runas.exe). Questo consente agli utenti di aumentare i propri privilegi fornendo un insieme di credenziali diverse durante l'esecuzione di script o eseguibili su server e workstation.
Anche se il concetto di utilizzare account con privilegi minimi è in sé abbastanza semplice, le organizzazioni a volte trovano difficile applicarlo, perché le vecchie abitudini informatiche possono essere difficili da cambiare. Un modo semplice per impedire l'uso degli account privilegiati per le attività quotidiane è non fornire a tali account accesso alla posta in Exchange Server, implementando questo approccio tramite un criterio amministrativo all'interno dell'organizzazione. Questo approccio relativamente semplice riduce notevolmente la probabilità che tali account vengano utilizzati per le attività non amministrative di routine.

Delegare i diritti.
Il passaggio finale nello sviluppo di un modello di delega è l'effettiva delega dei diritti all'interno di Active Directory. Questo comporta la manipolazione delle voci di controllo di accesso (ACE) e degli elenchi di controllo degli accessi (ACL) sui dati memorizzati nella directory. Gli ACL nei contenitori Active Directory definiscono quali oggetti possono essere creati e come verranno gestiti. La delega dei diritti comporta operazioni di base sugli oggetti, come la capacità di visualizzare un oggetto, creare un oggetto figlio di una classe specificata o leggere le informazioni su attributi e protezione in relazioni agli oggetti di una classe specificata. Oltre a queste operazioni di base, Active Directory definisce autorizzazioni estese, che consentono operazioni quali Invia come e Gestione topologia di replica.
Ai punti precedenti sono è stata esaminata la creazione di gruppi di protezione corrispondenti a ruoli organizzativi definiti. Questo significa che per ogni ruolo esiste un gruppo di protezione associato in base alla struttura di unità organizzativa secondaria. Per implementare il modello di delega, a questi gruppi devono essere assegnate autorizzazioni sugli oggetti della directory. A questo punto del processo, non è il caso di partire da zero e creare un ambiente altamente personalizzato. È invece meglio sfruttare ovunque possibile i gruppi e i diritti incorporati. Se, ad esempio, un determinato ruolo deve poter gestire i record DNS per l'insieme di strutture, non si cerchi di delegare diritti su contenitori e contesti di denominazione correlati al DNS integrato di Active Directory; sarà sufficiente utilizzare il gruppo BUILTIN\DNS Admins del dominio. In più, diritti utente e altre autorizzazioni possono essere estesi attraverso Criteri di gruppo per fornire le autorizzazioni aggiuntive necessarie a un dato ruolo per gestire una classe specifica del sistema.
Durante l'assegnazione di autorizzazioni mediante la delega, è necessario limitare o eliminare completamente l'uso di ACE di negazione all'interno della directory, che possono creare difficoltà al momento di individuare e risolvere i problemi. Un approccio migliore consiste nell'utilizzare ACE di autorizzazione espliciti per concedere autorizzazioni ai gruppi personalizzati che rappresentano i ruoli definiti. Tenere presente che i ruoli definiti dall'utente, come Tier4 Admins, hanno solo i diritti espliciti definiti dal ruolo stesso.
L'ereditarietà è fondamentale per la protezione di Active Directory e definisce il modo in cui un determinato ACL si applica agli oggetti figli in un dato contenitore principale o secondario. È importante essere sempre specifici nel definire l'ambito dell'ereditarietà, assicurandosi che gli ACE ereditabili siano applicati il più vicino possibile agli oggetti di destinazione. Le autorizzazioni di negazione ereditabili applicate all'oggetto padre avranno la precedenza su eventuali autorizzazioni di negazioni ereditabili applicati all'oggetto padre del padre, uno dei motivi principali per cui si sconsiglia l'uso di ACE di negazione per la delega pratica. Inoltre, le autorizzazioni ereditabili non possono ignorare un ACE esplicito su un oggetto. Per questo motivo si consiglia di limitare o eliminare la capacità degli amministratori nel sistema a livelli di modificare l'elenco di controllo di accesso discrezionale (DACL) sugli oggetti di directory, rimuovendo il privilegio di scrittura del DACL. (Si noti che il creatore dell'oggetto dispone implicitamente di questi diritti). La regola generale è che se un amministratore ha la capacità di modificare il DACL su un oggetto, probabilmente lo farà. Sarebbe un peccato se tutto il lavoro dell'organizzazione per implementare il modello di delega andasse sprecato con l'introduzione di elementi di scelta e potenziali errori amministrativi.
Per implementare correttamente un modello di delega in Active Directory sarà necessario utilizzare vari strumenti. Per la maggior parte delle grandi organizzazioni, utilizzare la procedura guidata di impostazione deleghe per assegnare le autorizzazioni nella directory rappresenta un compito enorme che offre molte possibilità di errori amministrativi. Invece si dovrà sempre utilizzare l'automazione per garantire che il modello di delega sia ben documentato, che sia supportabile e che fornisca un'opzione di ripristino nel caso in cui le impostazioni vengano in qualche modo perdute o modificate involontariamente.
Lo strumento principale necessario per implementare la delega è DSACLS.EXE, uno strumento da riga di comando utilizzato per manipolare gli ACL del servizio directory sugli oggetti. Questo strumento consente anche di specificare sull'oggetto padre i flag di eredità per un DACL. (I flag di eredità includono questo oggetto e i relativi oggetti secondari, solo gli oggetti secondari e distribuiscono le autorizzazioni ereditabili per un solo livello. I comandi DSACLS produrranno prima o poi errori se un flag di eredità è impostato in modo scorretto, quindi il testing è indispensabile quando si usa questo strumento. Ecco un esempio della sintassi di DSACLS per delegare la capacità di creare oggetti computer nell'unità organizzativa di destinazione di esempio:
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
DSACLS distingue tra maiuscole e minuscole in relazione ai tipi di oggetto. Questo significa che non sarà possibile delegare le autorizzazioni per la classe di oggetti "cn=Computer" su "cn=computer" (vedere la Figura 3).
Figura 3 Errore dovuto alla differenza tra maiuscole e minuscole
Figura 3 Errore dovuto alla differenza tra maiuscole e minuscole (Fare clic sull'immagine per ridurla)
Figura 3 Errore dovuto alla differenza tra maiuscole e minuscole
Figura 3 Errore dovuto alla differenza tra maiuscole e minuscole (Fare clic sull'immagine per ingrandirla)
Per creare alcuni oggetti è necessaria una serie specifica di diritti. Questo dipende dalla differenza tra gli attributi "must-contain" e "may-contain" degli oggetti. La metafora migliore per spiegare questo concetto è quella dell'hamburger. Per essere considerato tale, un hamburger deve contenere una polpetta di carne e un panino. Questi sono gli attributi "must-contain" della classe di oggetti hamburger. Le altre cose, come sottaceti, ketchup, lattuga e così via, sono attributi "may-contain". Se si estende la classe di oggetti in modo da definire un cheeseburger, si dovrà aggiungere il formaggio all'elenco degli attributi "must-contain".
Gli oggetti utente funzionano allo stesso modo. Si supponga di seguire questo modello per creare oggetti utente utilizzando la seguente sintassi di DSACLS:
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
L'amministratore incontrerebbe vari errori durante la creazione dell'oggetto utente. È necessario assegnare i privilegi necessari per impostare gli attributi richiesti sull'oggetto utente, compresa l'impostazione della password. Questo è descritto nella seguente sintassi di DSACLS aggiuntiva.
Per prima cosa, assegnare i privilegi di scrittura degli attributi "deve contenere" assegnando Lettura generica/Scrittura generica a tutti gli attributi della classe utente:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
Quindi assegnare il diritto esteso di modificare la password:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
Infine assegnare il privilegio di lettura e scrittura proprietà dell'attributo Ultima impostazione password:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
Una volta delegati i diritti appropriati, i ruoli definiti saranno limitati alla sola gestione delle classi di oggetti definite nel DACL del contenitore. Utilizzando l'esempio di oggetto computer precedente, il menu contestuale in Utenti e computer di Active Directory limita l'elenco di nuovi oggetti che possono essere creati dall'utente a cui sono delegati tali diritti: vedere l'elenco limitato nella Figura 4.
Figura 4 Elenco limitato di oggetti nuovi
Figura 4 Elenco limitato di oggetti nuovi
DSACLS può anche essere automatizzato per fornire una distribuzione complessa dei diritti. Ecco alcuni comandi di DSACLS che possono essere utilizzati per delegare i diritti a manipolare attributi degli indirizzi comuni sugli oggetti utente di un determinato contenitore:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
Esempi di questo tipo sono comuni nella maggior parte dei modelli di delega e possono essere utilizzati insieme ai ruoli definiti in precedenza.
Un altro strumento utilizzato per l'implementazione della delega è DSREVOKE.EXE, che consente agli amministratori di individuare e rimuovere diritti delegati per specifiche entità di protezione su oggetti nella directory. Questo strumento può essere molto utile, ma si applica a una specifica entità di protezione e non valuta l'appartenenza nidificata all'interno dei gruppi di protezione.
Oltre a questi strumenti della riga di comando, si consiglia di utilizzare anche Assegnazione diritti utente e Gruppi con restrizioni con i Criteri di gruppo. Come si è visto in precedenza, Assegnazione diritti utente consente agli amministratori IT di estendere o rimuovere diritti di basso livello, come il diritto ad accedere e riavviare un sistema in modalità remota, per vari gruppi di utenti su sistemi di destinazione specifici. I Gruppi con restrizioni possono essere utilizzati per specificare e applicare l'appartenenza a gruppi locali e di dominio nell'insieme di strutture. Insieme, questi strumenti forniscono tutto il necessario per automatizzare e implementare un modello di delega in Active Directory.

Riepilogo
Anche se il compito di sviluppare un modello di delega in Active Directory può sembrare complesso, in realtà modelli molto semplici possono essere applicati alla maggior parte delle infrastrutture IT. Una delle fasi più importanti nella distribuzione di un modello di delega pratico è la definizione di ruoli chiari. È bene limitarsi a definire un numero ristretto e gestibile di ruoli. Si tratta di un equilibrio delicato: se ci sono troppi ruoli, alcuni non verranno utilizzati, mentre se ce ne sono troppo pochi non sarà possibile mantenere la separazione dei ruoli.
Durante la definizione delle attività, ricordarsi di suddividerle in base alla frequenza, all'importanza e alla difficoltà. Una volta definiti i ruoli, sviluppare una serie di casi d'uso per identificare più facilmente ciò che ogni ruolo può o non può fare e automatizzare il processo di testing. I casi d'uso adeguatamente preparati aiuteranno a spiegare i ruoli agli interessati nell'organizzazione e a ridurre le sorprese causate da errori di automazione.
Infine, è sempre bene adottare un approccio pratico nello sviluppare un modello di delega. Semplicità significa facilità di supporto, e un modello di delega sostenibile ripagherà abbondantemente il lavoro necessario facilitando il controllo dei diritti amministrativi all'interno dell'ambiente Active Directory.
Ulteriori riferimenti
  • Design Considerations for Delegation of Administration in Active Directory (in inglese)
  • Best Practices for Delegating Active Directory Administration (in inglese)

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.
Rob Campbell è uno specialista tecnico 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.


 Amministrazione di Windows: I nuovi modelli di Criteri di gruppo in Windows Vista
Amministrazione di Windows Darren Mar-Elia

I nuovi modelli di Criteri di gruppo in Windows Vista
Panoramica:
  • ADMX
  • Modifica dei file ADMX
  • Differenze tra i file ADM e ADMX
  • Creazione di un archivio centrale

Prima di Windows Vista, i valori del Registro di sistema che potevano essere impostati all'interno di Criteri di gruppo erano determinati dai file ADM, la cui sintassi era criptica e proprietaria. Se si volevano controllare altri valori del Registro di sistema oltre a quelli inclusi da Microsoft con i file ADM standard, era necessario imparare questa
sintassi e creare un file ADM personalizzato. Inoltre, questi file ADM erano memorizzati con ciascun oggetto Criteri di gruppo nell'ambiente Active Directory®, e ognuno di questi oggetti Criteri di gruppo con i relativi file ADM veniva replicato su tutti i controller del dominio nel dominio.
Con il rilascio di Windows Vista™, Microsoft fa un importante passo avanti nell'area dei modelli di Registro di sistema basati su Criteri di gruppo. Windows Vista introduce cambiamenti significativi sia nel formato del file ADM, ora chiamato ADMX, che nel modo in cui questi file vengono memorizzati. In questo articolo esaminerò il nuovo formato ADMX e tratterò il modo in cui questi file differiscono da ADM. Inoltre descriverò come viene gestita la memorizzazione di questi file in un ambiente Windows Vista.

Le differenze di ADMX
La differenza principale tra il nuovo formato di file ADMX e il vecchio formato ADM esistente fin da Windows NT® 4.0 è che ADMX ha adottato lo standard XML per descrivere le impostazioni dei criteri del Registro di sistema. Questo presenta diversi vantaggi. Il primo è che ci sono molti più strumenti per la modifica di XML che per la sintassi ADM. Il secondo è che, poiché XML è schematizzato, col tempo diventerà più facile creare strumenti per aiutare gli utenti a conoscere i tag giusti da mettere nei posti giusti per creare un file ADMX ben formattato. "Schematizzato" significa che per una data applicazione XML, come il formato ADMX, c'è uno schema documentato che descrive gli elementi e gli attributi possibili e come sono organizzati. Più avanti in questo articolo vedremo un esempio.
L'altra differenza importante tra ADMX e ADM è la separazione della sezione [strings] (stringhe) del file ADMX principale in un file ADML specifico per la lingua in uso. Chi conosce i file ADM saprà che alla fine di ogni file compariva una sezione delimitata da un tag "[strings]", in cui si potevano assegnare valori alle stringhe di testo che sarebbero state visualizzate durante l'uso dell'Editor criteri di gruppo e dei modelli amministrativi. Ad esempio, il testo che compariva facendo clic sulla scheda Descrizione di un dato criterio era memorizzato nella sezione [strings]. Il problema di questo sistema è che le stringhe venivano memorizzate nel file ADM, quindi se si voleva utilizzare quell'ADM in un sistema Windows® in una lingua diversa era necessario creare un nuovo file ADM con una sezione [strings] per la nuova lingua.
Le cose diventavano ancora più complicate se, per esempio, un utente con una versione francese di Windows voleva modificare un oggetto Criteri di gruppo esistente che utilizzava ADM inglesi. L'amministratore francese avrebbe visto solo testo inglese nell'Editor criteri di gruppo. Windows Vista risolve questo problema separando la sezione [strings] in un file ADM basato su XML (o ADM Language). Il file ADML può essere distribuito in qualsiasi lingua supportata e può essere facilmente cambiato per supportare qualsiasi nuova lingua senza dover toccare il file ADMX principale che contiene i criteri. Cosa ancora più importante, quando l'amministratore francese di prima modifica un oggetto Criteri di gruppo dalla sua workstation Windows Vista, l'Editor criteri di gruppo rileva che è in uso la versione francese di Windows e carica automaticamente i file ADML francesi per quell'oggetto Criterio di gruppo.
Tutti i file ADMX e ADML forniti con l'installazione di Windows Vista sono contenuti nella cartella c:\windows\policydefinitions (vedere Figura 1).
Figura 1 File ADMX in Windows Vista
Figura 1 File ADMX in Windows Vista (Fare clic sull'immagine per ridurla)
Figura 1 File ADMX in Windows Vista
Figura 1 File ADMX in Windows Vista (Fare clic sull'immagine per ingrandirla)
Si noti che all'inizio dell'elenco dei file nella Figura 1 compare una cartella chiamata en-us. Questa è la cartella specifica per la lingua che contiene i file ADML per i file ADMX contenuti in questa cartella PolicyDefinitions, in questo caso per l'inglese americano. È disponibile un file ADML per ogni ADMX. Al momento della pubblicazione di questo articolo, Windows Vista contiene, per impostazione predefinita, 132 file ADMX/ADML. Questa è un'altra grande differenza tra Windows Vista e le versioni precedenti: Gli oggetti Criteri di gruppo creati in Windows XP contenevano normalmente cinque file ADM, di cui il più grande era System.adm, che conteneva le voci dei criteri per la maggior parte dei componenti di Windows controllati dai criteri. In Windows Vista, Microsoft ha deciso di suddividere i file ADMX per funzione: per questo i file ADMX sono molto più numerosi. Ogni ADMX normalmente si riferisce a un singolo componente di Windows, come Pannello di controllo, client DNS, Esplora risorse e così via.

ADMX
Il fatto che i file ADMX siano scritti in XML è un notevole miglioramento, come ho accennato sopra. Tuttavia, molti amministratori non sanno scrivere XML, tantomeno comprendono lo schema utilizzato da ADMX per creare estensioni dei criteri. Un'esercitazione sulla creazione di file ADMX personalizzati va al di là dell'ambito di questo articolo; possiamo tuttavia esaminare la composizione dei file ADMX.
Un file ADMX o ADML può essere aperto in qualsiasi editor di testo, anche il Blocco note, ma se l'editor non riconosce la sintassi XML il risultato potrebbe non essere molto comprensibile. Io utilizzo Visual Studio® perché la relativa funzionalità IntelliSense® aiuta a completare determinati elementi. La Figura 2 mostra le prime righe di uno dei file ADMX forniti con Windows Vista.
Figure 2 XML in un file ADMX (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
L'aspetto di questo file può sembrare strano se non si è abituati a XML, ma molti di questi elementi XML compaiono in qualsiasi file ADMX. L'elemento policyNamespaces, ad esempio, identifica in modo univoco questo file ADMX nell'universo di tutti i file ADMX.
Chi ha creato file ADM personalizzati in versioni precedenti di Windows saprà che c'era una serie di tag, come Category, Policy, ListBox e ActionList, utilizzati per definire le impostazioni dei criteri che sarebbero comparse nell'Editor criteri di gruppo. Molti di questi tag sono rimasti invariati, o sono cambiati solo leggermente nel formato ADMX, ma hanno un aspetto molto diverso perché sono rappresentati in formato XML. Ad esempio, io avevo scritto un file ADM personalizzato che consentiva vari tipi di registrazione di eventi in Windows per la risoluzione dei problemi in Criteri di gruppo. Una sezione di tale ADM personalizzato è illustrata nella Figura 3. Ho trasferito questo file nel nuovo formato ADMX, come illustrato nella Figura 4.
Figure 4 File ADM convertito in un file ADMX (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 Un file ADM personalizzato (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
Sotto molti aspetti, questo frammento di ADMX è molto più facile da comprendere del suo parente ADM, dato che è più conciso. L'elemento criterio specifica la funzione di questo criterio (registrazione reindirizzamento cartelle). Gli attributi preceduti da $(string. sono riferimenti all'elemento stringa del file ADML corrispondente. Gli attributi chiave e nome del valore specificano, naturalmente, la chiave e il valore del Registro di sistema a cui si applica questo criterio. L'elemento parentCategory controlla la posizione in cui compare questo criterio nella gerarchia dei modelli amministrativi dell'Editor criteri di gruppo. L'elemento supportedOn indica quale versione del sistema operativo rispetta questo criterio; infine, gli elementi enabledvalue e disabledvalue specificano i valori inseriti nel Registro di sistema quando questo criterio è impostato rispettivamente su attivato e su disattivato.
Questo è un criterio piuttosto semplice, che può essere solo attivato o disattivato. Come nella sintassi ADM, è possibile creare elementi di interfaccia utente più complessi nell'Editor criteri di gruppo. In ADMX, questa operazione rende la sintassi un po' più complicata e comprende un attributo di presentazione che fa riferimento a una parte del file ADML in cui sono riportate le etichette di testo dell'elemento dell'interfaccia utente. Ma al di là di questo, la sintassi ADMX in realtà non è molto più complessa. È da tenere presente che alcuni nomi dei tag sono cambiati da ADM ad ADMX. Ad esempio, in ADM c'erano i tag "edittext" e "listbox". In ADMX, questi tag sono chiamati "text" e "list" all'interno del file ADMX. A tali elementi corrisponderanno voci nel file ADML che specificano il testo ad essi associato.
Come forse si saprà già, un amministratore può caricare un file ADM personalizzato nell'Editor oggetti Criteri di gruppo di Windows Vista. Spesso mi viene chiesto se Microsoft fornirà un'utilità per convertire i file ADM personalizzati in sintassi ADMX. La risposta è che Microsoft ha collaborato con FullArmor Corp. per rilasciare uno strumento gratuito chiamato ADMX Migrator. Questo strumento fa due cose. Innanzitutto converte i vecchi file ADM personalizzati in formato ADMX (vedere la Figura 5 per un esempio dell'uso dello strumento per la conversione del mio file personalizzato gpolog.adm).
Figura 5 ADMX Migrator
Figura 5 ADMX Migrator (Fare clic sull'immagine per ridurla)
Figura 5 ADMX Migrator
Figura 5 ADMX Migrator (Fare clic sull'immagine per ingrandirla)
In secondo luogo fornisce un editor ADMX che consente di creare nuovi file ADMX da zero. Questo strumento può essere scaricato da go.microsoft.com/fwlink/?LinkID=77409.

Memorizzazione di ADMX
L'altro notevole cambiamento di cui voglio parlare è il modo in cui i file ADMX e ADML vengono memorizzati per l'uso. Nelle versioni di Windows precedenti a Windows Vista, quando si modificava un nuovo oggetto Criteri di gruppo, i file ADM venivano copiati automaticamente dalla workstation locale in cui si effettuavano le modifiche alla parte SYSVOL dell'oggetto Criteri di gruppo su un controller di dominio nel dominio Active Directory dell'utente. Questi ADM venivano poi replicati su ogni controller di dominio, per ogni oggetto Criteri di gruppo creato. In questo modo veniva utilizzata molta larghezza di banda e spazio su disco, specialmente nei grandi ambienti con dozzine o centinaia di oggetti Criteri di gruppo. Windows Vista capovolge questo processo. Per impostazione predefinita, quando si crea un oggetto Criteri di gruppo basato su Active Directory da una workstation Windows Vista, i criteri dei modelli amministrativi che vengono visualizzati nell'Editor criteri di gruppo vengono caricati dalla cartella c:\windows\policydefinitions nel computer da cui si sta modificando l'oggetto Criteri di gruppo.
I file ADMX e ADML non vengono copiati su SYSVOL, vi viene solo fatto riferimento localmente. Si elimina così il carico di memoria e di rete creato dai file ADM nell'ambiente dei Criteri di gruppo. Ma il meglio deve ancora arrivare. Windows Vista supporta anche un archivio centrale, un contenitore per i modelli amministrativi. Questo risolve il problema di controllare in modo efficace i file ADMX utilizzati per modificare gli oggetti Criteri di gruppo, indipendentemente da chi li modifica. Per fare ciò è necessario copiare tutti i file ADMX e ADML ufficiali, insieme agli eventuali file personalizzati, in un percorso di rete; dopodiché tutte le modifiche successive a Criteri di gruppo da workstation Windows Vista faranno riferimento a queste versioni in rete invece che a ognuna delle proprie versioni locali separate. Impostare un archivio centrale è un compito facile e da eseguire una sola volta per ogni dominio. Sarà sufficiente seguire le istruzioni in "Creazione di un archivio centrale".

Riepilogo
Il nuovo formato ADMX in Windows Vista è un netto miglioramento rispetto ai file ADM utilizzati nelle versioni precedenti del sistema operativo. L'uso di XML fornisce una struttura più chiara per la modifica e la ricerca in questi file. Lo spostamento delle stringhe specifiche per una lingua in file separati rende trasparente la modifica dei Criteri di gruppo in più lingue, mentre l'archivio centrale elimina la necessità di memorizzare e aggiornare tutti gli oggetti Criteri di gruppo con le copie dei file ADM. Per tutti questi motivi, informarsi su ADMX è un'ottima idea.
Creazione di un archivio centrale
Creare un archivio centrale è abbastanza semplice. Seguire questa procedura per crearne uno nel dominio Active Directory in uso:
Passaggio 1: Aprire Esplora risorse e passare alla condivisione SYSVOL sul controller di dominio emulatore PDC nell'ambiente in uso (si può usare qualsiasi controller di dominio, ma normalmente le modifiche ai Criteri di gruppo sono concentrate sul proprietario del ruolo PDC).
Passaggio 2: Spostarsi nella cartella Criteri sotto SYSVOL e creare una nuova cartella chiamata PolicyDefinitions.
Passaggio 3: Copiare il contenuto della cartella C:\windows\policydefinitions della workstation Windows Vista in uso nella nuova cartella PolicyDefinitions, che include la cartella ADML per la lingua in uso (ad esempio en-us nei computer che usano l'inglese americano).
Una volta copiati i file ADMX e ADML nella cartella dell'archivio centrale, l'Editor oggetti Criteri di gruppo di Windows Vista inizierà a fare riferimento ai file presenti in questa cartella, ignorando quelli memorizzati localmente.

Darren Mar-Elia è un MVP per i Criteri di gruppo Microsoft, creatore del sito Criteri di gruppo (www.gpoguy.com, in inglese) e coautore di Microsoft Windows Group Policy Guide (Microsoft Press, 2005). È anche direttore tecnico e fondatore di SDM Software, Inc. Può essere contattato all'indirizzo Darren@gpoguy.com.


 Amministrazione di Windows: Guida alla risoluzione dei problemi di Criteri di gruppo
Amministrazione di Windows Derek Melber

Guida alla risoluzione dei problemi di Criteri di gruppo
Panoramica:
  • Problemi comuni degli Oggetti Criteri di gruppo
  • Regole di Criteri di gruppo
  • Risoluzione dei problemi degli Oggetti Criteri di gruppo
  • Strumenti per la risoluzione dei problemi

Microsoft Active Directory è diventato un componente fondamentale di molte infrastrutture IT. Una delle funzionalità più importanti di Active Directory è Criteri di gruppo, che consente agli amministratori di centralizzare la gestione di controller di dominio, server membri e desktop.
Nonostante Criteri di gruppo fornisca chiaramente molti vantaggi, presenta un piccolo problema. La sua progettazione e implementazione all'interno di una grande organizzazione può risultare complicato. Ancora più problematico può apparire la risoluzione dei problemi quando qualcosa va storto. In questo articolo, esaminerò la struttura di Criteri di gruppo e mostrerò come risolverne i problemi. Alla fine, avrete tutto il necessario per affrontare praticamente qualunque problema di Criteri di gruppo.

Impostazioni problematiche
Ci sono molte parti mobili in Criteri di gruppo, soprattutto in relazione al modo in cui si interfaccia con la progettazione e l'implementazione complessiva di Active Directory®. Durante la risoluzione di problemi di vario genere relativi all'accesso e alla rete, la ricerca di una soluzione dovrebbe includere sempre Active Directory e gli elementi essenziali dell'implementazione di Criteri di gruppo. Per iniziare il processo di risoluzione dei problemi, osserviamo le impostazioni di Criteri di gruppo che possono essere configurate in modo non corretto, per poi passare ad argomenti più complessi che potrebbero causare il malfunzionamento di Criteri di gruppo.
Le impostazioni di Criteri di gruppo vengono consultate dagli amministratori di Active Directory utilizzando i file modello amministrativo (file ADM o ADMX) e l'Editor oggetti Criteri di gruppo, o GPEdit (avviato eseguendo gpedit.msc). Utilizzando GPEdit, l'amministratore crea i file Oggetto Criteri di Gruppo, o GPO. Gli Oggetti Criteri di gruppo sono configurati in modo da poter essere applicati (o meno) ai computer e agli utenti entro la struttura di Active Directory. Ci sono numerose regole che gli oggetti Criteri di gruppo devono seguire per funzionare correttamente. Vediamo quali sono.
Un Oggetto Criteri di gruppo deve essere collegato Quando viene creato un nuovo Oggetto Criteri di gruppo, può non essere collegato a qualunque nodo in Active Directory. Anche se l'Oggetto Criteri di gruppo può essere modificato e cambiato, non influirà su altri oggetti finché non viene collegato a un nodo. Per assicurarsi che l'Oggetto Criteri di gruppo sia collegato correttamente, osservare la finestra di informazioni nella console Gestione criteri di gruppo (GPMC) mostrata nella Figura 1.
Figura 1 I collegamenti dell'Oggetto Criteri di gruppo sono mostrati chiaramente
Figura 1 I collegamenti dell'Oggetto Criteri di gruppo sono mostrati chiaramente (Fare clic sull'immagine per ridurla)
Figura 1 I collegamenti dell'Oggetto Criteri di gruppo sono mostrati chiaramente
Figura 1 I collegamenti dell'Oggetto Criteri di gruppo sono mostrati chiaramente (Fare clic sull'immagine per ingrandirla)
L'Oggetto Criteri di gruppo deve avere come destinazione l'oggetto giusto Come è noto, Criteri di gruppo deve avere come destinazione gli oggetti corretti in Active Directory. Tuttavia, questo requisito a volte viene trascurato durante la risoluzione dei problemi. In un Oggetto Criteri di gruppo, ci sono due categorie principali: computer e utente. Quando si configura un Oggetto Criteri di gruppo, accertarsi di annotare se è per un oggetto computer o utente. Quindi, è possibile verificare che i tipi di oggetto corretti siano collocati nell'Unità Organizzativa (UO) dove è collegato l'Oggetto Criteri di gruppo.
Gli Oggetti Criteri di gruppo non si applicano ai gruppi Sebbene si possa desiderare che sia così, un Oggetto Criteri di gruppo non può essere applicato a un oggetto gruppo di protezione di Active Directory. Gli unici due oggetti configurabili mediante un'impostazione di Oggetto Criteri di gruppo sono computer e utenti. Gli Oggetti Criteri di gruppo non possono configurare oggetti mediante l'appartenenza al gruppo. Per esempio, se c'è un Oggetto Criteri di gruppo collegato all'unità organizzativa Finance, come mostrato nella Figura 2, i soli oggetti che saranno influenzati dall'impostazione sono Derek e Frank. Le impostazioni nell'Oggetto Criteri di gruppo non interesseranno i membri del gruppo Marketing, a prescindere da chi appartiene a tale gruppo.
Figura 2 Unità organizzativa Finance e oggetti al suo interno
Figura 2 Unità organizzativa Finance e oggetti al suo interno (Fare clic sull'immagine per ridurla)
Figura 2 Unità organizzativa Finance e oggetti al suo interno
Figura 2 Unità organizzativa Finance e oggetti al suo interno (Fare clic sull'immagine per ingrandirla)
L'oggetto di destinazione deve essere nel percorso dell'Oggetto Criteri di gruppo Quando si nota che un'impostazione di Oggetto Criteri di gruppo non influisce come dovrebbe su un oggetto, c'è un'impostazione più importante: l'oggetto deve trovarsi nell'ambito di gestione (SOM, Scope of Management) dell'Oggetto Criteri di gruppo. Questo significa che l'oggetto deve trovarsi sotto il nodo dove l'Oggetto Criteri di gruppo è collegato (anche un nodo figlio sarà sufficiente). Per esempio, nessuno degli oggetti nell'unità organizzativa Marketing sarà interessato da un Oggetto Criteri di gruppo che è collegato all'unità organizzativa Finance, come mostrato nella Figura 3. L'ambito di gestione di un Oggetto Criteri di gruppo parte dal nodo dove è collegato e procede attraverso la struttura di Active Directory.
Figura 3 Quando ci sono unità organizzative allo stesso livello, gli Oggetti Criteri di gruppo si applicano soltanto all'unità organizzativa a cui sono collegati
Figura 3 Quando ci sono unità organizzative allo stesso livello, gli Oggetti Criteri di gruppo si applicano soltanto all'unità organizzativa a cui sono collegati (Fare clic sull'immagine per ridurla)
Figura 3 Quando ci sono unità organizzative allo stesso livello, gli Oggetti Criteri di gruppo si applicano soltanto all'unità organizzativa a cui sono collegati
Figura 3 Quando ci sono unità organizzative allo stesso livello, gli Oggetti Criteri di gruppo si applicano soltanto all'unità organizzativa a cui sono collegati (Fare clic sull'immagine per ingrandirla)
L'Oggetto Criteri di gruppo deve essere attivato Quando viene creato un Oggetto Criteri di gruppo, non è configurato per apportare alcuna modifica agli oggetti di destinazione. Tuttavia, è attivato per entrambe le porzioni, computer e utente. Se una di queste porzioni è disattivata, può essere difficile accorgersene. Quindi, durante l'esecuzione della risoluzione dei problemi di un Oggetto Criteri di gruppo che non si applica, è consigliabile verificare se l'Oggetto Criteri di gruppo è disattivato in parte o del tutto. A tale scopo, consultare Oggetti Criteri di Gruppo | Criteri di account nella GPMC e controllare lo stato dell'Oggetto Criteri di gruppo.
Alcune impostazioni richiedono un riavvio Quando l'impostazione di un Oggetto Criteri di gruppo non funziona correttamente, potrebbe essere dovuto all'elaborazione inerente degli Oggetti Criteri di gruppo. Se l'aggiornamento periodico in background degli Oggetti Criteri di gruppo è attivato, è possibile elaborare soltanto alcune delle impostazioni dell'Oggetto Criteri di gruppo, ma non tutte. Nonostante sia stata creata un'impostazione, potrebbe non aver avuto ancora effetto. Ci sono alcune impostazioni categorizzate come Criteri di primo piano, e vengono applicate soltanto al riavvio del computer o quando l'utente si scollega e si ricollega. Tra gli esempi di impostazioni con questo comportamento ci sono le installazioni di software, il reindirizzamento di cartelle e l'applicazione di script.

Applicazione sincrona e asincrona delle impostazioni
All'interno di un Oggetto Criteri di gruppo è possibile configurare in che modo vengono applicati i criteri all'avvio e all'accesso. Le modifiche che è possibile apportare forniscono accesso immediato al desktop, mentre i criteri sono ancora in fase di applicazione, o garantiscono che tutti i criteri vengano applicati prima che l'utente acceda al desktop. La Figura 4 mostra il comportamento predefinito di ciascun sistema operativo. Se si desidera alterare questo comportamento, è possibile modificare l'impostazione di criterio seguente:
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 Elaborazione predefinita sul client (Close Figure 4)

Sistema operativo | Avvio | Accesso | Aggiornamento criteri
Windows 2000 | Sincrono | Sincrono | Asincrono
Windows XP Professional | Asincrono | Asincrono | Asincrono
Windows Server 2003 | Sincrono | Sincrono | Asincrono
La maggior parte degli amministratori preferisce avere un'applicazione sincrona dei criteri, per assicurare che tutti i criteri siano applicati prima che l'utente possa accedere al desktop. In questo modo si assicura che tutte le impostazioni di protezione e configurazione siano applicate prima che l'utente possa svolgere qualunque operazione. Notare che questo non è lo stato predefinito in Windows® XP Professional, che è stato ottimizzato per migliorare la velocità di accesso.

Alterazione dell'ereditarietà predefinita
Ci sono quattro metodi diversi che si possono utilizzare per alterare l'ereditarietà predefinita dell'elaborazione degli Oggetti Criteri di gruppo. Queste opzioni sono potenti e dovrebbe essere utilizzate con parsimonia, dato che possono causare delle alterazioni significative al funzionamento dell'elaborazione di Criteri di gruppo. Può essere anche molto difficile risolverne i problemi. Le opzioni per alterare l'ereditarietà predefinita comprendono le quattro impostazioni e configurazioni seguenti:
  • Blocca l'eredità dei criteri
  • Applicazione di Oggetti Criteri di gruppo
  • Filtro dell'elenco di controllo di accesso (ACL) con Oggetti Criteri di gruppo
  • Filtri Strumentazione gestione Windows (WMI)
Poiché queste impostazioni dovrebbero essere utilizzate con parsimonia, dovrebbe essere facile documentare quando sono utilizzate. Per scoprire se queste opzioni sono in uso, controllare nella GPMC. Il blocco dell'ereditarietà viene eseguito in corrispondenza del nodo di dominio o del nodo dell'unità organizzativa nella GPMC. L'applicazione dell'Oggetto criteri di gruppo, il filtro ACL e il filtro WMI vengono impostati su ogni Oggetto Criteri di gruppo.
In alternativa, è possibile eseguire il comando Gpresult dal computer di destinazione per avere un'idea se una di queste impostazioni impedisce l'applicazione dei criteri. Per una vista approfondita dei criteri applicati, è possibile aggiungere l'opzione /v al comando Gpresult, che fornirà un output dettagliato.

Problemi dei modelli ADM
Quando si tenta di configurare le impostazioni in un Oggetto Criteri di gruppo nella sezione Modelli amministrativi, si lavora con i modelli ADM. Oltre ai modelli ADM forniti con il sistema operativo, è possibile crearne uno personalizzato per l'uso in un Oggetto Criteri di gruppo. Il codice nel modello ADM crea le cartelle e i criteri nell'Editor criteri di gruppo sotto il nodo Modelli amministrativi. Tuttavia, se il modello ADM è corrotto, assente o non configurato correttamente, è molto probabile che non siano visibili alcune o tutte le impostazioni nell'editor. Di seguito vengono riportati alcuni problemi da cui tutelarsi durante l'utilizzo dei modelli ADM.
Modelli ADM mancanti Quando si modifica un Oggetto Criteri di gruppo e si scopre che ci sono delle impostazioni in un modello ADM personalizzato che non appaiono nell'editor, è necessario importare il modello ADM nell'Oggetto Criteri di gruppo. A tale scopo è sufficiente fare clic col pulsante destro del mouse sul nodo Modelli amministrativi nell'editor e selezionare Aggiunta/Rimozione modelli.
Preferenze mancanti Esistono due tipi di impostazioni che è possibile creare in un Oggetto Criteri di gruppo personalizzato: preferenze e criteri. I criteri sono le impostazioni Microsoft predefinite che rientrano tutte in una delle quattro sottochiavi nel registro di sistema, ciascuna delle quali termina con il testo "Policies". Le preferenze sono modifiche al registro di sistema "vecchio stile" che non rientrano in una delle quattro sottochiavi, e sono difficili da annullare una volta configurate. Queste preferenze non appaiono nell'editor per impostazione predefinita. È necessario attivarne la visualizzazione, nel menu Visualizza sulla barra degli strumenti. Da qui, scegliere Filtri e selezionare la casella di controllo "Visualizza solo le impostazioni di criteri completamente gestibili". In questo modo vengono immediatamente visualizzate le preferenze configurate nei modelli ADM personalizzati che sono stati importati.

Strumenti utili
Ci sono numerosi strumenti disponibili che consentono di tracciare i problemi di Criteri di gruppo. Alcuni sono incorporati nel sistema operativo e altri possono essere scaricati e installati. Di seguito tratterò gli strumenti appropriati per consentire di scegliere quello giusto per l'attività da svolgere.
Dcgpofix Potrebbe verificarsi un problema con uno dei due Oggetti Criteri di gruppo predefiniti: Criterio dominio predefinito e Criterio controller di dominio predefiniti. Se uno o entrambi gli Oggetti Criteri di gruppo diventano corrotti, troppo compromessi nella loro configurazione per ripararli o si presenta qualche altro problema sconosciuto, è possibile utilizzare lo strumento dcgpofix per riportarli allo stato predefinito. Questo strumento è contenuto in Windows Server® 2003 e non dovrebbe essere eseguito su un controller di dominio Windows 2000; dove è preferibile utilizzare invece Recreatedefpol. E ricordare che quando si utilizza questo strumento vengono perse tutte le impostazioni personalizzate.
Recreatedefpol Questo strumento è simile a Dcgpofix, ma per Windows 2000 server. Può riportare i due Oggetti Criteri di gruppo predefiniti allo stato della loro prima installazione. Utilizzare questo strumento solo in una situazione di ripristino di emergenza, non per la manutenzione di routine degli Oggetti Criteri di gruppo. È possibile scaricare questo strumento dalla pagina
Visualizzatore eventi Il Visualizzatore eventi fornisce numerose informazioni su Criteri di gruppo. Sfortunatamente, richiede di consultare tutti i diversi file registro per trovare le voci relative ai Criteri di gruppo. Qui sono disponibili voci relative all'applicazione, alla replica e all'aggiornamento dei criteri, tutte utili quando si tenta di tracciare un problema. Non ci sono sempre molte informazioni sugli errori specifici di Criteri di gruppo nei registri eventi, ma ricordare che è sempre possibile eseguire una ricerca in Technet se si riscontrano errori che non si riescono a identificare.
Gpresult Questo strumento può essere eseguito soltanto localmente sul computer di destinazione, ma fornisce delle informazioni su Gruppi di criteri risultanti (RSoP), gli Oggetti Criteri di gruppo bloccati, le autorizzazioni sugli Oggetti Criteri di gruppo e molto altro ancora. Utilizzare il comando con l'opzione /v per visualizzare una grande quantità di informazioni sugli Oggetti Criteri di gruppo che interessano il computer e sugli account utente associati alla sessione di accesso corrente.
Gpupdate Se si implementano nuove impostazioni di Oggetti Criteri di gruppo o si tenta di verificare che tutta l'elaborazione degli Oggetti Criteri di gruppo sia stata eseguita, è possibile utilizzare lo strumento Gpupdate. Di tratta di una utilità da riga di comando fornita con il sistema operativo (Windows XP e successivi). Quando viene eseguita, attiva un aggiornamento in background che applica tutte le impostazioni degli Oggetti Criteri di gruppo che aderiscono a questo tipo di aggiornamento. Se si aggiunge l'opzione /force, vengono riapplicate tutte le impostazioni degli Oggetti Criteri di gruppo, anche se non ci sono state modifiche all'Oggetto Criteri di gruppo dopo l'ultimo aggiornamento. L'esecuzione di questo comando prima di Gpresult è un metodo molto valido per tracciare i problemi degli Oggetti Criteri di gruppo.
Gpotool Poiché gli Oggetti Criteri di gruppo sono replicati dal controller di dominio dove sono state eseguite originariamente le modifiche a tutti gli altri controller di dominio, c'è una probabilità di errore di replica o mancata convergenza. Ne risulta una discordanza o un'errata applicazione delle modifiche ai computer di destinazione. Gli strumenti come Gpresult e RSOP possono aiutare a determinare quali Oggetti Criteri di gruppo sono stati applicati, ma lo strumento Gpotool può aiutare a determinare se gli Oggetti Criteri di gruppo sono coerenti su tutti i controller di dominio. Lo strumento è parte del Resource Kit di Windows Server 2003, disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=77613.
Replmon Durante la risoluzione dei problemi di replica degli Oggetti criteri di gruppo da un controller di dominio a un altro, è importante sapere quali strumenti si possono utilizzare affinché la replica funzioni. Poiché ci sono due parti di un Oggetto Criteri di gruppo che devono essere replicate, ci sono due parti che hanno bisogno di essere esaminate. La prima, che è il contenuto di SYSVOL su ogni controller di dominio, è controllata dal Servizio Replica file (FRS). Non c'è realmente molto che si possa fare per controllare questa replica, eccetto disattivare e attivare il servizio che consente di attivare un intervallo di replica. L'altra parte dell'Oggetto Criteri di gruppo, memorizzata in Active Directory, è controllata dalla replica di Active Directory. Questa replica può essere controllata tra i controller di dominio nello stesso sito di Active Directory utilizzando Siti e servizi di Active Directory. Comunque, quando si desidera attivare una replica tra i controller di dominio in siti di Active Directory diversi, è necessario utilizzare uno strumento come Replmon. Replmon può forzare la replica del database di Active Directory oltre i limiti del sito, mentre Siti e servizi di Active Directory non può. Quindi, quando c'è una mancata corrispondenza delle informazioni di Criteri di gruppo memorizzate in Active Directory, è possibile utilizzare Replmon per attivare un processo di replica e ottenere la convergenza delle informazioni su ogni controller di dominio. Replmon fa parte del Resource Kit e degli Strumenti di supporto di Windows XP. È scaricabile all'indirizzo go.microsoft.com/fwlink/?LinkId=77614.
RSOP Analogamente all'utilità da riga di comando Gpresult, RSOP fornisce un'interfaccia grafica per esaminare le impostazioni che sono state applicate da tutti gli Oggetti Criteri di gruppo. RSOP.MSC è uno strumento incorporato per Windows XP Professional e Windows Server 2003. Lo strumento fornisce un risultato di tutte le impostazioni di criteri applicate in un formato simile a quello dell'Editor oggetti Criteri di gruppo, come mostrato nella Figura 5.
Figura 5 Strumento Gruppo di criteri risultante
Figura 5 Strumento Gruppo di criteri risultante

Riepilogo
La risoluzione dei problemi di Criteri di gruppo non è l'attività più facile che si possa tentare. Infatti, come mostrato in questo articolo, i Criteri di gruppo possono essere abbastanza complicati. Quando si tenta di risolvere i problemi, è necessario comprendere l'architettura essenziale e l'elaborazione globale tipica dei Criteri di gruppo. Inoltre, è necessario comprendere in che modo vengono eseguiti l'aggiornamento, la replica, l'elaborazione e l'applicazione di un Oggetto Criteri di gruppo. Se si ha una buona padronanza di tutti questi concetti, la risoluzione di qualsiasi specifico problema di Criteri di gruppo risulta molto più facile. Seguendo le linee guida in questo articolo ed utilizzando adeguatamente gli strumenti, sarà possibile affrontare tutti i problemi di Criteri di gruppo che si possono incontrare.

Derek Melber è Director of Education, Certification, and Compliance Solutions per DesktopStandard, una società interamente controllata da Microsoft. Derek è coautore di Microsoft Windows Group Policy Guide (Microsoft Press, 2005). Ha scritto anche una serie di libri sulla verifica della protezione di Windows (www.theiia.org). Può essere contattato all'indirizzo derekm@desktopstandard.com.


 Amministrazione di Windows: Monitoraggio di Active Directory con MOM
Amministrazione di Windows John Hann

Monitoraggio di Active Directory con MOM
Panoramica:
  • Management pack per Active Directory
  • Suggerimenti di personalizzazione per MOM
  • Ottimizzazione degli avvisi

I management pack sono la linfa vitale di Microsoft Operations Manager (MOM) 2005 e sono ciò che lo differenzia dagli altri prodotti di gestione. MOM utilizza dei management pack per riunire regole, report, attività e viste. Il suo ambito può essere limitato a un'applicazione
o un servizio specifico, quale Active Directory. I team del prodotto Microsoft creano i management pack per le applicazioni che sviluppano, assicurando che MOM rifletta la loro conoscenza approfondita del prodotto. Inoltre, i management pack possono essere personalizzati per adattarli al proprio ambiente IT. Si ottengono così regole che monitorano e gestiscono il prodotto in base al particolare ambiente di server e applicazioni.
Non solo esiste un management pack specifico per Active Directory®, ma sono disponibili miriadi di management pack che consentono di misurare l'integrità dei servizi directory: dal sistema operativo base di Windows Server® a DHCP (Dynamic Host Configuration Protocol), DNS, e FRS (Servizio Replica file). Esaminiamo in dettaglio questi management pack per avere una maggiore comprensione della gestione end-to-end di Active Directory possibile attraverso MOM.

Management Pack per DHCP
Il management pack per il servizio DHCP monitora il servizio DHCP in esecuzione su Windows NT®, Windows® 2000 e Windows Server 2003. È opportuno monitorare il DHCP per sapere se i client hanno problemi di collegamento alla rete. Vengono inoltre segnalati i server DHCP non autorizzati in esecuzione nell'ambiente. Il pacchetto disponibile per il download di questo management pack contiene una guida che documenta le regole e i report, come pure gli scenari di controllo e distribuzione. Una fonte preziosa di documentazione e guida aggiuntiva è disponibile nel sito Web di MOM 2005 Technet (microsoft.com/technet/prodtechnol/mom/mom2005).
Più recente è la versione di Windows su cui si esegue il servizio DHCP, maggiori sono le funzionalità e gli strumenti forniti da MOM 2005 per la sua gestione. Pertanto, si ottengono più informazioni su un server DHCP di Windows Server 2003 rispetto a un server DHCP di Windows NT. Per esempio, è possibile monitorare l'ambito esteso di un server DHCP in esecuzione su Windows Server 2003, mentre il management pack per DHCP monitora soltanto gli ambiti normali su un server DHCP di Windows 2000. È possibile evitare il monitoraggio di determinati ambiti specificando che tali ambiti non vengano inclusi come parametri per lo script di monitoraggio.
Come menzionato in precedenza, il management pack per DHCP supporta server DHCP in esecuzione su Windows NT, Windows 2000 Server e Windows Server 2003. I gruppi di computer vengono popolati attraverso formule che utilizzano la versione del sistema operativo e la presenza o meno del servizio Server DHCP sul server.
Il management pack per DHCP non supporta le configurazioni con privilegi limitati. L'account azione dell'agente deve essere membro del gruppo Administrators locale. Il controllo senza agenti è supportato, ma le attività non sono supportate in una configurazione senza agenti. La Figura 1 elenca i report disponibili nel management pack per DHCP.
Figure 1 Report servizi DHCP (Close Figure 1)

Tutti i server DHCP
Tutti i server DHCP autorizzati
Performance History-Active Queue Length (Cronologia delle prestazioni-Lunghezza della coda attiva)
Performance History-Conflict Check Queue Length (Cronologia delle prestazioni-Lunghezza coda controlli conflitti)
Performance History-Declines per Second (Cronologia delle prestazioni-Rifiuti al secondo)
Performance History-Discovers per Second (Cronologia delle prestazioni-Ricerche al secondo)
Performance History-Milliseconds per Packet (Avg) (Cronologia delle prestazioni-Millisecondi a pacchetto (Media))
Performance History-NACKs per Second (Cronologia delle prestazioni-NACK al secondo)
Performance History-Scope Free Addresses (Cronologia delle prestazioni-Indirizzi senza ambito)
Performance History-Scope Addresses in Use (Cronologia delle prestazioni-Indirizzi ambito in uso)
Performance History-Superscope Free Addresses (Cronologia delle prestazioni-Indirizzi liberi ambito esteso)
Performance History-Superscope Addresses in Use (Cronologia delle prestazioni-Indirizzi ambito esteso in uso)
È possibile scaricare il management pack per DHCP da go.microsoft.com/fwlink/?LinkId=79527.

Management Pack per DNS
Il management pack per DNS (Domain Name Service) esegue il monitoraggio del servizio DNS in esecuzione su Windows 2000 Server e Windows Server 2003. Poiché fa parte dell'integrità complessiva di un'implementazione di Active Directory, è fondamentale eseguire il monitoraggio del DNS con MOM 2005. Il management pack per DNS monitora i problemi di risoluzione dei nomi, i problemi di database, i problemi del registro di sistema, gli eventi e gli errori di runtime, come pure i contatori legati alle prestazioni.
Per Windows 2000 Server, è necessario installare un provider DNS Strumentazione gestione Windows (WMI). Nello specifico, questo consente al management pack per DNS di eseguire ricerche nello spazio dei nomi DNS WMI per ottenere informazioni ed eseguire verifiche.
I gruppi di computer vengono popolati tutti attraverso formule che utilizzano la versione del sistema operativo e il fatto che il server ospiti o meno il servizio Server DNS per determinare l'appartenenza al gruppo. Il management pack per DNS supporta i privilegi limitati solo in Windows Server 2003. In Windows 2000, l'account azione dell'agente deve essere membro del gruppo Administrators locale. In Windows Server 2003, l'account azione deve essere membro dei gruppi locali Users e Performance Monitor Users. Inoltre, è necessario che l'account azione disponga delle autorizzazioni Gestione file registro di controllo e di protezione (SeSecurityPrivilege) e Consenti accesso locale (SeInteractiveLogonRight). La Figura 2 elenca i report disponibili nel management pack DNS.
Figure 2 Report per il servizio DNS (Close Figure 2)

All Windows DNS Servers (Tutti i server DNS Windows)
All Windows DNS Servers by Zone (Tutti i server DNS Windows per zona)
All Windows DNS Zones by Server (Tutte le zone DNS Windows per server)
Marcus Oh, MVP per Microsoft® Systems Management Server (SMS), ha sviluppato uno script che verifica un server DNS richiamando nslookup per verificare la capacità del server DNS di risolvere i nomi. Consultare l'articolo sul suo blog all'indirizzo marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html; questo script può essere integrato nel proprio management pack per DNS.
È possibile scaricare il management pack per DNS da go.microsoft.com/fwlink/?LinkId=79528.

Management Pack per FRS
Il management pack per il Servizio Replica file di Windows monitora il servizio FRS in esecuzione su Windows 2000 e Windows Server 2003. FRS è utilizzato dai controller di dominio per replicare gli script di accesso e le informazioni su Criteri di gruppo. Il management pack per FRS fornisce dettagli sull'integrità del servizio FRS per ogni controller di dominio.
Inoltre, utilizza lo strumento Ultrasound, disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=79529. Ultrasound crea uno spazio dei nomi WMI per FRS su ogni controller di dominio. Notare che Ultrasound richiede un database e memorizza le informazioni dallo spazio dei nomi WMI su ogni controller di dominio per il monitoraggio dello stato del sistema. Utilizzando le informazioni di Ultrasound, il management pack per FRS fornisce il monitoraggio per set di repliche, membri, connessioni, il servizio FRS stesso e il servizio controller di Ultrasound.
Infatti, si consiglia di installare Ultrasound su un server diverso dal server di gestione. Le regole di Ultrasound generano eventi e avvisi per conto di altri computer. Per consentire alle regole di Ultrasound di elaborare i dati correttamente, è necessario attivare il proxy degli agenti nella console amministrazione di MOM su ogni server che esegue Ultrasound. La Figura 3 elenca i quattro report di servizio disponibili nel management pack per FRS.
Figure 3 Report servizi FRS (Close Figure 3)

Ultrasound-Frequently Detected Issues-Most Problematic Connections (Ultrasound-Problemi rilevati di frequente-Connessioni più problematiche)
Ultrasound-Frequently Detected Issues-Most Problematic Members (Ultrasound-Problemi rilevati di frequente-Membri più problematici)
Ultrasound-Frequently Detected Issues-Most Problematic Replica Set (Ultrasound-Problemi rilevati di frequente-Set di replica più problematico)
Ultrasound-Frequently Detected Issues-Summary (Ultrasound-Problemi rilevati di frequente-Riepilogo)
I gruppi di computer associati a questo management pack contiene server Microsoft Ultrasound 1.0 e server FRS in esecuzione su Windows 2000 Server e Windows Server 2003. I gruppi di computer vengono popolati attraverso formule che utilizzano la versione di sistema operativo e il fatto che il server ospiti o meno il servizio FRS per determinare l'appartenenza al gruppo. Il gruppo Ultrasound Servers viene popolato quando su un server è installato Ultrasound.
Quando si configura il management pack per FRS per privilegi limitati, le attività non funzionano, ma il resto delle funzionalità del management pack è supportato. L'account azione deve avere accesso in lettura al database Ultrasound e autorizzazione per l'esecuzione della stored procedure GetControllerStatusForMOM001. Il management pack per FRS contiene il supporto per il monitoraggio di computer con e senza agente.
È possibile scaricare il management pack per FRS da go.microsoft.com/fwlink/?LinkId=79530.

Management Pack per Windows Server
Il management pack per il sistema operativo base di Windows monitora Windows NT 4.0 Server, Windows 2000 Server e Windows Server 2003. Il management pack del sistema operativo base fornisce report sull'integrità del sistema operativo per i controller di dominio, monitorando inoltre i servizi principali sul sistema. Il management pack fornisce lo stato di servizi di base di Windows, le prestazioni di memoria e processore, lo spazio libero su disco e la latenza del disco. C'è un certo grado di sovrapposizione tra le regole di monitoraggio di questo management pack e gli altri illustrati in questo articolo, ma questo fornisce un'ottima visuale dell'integrità del controller di dominio.
La Figura 4 elenca i report disponibili nel management pack per il sistema operativo base. Come tutti gli altri management pack, i gruppi di computer vengono popolati mediante formule che utilizzano la versione del sistema operativo.
Figure 4 Report per il sistema operativo base (Close Figure 4)

Disk Performance Analysis (Analisi prestazioni disco)
Operating System Configuration (Configurazione sistema operativo)
Operating System Performance (Prestazioni sistema operativo)
Operating System Shutdown by Event (Arresto sistema operativo per evento)
Operating System Shutdown by Server (Arresto sistema operativo per server)
Operating System Storage Configuration (Configurazione di archiviazione del sistema operativo)
Software and Applications Installations by Application (Installazioni di software e applicazioni per applicazione)
Software and Applications Installations by Instance (Installazioni di software e applicazioni per istanza)
Software and Applications Installations by Server (Installazioni di software e applicazioni per server)
Reliability-Application Failures by Application (Affidabilità-Errori applicazioni per applicazione)
Reliability-Application Failures by Computer (Affidabilità-Errori applicazioni per computer)
Reliability-Application Failures by Event (Affidabilità-Errori applicazioni per evento)
Reliability-Operating System Failures by Computer (Affidabilità-Errori del sistema operativo per computer)
Reliability-Operating System Failures by Event (Affidabilità-Errori del sistema operativo per evento)
Reliability-Operating System Failures by Stop Code (Affidabilità-Errori del sistema operativo per Codice Fermo)
Performance History-Performance History (Cronologia delle prestazioni-Cronologia delle prestazioni)
Performance History-Additional Reports (Cronologia delle prestazioni-Report aggiuntivi)
Quando si configura il management pack per il sistema operativo base per il funzionamento con privilegi limitati, in Windows 2000 è necessario che l'account azione sia membro del gruppo Administrators locale. In windows Server 2003 è necessario che l'account azione sia membro dei gruppi locali Users e Performance Monitor Users e abbia le autorizzazioni Gestione file registro di controllo e di protezione (SeSecurityPrivilege) e Consenti accesso locale (il Seinteractivelog onright). La maggior parte delle funzionalità del management pack per il sistema operativo base, eccetto le attività, sono supportate su computer monitorati senza agente.
È possibile scaricare il management pack per il sistema operativo base da go.microsoft.com/fwlink/?LinkId=79531.

Management Pack per Active Directory
Il management pack per Active Directory è molto grande e le sue regole coprono sia Windows 2000 Server che Windows Server 2003. Il management pack per Active Directory comprende cinque aree di regole: monitoraggio lato client, monitoraggio delle relazioni di trust, monitoraggio replica e rilevamento topologia, oltre a regole che riguardano specificamente i sistemi operativi Windows 2000 Server e Windows Server 2003. Come indicato in precedenza, le versioni più recenti di Windows offrono più strumentazione e quindi un monitoraggio aggiuntivo. Per esempio, il management pack supporta il monitoraggio delle relazioni di trust su Windows Server 2003, ma non su Windows 2000.
Il management pack per Active Directory crea numerosi gruppi utilizzati per applicare le regole a computer specifici. Le regole di monitoraggio lato client utilizzano un gruppo denominato Active Directory Client Side Monitoring. Per monitorare e gestire queste regole, i computer su cui è installato l'agente MOM devono essere inseriti in questo gruppo. Ho messo alcuni computer desktop forniti in licenza con l'agente in questo gruppo come pure alcuni dei server Exchange. Il server Exchange fa ampio uso di Active Directory ed è un indicatore principale di un problema di sviluppo. I computer desktop nel gruppo possono aiutare a valutare l'esperienza dell'utente finale. Le regole di monitoraggio lato client utilizzano degli script per verificare la connettività ai controller di dominio, interrogandoli tramite LDAP e fornendo report degli errori. È importante notare che le regole di monitoraggio lato client possono essere applicate soltanto ai computer gestiti tramite agente con proxy abilitato e non ai controller di dominio.
Le regole di monitoraggio delle relazioni di trust utilizzano un gruppo denominato Active Directory Trust Monitoring. Per verificare le relazioni di trust, inserire i computer windows Server 2003 in questo gruppo. Windows Server 2003 dispone di uno spazio dei nomi WMI per il controllo delle relazioni di trust. Queste regole utilizzano uno script per eseguire query sullo spazio dei nomi WMI. Quando vengono rilevati errori nelle relazioni di trust con altri domini, queste regole forniscono avvisi.
Sono disponibili molte regole del management pack per Active Directory che si applicano sia a Windows 2000 Server che a Windows Server 2003. Queste regole delineano le differenze nel modo in cui è stato implementato Active Directory tra i due sistemi operativi. Tuttavia, la maggior parte del management pack per Active Directory rientra nelle regole combinate per entrambi i sistemi operativi. Alcune di queste regole contengono degli script per testare la connettività tra i controller di dominio, verificando i ruoli FSMO (Flexible Single Master Operation) e la dimensione del database DIT (Directory Information Tree), convalidando l'elaborazione di Criteri di gruppo, il controllo di coerenza informazioni (KCC, Knowledge Consistency Checker) e la verifica del servizio Messaggistica tra siti.
Il controllo di replica è il cuore del management pack per Active Directory. Vengono creati due gruppi, Active Directory Replication Latency Data Collection Sources e Active Directory Replication Latency Data Collection Targets, per consentire di configurare i controller di dominio utilizzati soltanto per fornire report sul monitoraggio della replica. La latenza di replica è calcolata per ogni membro dei gruppi di raccolta dati. I contatori delle prestazioni vengono popolati con il tempo necessario agli aggiornamenti per la replica su ciascun membro del gruppo. La latenza di replica a livello di organizzazione è calcolata e segnalata in un report (e vengono generati avvisi) se supera le soglie definite. Notare che su Windows 2000 Server è necessario installare uno spazio dei nomi WMI per il monitoraggio della replica.
Rilevamento topologia nel management pack per Active Directory viene utilizzato per creare diagrammi dell'implementazione. Questi diagrammi utili possono essere esportati in Microsoft Office Visio®. I diagrammi vengono creati in tempo reale da MOM in modo da consentire la creazione di una versione aggiornata in pochi secondi.
In Viste diagrammi nella console operatore di MOM 2005 sono presenti tre diagrammi del management pack per Active Directory. Il diagramma Broken Connection Objects (Oggetti connessione interrotta) (vedere la Figura 5) mostra eventuali connessioni che sono in uno stato di errore. Questo diagramma può essere vuoto se non sono presenti errori di connessione.
Figura 5 Le connessioni interrotte sono evidenziate in Viste diagrammi
Figura 5 Le connessioni interrotte sono evidenziate in Viste diagrammi
Il diagramma Connection Objects (Oggetti connessione) evidenzia le connessioni tra controller di dominio. Il diagramma Site Links (Collegamenti sito) mostra ogni sito di Active Directory, incapsulando i controller di dominio appropriati in quel sito e i collegamenti del sito.
Poiché i diagrammi creati da MOM per queste viste sono dinamici, è possibile esportarli in Visio per modificarli e personalizzarli con facilità. Per esempio, la Figura 6 mostra il diagramma Site Links (Collegamenti sito) modificato in Visio.
Figura 6 Modifica di un diagramma Site Links (Collegamenti sito) in Visio
Figura 6 Modifica di un diagramma Site Links (Collegamenti sito) in Visio (Fare clic sull'immagine per ridurla)
Figura 6 Modifica di un diagramma Site Links (Collegamenti sito) in Visio
Figura 6 Modifica di un diagramma Site Links (Collegamenti sito) in Visio (Fare clic sull'immagine per ingrandirla)
La Figura 7 elenca i report disponibili nel management pack per Active Directory. I gruppi di computer associati a questo management pack sono indicati nella Figura 8. Come si può vedere, i gruppi di computer di Active Directory vengono popolati in base all'appartenenza esplicita; i gruppi di computer di Windows vengono popolati in base alla versione del sistema operativo e se il computer è un controller di dominio.
Figure 8 Computer Groups (Gruppi di computer) (Close Figure 8)

Active Directory Client-Side Monitoring (Monitoraggio lato client Active Directory)
Active Directory Replication Latency Data (Dati di latenza replica Active Directory)
Collection-Sources (Raccolta-Origini)
Active Directory Replication Latency Data (Dati di latenza replica Active Directory)
Collection-Targets (Raccolta-Destinazioni)
Active Directory Trust Monitoring (Monitoraggio relazioni di trust Active Directory)
Windows 2000 Server Domain Controllers (Controller di dominio Windows 2000 Server)
Windows Server 2003 Domain Controllers (Controller di dominio Windows Server 2003)
Figure 7 Report per Active Directory (Close Figure 7)

AD Domain Controller (Controller di dominio AD)
AD Role Holders (Ruoli AD)
AD Replication Connection Objects (Oggetti connessione replica AD)
AD Replication Site Links (Collegamenti sito replica AD)
AD DC Disk Space (Spazio su disco controller di dominio AD)
AD Domain Changes (Modifiche dominio AD)ù
AD Machine Account Authentication Failures (Errori di autenticazione account computer AD)
AD Replication Bandwidth (Larghezza di banda replica AD)
AD Replication Latency (Latenza replica AD)
Il management pack per Active Directory può essere configurato per privilegi limitati sui controller di dominio Windows Server 2003. Il management pack non supporta il monitoraggio senza agente. Su Windows 2000 Server, l'account azione dell'agente deve essere membro del gruppo Domain Admins o del gruppo Administrators locale. L'account azione dell'agente sui controller di dominio Windows Server 2003 deve disporre di autorizzazioni aggiuntive configurate per i privilegi limitati, compresa l'appartenenza ai gruppi Users e Performance Monitor Users, dell'accesso ai Registri eventi e dei privilegi SeSecurityPrivilege, SeAuditPrivilege e SeInteractiveLogonRight. Inoltre, è richiesto l'accesso seguente: accesso completo al contenitore CN=MomLatencyMonitors in Active Directory per il monitoraggio della replica, accesso in lettura alle directory contenenti il database NTDS.dit e i file registro, infine accesso in lettura alla seguente chiave del registro di sistema:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
Se si esegue il monitoraggio delle relazioni di trust in Windows Server 2003, notare che lo script AD Monitor Trusts richiede che l'account azione dell'agente sia membro del gruppo Domain Admin o Administrators.
È possibile scaricare il management pack per Active Directory da go.microsoft.com/fwlink/?LinkId=79540.

Personalizzazione di MOM per Active Directory
Occorre configurare il management pack per Active Directory, altrimenti gli avvisi riempiranno la console. Il momento di maggiore impegno del management pack per Active Directory si verifica al riavvio di un controller di dominio. Sembra vengano attivati tutti i possibili avvisi. Il problema è che non è semplice evitarlo. La soluzione migliore consiste nell'utilizzare la modalità manutenzione in MOM per controllare gli avvisi durante la manutenzione programmata di Windows. Lo scopo della modalità manutenzione è risolvere automaticamente gli avvisi per i controller di dominio in modo da non riempire la console.
Accertarsi di configurare il gruppo Active Directory Client Side Monitoring inserendo al suo interno i computer client e i server adeguati. Le regole associate a questo gruppo aiutano a determinare l'integrità di FSMO e la connettività verso di loro.
Ci sono regole prestazioni che utilizzano delle soglie per limitare FSMO mediante LDAP, PING e DNS per verificare la connettività. Queste regole sono localizzate nelle regole prestazioni di Active Directory Availability. Personalizzare le soglie utilizzate da queste regole impostando la gravità degli avvisi. Per esempio, le associazioni FSMO utilizzano valori di attributo espressi in secondi. Le regole prestazioni di ogni ruolo FSMO utilizzano questa metodologia di creazione degli avvisi.
È importante capire come funziona Calcolo gravità avvisi per le impostazioni di Regola di stato. La finestra di dialogo utilizza condizioni If-Else per il valore attributo e di conseguenza imposta la gravità dell'avviso (vedere la Figura 9). Quando la regola raccoglie il contatore di prestazioni Last Bind (Ultimo bind) creato dallo script AD Op Master Response, lo confronta con i valori di soglia condizionali impostate da queste regole. È necessario configurare questi livelli diversi di avviso per il proprio ambiente.
Figura 9 Impostazione delle regole sulla gravità degli avvisi
Figura 9 Impostazione delle regole sulla gravità degli avvisi (Fare clic sull'immagine per ridurla)
Figura 9 Impostazione delle regole sulla gravità degli avvisi
Figura 9 Impostazione delle regole sulla gravità degli avvisi (Fare clic sull'immagine per ingrandirla)
Ricordare la pianificazione repliche per ciascun controller di dominio. Se un dato controller di dominio presenta una pianificazione diversa dagli altri, devierà i risultati di latenza di replica comportando la necessità di impostare soglie più alte. È necessario impostare i parametri per gli script di replica per soddisfare le esigenze dello specifico ambiente. È importante notare che quando un controller di dominio qualsiasi è inattivo o presenta problemi di replica, tutti gli altri controller di dominio in questi gruppi possono segnalare un errore di replica per tale controller di dominio anche se non è un partner di replica diretto. Tuttavia, anche se il controller di dominio che causa problemi viene posto in modalità di manutenzione, gli altri controller di dominio possono segnalare errori di replica.
Il monitoraggio della replica è l'elemento che richiede i maggiori sforzi per l'ottimizzazione del management pack per Active Directory. Per verificare il comportamento degli avvisi, è necessario eseguire il management pack nel proprio ambiente per un paio di settimane. Una volta osservato lo sviluppo delle tendenze, utilizzare i report per delineare le latenze e ottimizzare di conseguenza le soglie.
Infine, è consigliabile sfruttare la guida fornita in Alert Tuning Solution Accelerator (in inglese).

In futuro
MOM 2005 e il management pack per Active Directory consentono di monitorare in modo efficace ed efficiente l'implementazione di Active Directory della propria organizzazione. Con i management pack per Active Directory, DHCP, DNS, FRS e sistema operativo base di Windows Server, è possibile monitorare meglio la maggior parte degli aspetti della propria infrastruttura, proteggendo l'integrità dell'infrastruttura Active Directory e gli utenti. L'utilizzo dei dati estesi raccolti nel data warehouse dei report consente di analizzare dati su prestazioni ed eventi per migliorare la pianificazione delle capacità e le tendenze nelle prestazioni.
Per trovare i management pack che ho trattato in questo articolo, insieme a tanti altri, vedere Management Pack Catalog (in inglese).
Il prossimo aggiornamento al management pack per Active Directory conterrà la consueta raccolta di correzioni e modifiche per alcune soglie. Più interessanti sono le nuove funzionalità progettate per la prossima versione del prodotto, denominata System Center Operations Manager 2007, tra cui la capacità di monitorare più insiemi di strutture da un singolo gruppo di configurazione, definire gruppi di controller di dominio (ciascuno con la propria latenza di replica prevista tra gli altri gruppi) e monitorare i controller di dominio in esecuzione sulla versione successiva di Windows Server. Per i dettagli, visitare il sito Web di MOM all'indirizzo microsoft.com/mom

John Hann ha lavorato con MOM fin da MOM 2000 ed è stato un MVP di MOM dal 2004; contribuisce inoltre a MyITforum.com, MOMCommunity.com e LearnMOM.com. È possibile contattarlo consultando il suo blog.


 Amministrazione di Windows: Gioco in un ambiente sicuro
Amministrazione di Windows Matt Clapham

Gioco in un ambiente sicuro
Panoramica:
  • Scrittura in cartelle protette e chiavi del registro di sistema
  • Errori di protezione dalla copia
  • Problemi di firewall
  • Problemi con i client aziendali

Di giorno, lavoro come Program Manager di sicurezza presso Microsoft. Ma spesso scrivo articoli sulla sicurezza per TechNet Magazine. Inutile a dirsi, la sicurezza ha per me un'importanza fondamentale. Ma ho anche altri
interessi. Mi piace trascorrere il mio tempo libero eseguendo giochi basati su Windows®. In particolare mi appassionano i giochi che implicano soprattutto in prima persona, simulatori, i giochi di ruolo e giochi di strategia in tempo reale. C'è un problema, però. Come i miei amici Jesper Johansson e Aaron Margosis, mi rifiuto di eseguire i giochi con privilegi amministrativi eccetto quando assolutamente necessario. Faccio questo in parte per assicurarmi che, se vengo battuto in un gioco in rete, non è solo per la mia mancanza di abilità né perché qualcuno mi bombarda con un rootkit per impedirmi di prendere la mira (vedere Quake 3 Buffer Overflow Advisory nella barra laterale "Risorse").
Questo gioco mi appassiona a tal punto che spesso mi impedisce di cominciarne un altro (vedere la Figura 1). Se non è possibile eseguire il gioco utilizzando il mio account utente con limitazioni (LUA, Limited User Account) su un client che fa parte di un dominio Small Business Server (SBS) dopo aver installato e aggiornato un account amministratore, lo rimuovo subito. Non ci sono scuse per questa scarsa progettazione, e di certo non mi mancano i giochi tra cui scegliere. Ammetto che questo possa suonare come una posizione estrema da prendere, ma sono irremovibile su questo punto. Tuttavia, non sono contrario a trovare soluzioni per aggirare alcune pecche minori per amore di qualche momento di gioco di qualità ed è di questo che tratterò qui. Dunque mi sia consentito di condividere alcuni dei problemi riscontrati relativi ai giochi e le soluzioni individuate. Per un riepilogo veloce delle procedure consigliate, consultare "Suggerimenti per giocare come utente con limitazioni" nella barra laterale.
Figura 1 Problema di accesso ai file durante l'esecuzione di un aggiornamento manuale
Figura 1 Problema di accesso ai file durante l'esecuzione di un aggiornamento manuale (Fare clic sull'immagine per ridurla)
Figura 1 Problema di accesso ai file durante l'esecuzione di un aggiornamento manuale
Figura 1 Problema di accesso ai file durante l'esecuzione di un aggiornamento manuale (Fare clic sull'immagine per ingrandirla)

Problemi comuni
Il problema relativo ai privilegi non è una novità. Numerosi giochi, nonché altri tipi di programmi, richiedono i privilegi amministrativi per essere eseguiti correttamente. Leggere l'articolo della Knowledge Base "Alcuni programmi non funzionano correttamente se si effettua l'accesso con un account utente con limitazioni" (vedere support.microsoft.com/kb/307091). Tale articolo elenca quasi 200 giochi e applicazioni che presentano difficoltà se eseguiti da un utente con limitazioni, compresi alcuni programmi Microsoft.
Voglio sia chiaro che non considero un problema la necessità di privilegi amministrativi per installare o aggiornare (manualmente) un gioco. Sarà così fino a quando non si potranno eseguire installazioni di routine per utente in Windows. Quel giorno sta per arrivare, ma non ci siamo ancora. Tuttavia, una volta installato e aggiornato un gioco, qualsiasi utente di un sistema dovrebbe essere in grado di utilizzarlo, anche uno con privilegi limitati.
Tentativi di scrittura in cartelle protette e chiavi del registro di sistema Il problema più comune da me individuato è quando un gioco presenta errori all'avvio o durante la partita perché tenta di scrivere in cartelle protette o chiavi del registro di sistema (comune in molte applicazioni basate su Windows). Per impostazione predefinita, soltanto gli amministratori (e gli utenti esperti obsoleti) possono scrivere in determinate cartelle (come %PROGRAMFILES%) e hive del registro di sistema (come HKEY_LOCAL_MACHINE). Gli errori possono essere abbastanza ovvi: "Errore 42: Impossibile scrivere i file di registro in C: \Programmi\CoolGamesInc\NewestFPS\Logs\” o "Gioco non installato correttamente, reinstallare e riavviare". A metà del gioco sono emersi alcuni esempi, come i messaggi di errore visualizzati durante il salvataggio dei progressi. A volte chi scrive i giochi avvisa in qualche modo l'utente che il gioco necessita attualmente del privilegio amministrativo per funzionare, come sperimentato con Age of Mythology®. I giochi MMO (Massively multiplayer online) spesso presentano problemi di privilegi poiché si aggiornano frequentemente. Inoltre, l'aggiornamento automatico è leggermente più complesso da risolvere tecnologicamente. Quando ho eseguito la versione di valutazione di EVE Online, ho notato che non solo collocava file di registro nelle posizioni improprie, ma tentava anche di auto-aggiornare i dati di contenuto del gioco nella cartella di installazione.
Errori di protezione dalla copia La seconda ragione più comune che ho visto per il mancato avvio dei giochi è quando la protezione dalla copia incorporata del gioco (o altra funzionalità anti-pirateria) non funziona come un utente con limitazioni. La causa potrebbe essere che il driver non è stato avviato correttamente o che un qualche servizio in background non è in esecuzione. Il problema più comune rilevato è quando durante il gioco viene chiesto all'utente di inserire un disco anche quando il supporto richiesto è già nell'unità. Ho notato anche dei giochi che richiedono assolutamente i privilegi di amministratore in base alla convinzione illegittima che soltanto gli amministratori possono eseguire correttamente la verifica di protezione dalla copia. Nei casi peggiori viene visualizzato un messaggio di errore mal formulato e insensato che non ha alcun riferimento sul sito di supporto del gioco.
Errore di richiesta di un'eccezione del firewall I giochi multiplayer che possono essere eseguiti su una rete locale o su Internet sono molto comuni e in Windows XP Service Pack 2 (SP2) è stato aggiunto un messaggio di avviso che indica all'utente quando le applicazioni sono in ascolto sulla rete. Questo errore mi porta a un altro problema comune: giochi che richiedono un'eccezione firewall, ma non l'aggiunta di tale eccezione al momento dell'installazione. Poiché gli utenti con limitazioni non possono alterare la configurazione del firewall, questo problema (vedere la Figura 2) non può essere risolto senza un'azione di configurazione eseguita da un amministratore. A volte il problema non è ovvio, poiché l'avviso viene visualizzato nella shell di Windows, non nell'interfaccia del gioco. Infatti, in genere, il messaggio di errore non viene visualizzato fino a quando non si esce dal gioco.
Figura 2 Quando le impostazioni del firewall arrestano tutto il divertimento
Figura 2 Quando le impostazioni del firewall arrestano tutto il divertimento (Fare clic sull'immagine per ridurla)
Figura 2 Quando le impostazioni del firewall arrestano tutto il divertimento
Figura 2 Quando le impostazioni del firewall arrestano tutto il divertimento (Fare clic sull'immagine per ingrandirla)
Problemi con i client enterprise Ho individuato altro problema non direttamente correlato all'esecuzione come utente con limitazioni, ma vale la pena trattarlo comunque. Utilizzo il mio PC di casa come una piccola azienda (non andrò troppo in dettaglio qui, ma si può leggere in proposito nell'articolo "Master Your Domain: Build a Corporate Network at Home", in inglese, scritto in collaborazione con Jesper Johansson per il numero di Ottobre 2006 di TechNet Magazine). Utilizzando SBS 2003 (R2), ho preparato un dominio di Windows completo con una cartella Documenti reindirizzata a una condivisione su server. Ecco come ho scoperto l'ultimo problema più comune che andrò ad illustrare: i giochi che non possono gestire i client enterprise
Ho notato un doppio problema con Age of Empires® III (AoE3). È merito del team di sviluppo se il gioco inizia e prosegue correttamente come un utente con limitazioni. Tuttavia, ho notato che gli scenari venivano caricati lentamente a causa dei molti dati di registrazione scritti in rete. Inoltre, ogni volta che si usciva dal gioco, AoE3 perdeva la mia configurazione, i giochi salvati e i progressi. I file erano chiaramente nella cartella Documenti, ma il gioco non li caricava. È stata una grande delusione, soprattutto considerando il fatto che AoE3 era diventato semplice da usare per LUA rispetto alle versioni precedenti della serie.
Ho visto un gioco in grado almeno di riconoscere tali problemi di client enterprise. Quando ho provato Fable®: The Lost Chapters™, il gioco indicava che le cartelle remote Documenti non erano supportate e veniva chiuso. Il team di sviluppo ha fatto un grande lavoro nel riconoscere uno scenario non supportato e nell'averlo segnalato. Tuttavia, è sembrato alquanto strano che il gioco smettesse di funzionare, dato che prevedeva di collocare soltanto pochi megabyte di dati nella cartella Documenti.

Soluzioni semplici
Ho riscontrato questi problemi diverse volte, su più giochi di quanti mi possa ricordare. Fortunatamente, la maggior parte di essi prevedeva soluzioni adatte. Generalmente, preferisco lasciare del tutto il gioco, passando a un titolo pronto per l'esecuzione come utente con limitazioni nello stesso genere fornito da un autore diverso. Potrebbe sembrare ancora una volta un atteggiamento estremista. E sicuramente non è una soluzione intelligente soprattutto dopo aver speso 60 dollari per un titolo nuovo e non poterlo restituire perché la confezione è già stata aperta. Pertanto si veda come poter aggiornare i giochi già in mio possesso.Suggerimenti per giocare come utente con limitazioni
  • Eseguire l'aggiornamento a Windows Vista.
  • Provare la demo prima di acquistare il prodotto. La demo evidenzierà molto probabilmente tutti i problemi di esecuzione come utente con limitazioni presenti nella versione completa.
  • Consultare l'elenco di programmi che notoriamente presentano problemi di esecuzione con un account utente con limitazioni ().
  • Cercare i giochi che portano il logo Designed for Windows.
  • Aggiornare il gioco dopo l'installazione e prima di eseguirlo come un utente con limitazioni.
  • Quando si trova un gioco che non funziona come un utente con limitazioni, esprimere le proprie lamentele all'autore e al servizio di supporto tecnico dell'azienda.
  • Se necessario, utilizzare un account utente esperto del sistema locale.

Correzione degli errori di protezione dalla copia Per prima cosa, affrontiamo il problema del driver di protezione dalla copia. I sistemi di protezione copia sono idonei, ma ciò non significa che debbano impedire agli utenti non amministratori di eseguire i giochi! La maggior parte dei giochi utilizza il meccanismo di protezione copia SafeDisc di Macrovision, che installa un driver che controlla la presenza di un disco del gioco originale. Per impostazione predefinita, il driver è configurato per l'avvio su richiesta (una funzione che gli utenti con limitazioni non sono autorizzati a utilizzare). Microsoft e Macrovision hanno distribuito alcune correzioni, ma io ho individuato un'altra soluzione:
  1. Aprire Gestione periferiche utilizzando un account amministratore.
  2. Andare al menu Visualizza e scegliere Mostra periferiche nascoste.
  3. Espandere il nodo Driver non Plug and Play.
  4. Aprire le proprietà per il driver di Protezione o SecDrv (vedere la Figura 3).
  5. Modificare il tipo di avvio in Automatico.
Figura 3 Corretta esecuzione della protezione copia
Figura 3 Corretta esecuzione della protezione copia (Fare clic sull'immagine per ridurla)
Figura 3 Corretta esecuzione della protezione copia
Figura 3 Corretta esecuzione della protezione copia (Fare clic sull'immagine per ingrandirla)
Poiché il driver adesso viene avviato all'avvio del computer, è pronto a eseguire il gioco quando l'utente inserisce il disco.
Correzione dei problemi di accesso al file system e al registro di sistema Il problema dell'accesso libero a qualunque parte del file system o del registro di sistema è comune con molti programmi correnti e legacy, non solo con i giochi. L'articolo di Aaron Margosis "Problems of Privilege: Find and Fix LUA Bugs" (in inglese) entra nei dettagli delle soluzioni ai vari problemi che portano a richiedere i privilegi di amministratore (vedere ).
Tenere traccia dei problemi di accesso può risultare difficile, ma una volta individuati il gruppo di file, cartelle e chiavi del registro di sistema richiesti, risulta semplice estendere gli elenchi di controllo di accesso (ACL) che consentono a utenti con limitazioni di utilizzare il gioco. Il risultati migliori li ho ottenuti con il seguente metodo:
  1. scaricare le versioni più recenti di Filemon e Regmon da microsoft.com/technet/sysinternals.
  2. Eseguire gli strumenti come un amministratore ed iniziare a raccogliere i log.
  3. Giocare per qualche minuto come amministratore, eseguendo le attività più comuni (iniziare una nuova campagna, salvare un gioco, ospitare un gioco di rete, e così via).
  4. Filtrare i risultati di Filemon e Regmon per concentrarsi sugli accessi dal gioco in fase di test.
  5. Se necessario, estendere gli ACL sulle cartelle e le chiavi del registro di sistema in questione.
  6. Eseguire il gioco come utente non amministratore per accertarsi che ora funzioni.
Un consiglio sull'estensione degli ACL: non estenderli troppo (ad esempio Everyone-Full Control) o a un livello troppo alto (ad esempio HKEY_CLASSES_ROOT). È preferibile evitare di modificare tutte le autorizzazione sulle cartelle di sistema come %SYSTEMROOT% e %PROGRAMFILES% per impedire di danneggiare completamente Windows o lasciare il sistema in uno stato non sicuro.
Un'altra potenziale soluzione consiste nell'eseguire il gioco come utente esperto del sistema locale. Non è la prima opzione da me seguita, ma utilizzando un account locale del sistema, se qualcosa non dovesse andare per il verso giusto, l'ambito dell'impatto sarebbe limitato a una sola workstation. Questa correzione è adatta per la maggior parte dei giochi che sembrano funzionare correttamente solo come amministratore.
Ho scoperto che se si esegue il gioco per un breve periodo come amministratore l'aggiornamento avviene in maniera automatica. In genere, eseguo il gioco come amministratore, ne richiamo l'opzione di aggiornamento ed esco dal gioco per tornare al mio account utente con limitazioni per giocare davvero. (Vale la pena menzionare che Windows Vista™ consente agli utenti con limitazioni di aggiornare le applicazioni, presupponendo che la patch sia firmata dall'autore originale).
Windows Vista consente anche di risolvere i problemi di acceso a file e registro di sistema riscontrati da giochi e altre applicazioni. Per impostazione predefinita, i programmi eseguiti dagli utenti con limitazioni hanno shim di virtualizzazione abilitati che reindirizzano gli accessi fuorviati a file e registro di sistema alla cache di uno specifico utente. Ho visto personalmente dei giochi progettati nell'era di Windows 9x, (per esempio, The Neverhood) che non venivano eseguiti correttamente su Windows XP (a causa dei problemi di autorizzazione) funzionare perfettamente in Windows Vista con gli shim predefiniti. Non vedo l'ora di verificare altri giochi problematici su Windows Vista, ma il mio sospetto è che sarà difficile trovare un gioco di cui Windows Vista non possa eseguire lo shim correttamente.
Risoluzione dei problemi di firewall. Il problema del firewall viene risolto al meglio alla prima installazione del gioco. Tuttavia, quando l'installazione del gioco non richiede e non configura gli adattamenti necessari al firewall, ecco un metodo che ho visto funzionare bene:
  1. Accedere come un amministratore.
  2. Aprire il Pannello di controllo di Windows Firewall.
  3. Scegliere di aggiungere un programma all'elenco di eccezioni firewall.
  4. Scegliere il gioco dall'elenco o ricercarne l'eseguibile quando richiesto.
Aggiungendo l'eseguibile del gioco alle eccezioni firewall, il gioco potrà accedere ad alcune o tutte le porte di cui necessita per funzionare correttamente. Molti problemi sono così risolti.
Correzione dei problemi con i client enterprise I problemi riscontrati dai giochi sui client enterprise col tempo svaniranno. Il numero di famiglie con più computer e connessione a banda larga è in aumento e c'è una comunità crescente di utenti che eseguono SBS a casa. Ma per adesso, è ancora necessaria una soluzione.
Nel mio caso particolare, ho scoperto che un account utente con limitazioni del sistema locale ha risolto il problema della cartella Documenti reindirizzata. Sia Age of Empires III che Fable: The Lost Chapters funzionano bene come utente con limitazioni finché la cartella Documenti non viene reindirizzata a una cartella di rete.Risorse
  • Quake 3 Buffer Overflow Advisory (in inglese)
  • Windows Vista Application Development Requirements for User Account Control Compatibility (in inglese)
  • Applying the Principle of Least Privilege to User Accounts on Windows XP (in inglese)
  • Strumento LUA Buglight di Aaron Margosis
  • Standard User Analyzer
  • Master Your Own Domain: Build a Corporate Network at Home (in inglese)
  • Problems of Privilege: Find and Fix LUA Bugs (in inglese)
  • Alcuni programmi non funzionano correttamente se si effettua l'accesso con un account utente con limitazioni

Conclusioni
Consiglio vivamente di eseguire il gioco come utente con limitazioni così da poter sfruttare i vantaggi associati all'esecuzione come utente non amministratore. Non è sempre facile giocare in un ambiente con connessione aziendale e privilegi minimi, ma non è impossibile. Negli anni, mi sono imbattuto in moltissimi giochi di ogni genere che funzionano correttamente come utente con limitazioni. E ho scoperto alcune correzioni che fanno funzionare diversi altri titoli. Nel frattempo, grazie alla virtualizzazione in Windows Vista, i giochi che non potevano essere eseguiti come un utente con limitazioni su Windows XP ora funzionano di nuovo.

Matt ClaphamProgram Manager per la sicurezza presso Microsoft, partecipa attivamente alla community di sicurezza IT di Seattle ed è membro del team di gestione dei rischi in un progetto di incubazione IT.


 Dal redattore: Dietro le quinte
Dal redattore
Dietro le quinte

WINDOWS VISTA È EQUILIBRATO per avere un grande impatto sui reparti IT aziendali nel 2007. Come riferito in InformationWeek, una recente relazione di IDC valuta che quest'anno, negli Stati Uniti, saranno creati 100.000 posti di lavoro IT come risultato diretto del "salto di qualità" di Windows Vista. Quest'anno Windows Vista sarà installato su circa 90 milioni di nuovi computer nel mondo e, dal prossimo anno l'80 percento dei nuovi computer forniti alle aziende avrà Windows Vista preinstallato. Nel frattempo, occorre decidere se è tempo di distribuire il sistema operativo nella propria azienda. È possibile fornire supporto.
Il numero di questo mese di TechNet Magazine avvia una serie che offre un esame approfondito di ciò che rende speciale Windows Vista: il kernel. Vero, Windows Vista ha alcune nuove funzionalità piacevoli per l'esperienza dell'utente, ma se questa fosse la ragione principale per eseguire la migrazione, ci sarebbe da preoccuparsi. Il kernel rappresenta il cuore del sistema operativo e sono disponibili dei miglioramenti significativi nel modo in cui il kernel di Windows Vista funziona.
Chi può descrivere queste modifiche meglio di Mark Russinovich, che conosce il kernel di Windows come nessuno al mondo? Il suo libro Windows Internals, scritto insieme a David Solomon, è diventato la principale risorsa per quanti vogliano comprendere cosa accade dietro le quinte.
Questo mese, Mark spiega i miglioramenti apportati all'allocazione della CPU, che rendono le applicazioni desktop più sensibili, quindi descrive come Windows Vista migliora le prestazioni multimediali al livello del kernel. L'articolo esamina anche modifiche importanti nel modello di I/O in Windows Vista, compresi i collegamenti simbolici basati su file, la nuova capacità di annullare le operazioni di I/O sincrone (la modifica principale, a mio avviso), nonché il concetto di priorità di I/O. Nel valutare Windows Vista per la propria organizzazione leggere l'esauriente articolo di Mark.
Naturalmente, ci sono sempre le attività di ogni giorno da svolgere, e potremo essere d'aiuto anche in quelle. Questo numero tratta approfonditamente l'ambito dell'amministrazione di Windows, con articoli sulla delega di autorità in Active Directory, i nuovi modelli di Criteri di gruppo in Windows Vista, la risoluzione dei problemi dei Criteri di gruppo e il monitoraggio di Active Directory con MOM.
Infine, per chi ama utilizzare giochi e mantenere la sicurezza, vale la pena di leggere l'articolo dedicato ai giochi in un ambiente sicuro. È noto cosa si dica sul solo lavoro senza gioco. - JOSHUA TRUPIN

Un ringraziamento agli esperti Microsoft: Matt Ayers, Eugene Bak, Vijay Bharadwaj, Michael Fortin, David Hicks, Khushru Irani, Mehmet Iyigun, Arun Kishan, Mark Lawrence, Pavel Lebedynskiy, Ben Mickle, Michael Murgolo, John Orefice, Ravisankar Pudipeddi, Jeffrey Richter, David Solomon, Jim Truher, Landy Wang e Andy Zeigler.


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

Spostare i dati
SQL Examiner Bundle
www.sqlaccessories.com
A prescindere dal ruolo occupato all'interno di dell'organizzazione (amministratore di database, sviluppatore o figura "jolly"), se si lavora con SQL Server™, probabilmente sarà capitato a molti di dover spostare dati tra ambienti e garantirne l'integrità assicurandosi che le strutture rimanessero intatte. Certo, SQL Server ha molte funzionalità di replica e sincronizzazione incorporate, ma se si sta verificando che il database QA corrisponda esattamente al database di sviluppo, uno strumento quale SQL Examiner Bundle di TulaSoft può avere un valore inestimabile oltre a far risparmiare tempo ed energie.
Bastano pochi clic del mouse e l'applicazione può individuare le discrepanze nella struttura del database o nei dati stessi tra due istanze di database. È sufficiente indicare all'applicazione i database da controllare. Come suggerisce il nome, SQL Examiner Bundle unisce due applicazioni: SQL Examiner e SQL Data Examiner. SQL Examiner analizza la struttura dei database, mentre SQL Data Examiner analizza tutti i dati ed evidenzia eventuali differenze.
SQL Examiner analizza e confronta tutto ciò che è presente nelle istanze di database, dalle tabelle alle procedure memorizzate, ai cataloghi full-text e alle raccolte di schemi XML. Per chi utilizza SQL Server 2005, è possibile eseguire un confronto anche tra gli assembly CLR (Common Language Runtime). Una volta confrontati i database, SQL Examiner consente di scegliere gli oggetti di database da sincronizzare e la direzione di sincronizzazione.
Analisi e confronto dei database con SQL Examiner
Analisi e confronto dei database con SQL Examiner (Fare clic sull'immagine per ridurla)
Analisi e confronto dei database con SQL Examiner
Analisi e confronto dei database con SQL Examiner (Fare clic sull'immagine per ingrandirla)
Una funzionalità molto interessante consente all'applicazione di generare lo script SQL che a sua volta crea un oggetto ed evidenzia la differenza tra i database nello script generato. Questo potrebbe essere un ottimo metodo per evidenziare gli errori che si verificano quando uno script di creazione o migrazione non riesce a creare la struttura del database di destinazione. "Oh, ecco dove avevo lasciato il mio indice cluster!" È possibile eseguire gli script generati singolarmente, salvarli per eseguirli in un secondo momento o fare semplicemente clic sul pulsante Synchronize (Sincronizza) per far sì che l'applicazione lavori per te.
Un'altra funzionalità utile consente di aggiungere esclusioni al confronto, ad esempio ignorare commenti, trigger, indici o proprietà estese di un oggetto. Dopo aver esaminato il confronto delle strutture, SQL Data Examiner consente di esaminare i dati e visualizzare eventuali discrepanze. È possibile scegliere le tabelle, nonché le relative colonne, da confrontare. Una volta completato il confronto delle tabelle di dati, è possibile individuare le righe identiche, le righe diverse e le righe che si trovano solo in uno dei database.
Come con SQL Examiner, SQL Data Examiner consente di fare clic su un pulsante per sincronizzare le tabelle o scegliere selettivamente i dati da trasferire, nonché la direzione del trasferimento. Entrambe le applicazioni consentono di salvare la propria configurazione come progetto, per cui non sarà necessario creare nuovamente le attività ogni volta. Ogni applicazione può essere acquistata separatamente, ma in base alla mia esperienza, scommetto che tutti vorranno acquistarle entrambe.
Prezzo: $299,95 per una licenza per singolo utente.

Cerca file duplicati
zsDuplicateHunter (Professional Edition)
Zizasoft
Se ci si occupa di gestione del desktop, ci si sarà imbattuti sicuramente in un utente che ha esaurito lo spazio disponibile sul proprio computer. Una ricerca rivela che questo utente esegue una copia dei propri documenti ogni volta che apporta una modifica, anche se è stato predisposto un sistema NAS (Network Attached Storage) per la memorizzazione dei file. Oppure, si dispone di un server di registro con processi batch in grado di duplicare i registri di grandi dimensioni, occupando tutto lo spazio sul server assegnato. Una soluzione possibile a questi problemi deriva da zsDuplicateHunter Professional Edition, un programma di ricerca duplicati basato su Java eseguibile in Windows®, Linux o Mac OS X.
L'applicazione consente di eseguire facilmente ricerche in unità, directory o condivisioni di rete oltre a individuare i possibili duplicati. Oltre al confronto dei nomi, l'applicazione consente di raggruppare i file per dimensione, checksum o anche calcolo del digest file per verificare che i file da eliminare siano effettivamente diversi. Infine, non è necessario eliminare definitivamente i duplicati. Come precauzione, l'applicazione consente di spostare tutti i duplicati contrassegnati in una cartella specificata.
Un'altra funzionalità utile è l'opzione "Keep Files in this Folder, Delete Duplicates Elsewhere" (Mantieni i file in questa cartella, elimina i duplicati in altre posizioni) che consente di scegliere la directory di origine pulita ed eliminare le altre presenti sul disco. Tra i risultati di ricerca, è anche possibile fare doppio clic sui file per aprirli con un visualizzatore di file associato, ordinarli e selezionarli per ottenere i risultati esatti di cui si ha bisogno. L'utile funzione "IT pro" (Professionista IT) consente di ottimizzare la quantità di memoria che l'applicazione è autorizzata a occupare mentre cerca i duplicati. Come protezione aggiuntiva, è anche possibile disattivare la ricerca di file nascosti o di sistema per accertarsi di non eliminare nulla di importante né file gestiti dal sistema operativo o da un'altra applicazione.
La Professional Edition fornisce inoltre un filtro granulare per l'insieme di risultati della ricerca, consentendo di applicare un'espressione regolare per trovare i file da eliminare.
Prezzo: $39,95 per una licenza per singolo utente.

Portare le applicazioni con sé
MojoPac
www.mojopac.com
Se si passa spesso da un ambiente a un altro e si sente la mancanza delle proprie impostazioni desktop e delle applicazioni preferite o non si desidera lasciare traccia del proprio passaggio sul desktop di un altro utente, è il caso di provare MojoPac di RingCube Technologies.
Tralasciando i nomi bizzarri, MojoPac consente di portare le proprie impostazioni e applicazioni in qualunque sistema Windows XP (Home, Professional, Media Center o Tablet) su un disco rigido USB, un dispositivo multimediale personale da collegare al sistema host utilizzando USB 2.0, quali Zune o iPod, o anche un telefono cellulare con spazio di archiviazione sufficiente. Quando è stato scritto questo articolo, gli host Windows Vista™ e Windows 2000 non erano supportati, ma dalla documentazione sul sito Web del prodotto si evinceva che sarebbe stato presto disponibile un aggiornamento che supportasse questi sistemi operativi.
Trasferire le proprie impostazioni con MojoPac
Trasferire le proprie impostazioni con MojoPac (Fare clic sull'immagine per ridurla)
Trasferire le proprie impostazioni con MojoPac
Trasferire le proprie impostazioni con MojoPac (Fare clic sull'immagine per ingrandirla)
Attualmente, MojoPac richiede privilegi di amministratore sul sistema host, ma la versione 2.0 (in fase di sviluppo) disporrà del supporto per la modalità utente con limitazioni. Lo strumento fornisce fondamentalmente aiuto ai sistemi operativi host e alle periferiche di archiviazione e, al primo avvio in seguito all'installazione dell'applicazione sul dispositivo portatile, MojoPac consente di avviare la configurazione iniziale dell'account di Windows da eseguire, configurando le impostazioni personali per l'utente MojoPac sul dispositivo MojoPac.
Una volta pronti, il passaggio tra il sistema host e il sistema Mojo è facile: È sufficiente fare clic sulla barra degli strumenti (che può essere ridotta a icona) in alto nella schermata. Le applicazioni sul dispositivo Mojo vengono installate normalmente mentre MojoPac è attivo. Fin quando si tiene conto dell'avviso presente nei documenti readme sull'installazione nella directory predefinita, tutto dovrebbe funzionare.
Tutto sommato, MojoPac può rappresentare una grande risorsa per qualunque professionista IT che si trova a viaggiare e vuole portare con sé la propria installazione. Per esempio, è possibile avere tutte le utilità di sistema, gli sniffer di pacchetti e i monitoraggi del traffico su MojoPac e risolvere i problemi da qualunque computer dell'organizzazione, senza lasciare alcuna traccia.
Prezzo: $49,99 per una licenza per singolo utente.

Recensioni
Administrator’s Guide to SQL Server 2005 (in inglese)
www.aw-bc.com
Sempre più gruppi IT si rendono conto del potenziale e della portata delle funzionalità fornite da SQL Server 2005. Quest'applicazione fornisce diversi miglioramenti utili tra cui il supporto esteso dei dati XML, SQL Server Integration Services (SSIS), a SQL Server 2005 Service Broker. Come supporto per il percorso di aggiornamento o la gestione dell'istanza di SQL Server 2005 appena rilasciata, Buck Woody ha scritto un'eccellente guida di riferimento: Administrator’s Guide to SQL Server 2005 (Addison-Wesley Professional, 2006) (in inglese).
Nel libro vengono fornite informazioni sulle procedure pratiche di gestione applicate alla nuova piattaforma server e, a differenza di molti altri riferimenti disponibili, queste informazioni sono notevolmente concise. Il libro si apre con una sezione sul ridimensionamento dell'infrastruttura per soddisfare le esigenze dell'applicazione e con alcune istruzioni su come scegliere la versione di SQL Server adatta ai diversi scenari. Il testo fornisce inoltre un'idea su come architettare la propria infrastruttura per non trovarsi di fronte a colli di bottiglia delle prestazioni che potrebbero essere evitati nell'installazione.
Vengono poi delineati i diversi strumenti forniti con SQL Server, ad esempio il migliorato SQL Server Profiler e il nuovo SQL Server Management Studio. Vengono inoltre forniti dettagli sulle attività di manutenzione e automazione e su come pianificare una crescita in base alla creazione di profili server e ottenere un piano di manutenzione adeguato alla propria implementazione.
Nel capitolo sulla protezione, viene illustrato anche come proteggere l'installazione, dalla rete all'hardware, attraverso il sistema operativo e l'istanza di SQL Server. Anche qui, vengono fornite informazioni sui servizi di crittografia aggiunta, certificati e gestione chiavi forniti dalla nuova piattaforma.
Un altro capitolo spiega i meccanismi che esistono per assicurare l'alta disponibilità del sistema, in base alle esigenze della propria implementazione. Viene illustrato il clustering, il mirroring di database, la replica e la distribuzione log come metodi per soddisfare i requisiti di tempo di operatività. E con la virtualizzazione che sta diventando un ottimo metodo per ottenere l'alta disponibilità senza il sovraccarico di infrastrutture fisicamente distinte, il libro offre una guida passo passo all'impostazione di un cluster a due nodi utilizzando Microsoft Virtual Server.
Il capitolo dedicato a SSIS mostra come utilizzare lo strumento nuovo (addio DTS!) non solo per sviluppare e distribuire funzioni di estrazione, trasformazione e caricamento (ETL) ma anche come utilizzare i servizi per creare attività di monitoraggio, notifica tramite messaggi di posta elettronica e backup.
Infine, negli ultimi capitoli vengono esaminati i servizi di report e analisi forniti dalla nuova piattaforma SQL Server. Qui viene presentata la progettazione e la creazione di report, la gestione di sistemi di report e tutto ciò che si intende per manutenzione di una distribuzione di servizi di analisi.
Tutto sommato, Administrator’s Guide to SQL Server 2005 è una grande risorsa che consente di snellire l'amministrazione, il monitoraggio e l'aggiornamento a SQL Server 2005.
Prezzo: $49.99.


 SQL: Domande&amp;Risposte: Dimensione del database, mirroring, transazioni contrassegnate e altro
SQL: Domande&Risposte
Dimensione del database, mirroring, transazioni contrassegnate e altro
A cura di Nancy Michell

Trasferimento di un cluster
D Devo trasferire un cluster SQL Server 2000 su nuovi indirizzi IP sia per i server fisici sottostanti sia per i cluster Windows® e SQL Server™. È necessario ricreare l'intera soluzione?
R No, è sufficiente eseguire il programma di installazione di SQL Server e modificare gli indirizzi IP. Di seguito viene indicato l'indirizzo Internet dove poter trovare un articolo della Knowledge Base che spiega come eseguire l'operazione.

Dimensione del database
D SQL Server 2000 SP4 è in produzione con un database di rilevanza cruciale di quasi 10 GB, un modello di recupero con REGISTRAZIONE MINIMA, un file principale di 9.850 MB e un file di log delle transazioni di 88 MB. Anche il backup del database è di quasi 10 GB. Devo ridurre la dimensione del database per migliorare le prestazioni? In tal caso, dovrei utilizzare DBCC SHRINKDATABASE o DBCC SHRINKFILE? (Sfortunatamente, non ci sono orari in cui il traffico è ridotto per poter eseguire questa procedura di manutenzione).
R DBCC SHRINKDATABASE o DBCC SHRINKFILE sono utili solo se il database è sottoposto a molte operazioni di eliminazione e aggiornamento che riducono il volume dei dati. Ma la domanda reale è perché preoccuparsi? Uno spazio su disco di 10 GB oggigiorno può costare $20. Non avrebbe più senso aggiungere altri 100 GB di spazio su disco e farne uso? Le prestazioni peggiorano appena lo spazio diventa più frammentato, ma se non è possibile eseguire operazioni di manutenzione le scelte sono poche. A volte, in casi come questi, alcuni utilizzano una copia secondaria del database. Conservano inoltre una copia di backup aggiornata con la replica, di cui eseguono la manutenzione, quindi indirizzano le applicazioni al backup. Ciò richiede ovviamente la modifica del codice e il cambio del modello di recupero con REGISTRAZIONE MINIMA (in modello di recupero con REGISTRAZIONE COMPLETA o con REGISTRAZIONE MINIMA DELLE TRANSAZIONI DI MASSA) ma può essere una buona soluzione a lungo termine.

Aggiornamento e prestazioni
D Ho bisogno di trasferire due applicazioni da SQL Server 2000 a SQL Server 2005. Come posso evitare l'impatto sulle prestazioni durante l'aggiornamento?
R In genere, le seguenti insidie possono causare un peggioramento delle prestazioni durante l'aggiornamento, quindi è preferibile evitarle:
  1. Le statistiche non sono state ricreate in seguito all'aggiornamento a SQL Server 2005.
  2. Sono presenti clausole JOIN e WHERE che mettono a confronto due diversi tipi di dati, con conseguente peggioramento delle prestazioni, soprattutto se sul server era in esecuzione SQL Server 2000 SP3 o versione precedente (vedere support.microsoft.com/kb/271566/).
  3. L'istanza di SQL Server 2005 non è configurata correttamente; mentre la memoria, la funzionalità AWE (Address Windowing Extensions), i driver e così via sono configurati in modo errato. Il computer che esegue SQL Server 2000 ha subito delle variazioni da parte di una persona che è andata via senza documentare le modifiche apportate, di conseguenza l'operazione non è stata mai eseguita sull'istanza SQL Server 2005.
  4. Difetto dell'hardware. Spesso, si acquista un nuovo hardware perché sembra valido in teoria ma si rivela tutt'altro in pratica.
Prima di utilizzare un'istanza di SQL Server in produzione, occorre stabilire un valore di riferimento delle prestazioni per avere la conferma di poter ottenere le prestazioni previste. Si potrebbe quindi escludere l'infrastruttura come potenziale problema. È necessario esaminare i contatori Perfmon quali Disco, I/O e memoria e confrontarli tra le istanze.

Mirroring del database
D Utilizzo il mirroring del database e voglio attivare l'opzione di database READ_COMMITTED_SNAPSHOT. Quando tento di attivarla dopo aver impostato il mirroring, ricevo un'eccezione che dichiara che il db è in una sessione di mirroring e non è possibile eseguire il comando.
R Ciò accade perché l'impostazione dell'opzione READ_COMMITTED_SNAPSHOT richiede il riavvio del database per rendere operativa la modifica. Pertanto, occorre interrompere la sessione di mirroring, impostare l'opzione e riavviare il database. Completate queste operazioni, è possibile riprendere il mirroring. Una volta avviata la sessione, il database mirror selezionerà l'opzione e la utilizzerà in caso di failover.

D Tento di impostare il mirroring asincrono e ricevo un errore 1418. L'esecuzione di Netstat -ano mostra che SQL Server è in ascolto sulla porta corretta su tutti i server. L'errore viene visualizzato quando tento di avviare il mirroring. Che succede?
R Forse il firewall potrebbe bloccare la comunicazione; si tratta di un problema abbastanza comune che dovrebbe essere esaminato. Per ulteriori informazioni, consultare i seguenti whitepaper: Risoluzione dei problemi relativi all'impostazione del mirroring del database all'indirizzo e MSSQLSERVER_1418.
Da notare che questo problema non è specifico del mirroring asincrono. In realtà, può verificarsi anche con il mirroring sincrono.
L'errore ricevuto ("L'indirizzo di rete del server "%.*ls" non è raggiungibile o non esiste. Controllare il nome dell'indirizzo di rete e ripetere il comando") è corretto. Spesso accade che il partner remoto esiste ma non è raggiungibile.
Questo può accadere se il partner remoto non è attivo, non è in ascolto sulla porta o anche se l'endpoint non è attivo (il che potrebbe verificarsi se i partner non possono negoziare lo stesso meccanismo di crittografia o riscontrano altri problemi di autenticazione). Può verificarsi anche se il partner è bloccato, a causa del firewall del partner che ha avviato il comando.
Altri problemi che probabilmente si vorranno escludere sono quelli inerenti il nome origine dati (DSN, Data Source Name) e la risoluzione nomi. Generalmente, è preferibile utilizzare i nomi dominio completi. Quindi, nonostante spesso il problema potrebbe essere il firewall stesso, non dimenticare che le cause potenziali sono molte.

D Desidero utilizzare il mirroring di SQL Server 2005; tuttavia, ho sentito che è sconsigliato in caso di più applicazioni che si collegano a più database sulla stessa istanza di SQL Server. È vero?
R La risposta in realtà dipende da diversi fattori, ad esempio se ogni applicazione dispone del proprio database, se le applicazioni utilizzano transazioni tra database o Distributed Transaction Coordinator (DTC). Se vengono utilizzate transazioni tra database, il mirroring potrebbe presentare incongruenze logiche in cui le transazioni non vengono sottoposte a commit come previsto. Una spiegazione esauriente relativamente a quanto accade in queste circostanze è disponibile alla pagina
In caso di più database utilizzati da più applicazioni, con ciascuna applicazione che dispone del proprio database, il mirroring non causa questi problemi.

Transazioni contrassegnate
D Cosa sono esattamente le transazioni contrassegnate? Possono essere utilizzate con un database SQL Server e un database Oracle insieme?
R Una transazione contrassegnata è un'operazione eseguita periodicamente dal DBA per applicare un contrassegno nello stesso punto in tutti i log. Questa azione, insieme alla capacità di ripristinare una tabella in corrispondenza di un contrassegno di transazione, consente di ripristinare tutti i database allo stesso punto. Questa operazione può essere estremamente sgradevole in quanto si devono ripristinare tutti i database interessati, perdendo tutti i dati in essi contenuti, pertanto sarebbe meglio evitarla assicurandosi di non perdere i file di log. Le transazioni contrassegnate sono specifiche di SQL Server, quindi se le transazioni distribuite contengono dei database diversi da SQL Server, non possono prendere parte al contrassegno della transazione. In generale, pochissimi sistemi di database distribuiti utilizzano i contrassegni di transazione. La perdita di uno dei log delle transazioni sarebbe un evento catastrofico che richiederebbe molto lavoro manuale per il ripristino.

Strumento di conversione da Access a T SQL
D È disponibile uno strumento automatico per convertire Access™-SQL in T-SQL per le stored procedure?
R Provare SQL Server Migration Assistant (SSMA) for Access, che può essere scaricato dal sito Allo stesso indirizzo, sono disponibili anche SQL Server Migration Assistant for Oracle, SQL Server Migration Assistant for Sybase e Migrating Informix Databases to Microsoft® SQL Server 2000.
Per l'upsize da Access a SQL Server, è possibile utilizzare Office Upsizing Wizard, ma SSMA for Access, mostrato nella Figura 1, dispone di più funzionalità, tra cui report di valutazione conversione e scansione della rete. SSMA for Access corregge anche molti problemi che al momento non sono gestiti correttamente da Office Upsizing Wizard.
Figura 1. SQL Server Migration Assistant (SSMA) for Access
Figura 1. SQL Server Migration Assistant (SSMA) for Access (Fare clic sull'immagine per ridurla)
Figura 1. SQL Server Migration Assistant (SSMA) for Access
Figura 1. SQL Server Migration Assistant (SSMA) for Access (Fare clic sull'immagine per ingrandirla)

Indici non raggruppati
D Ho una tabella la cui chiave primaria è composta da due GUID (GUID1 e GUID2). Già dispongo di un indice raggruppato univoco su GUID1 e GUID2. Ora, per motivi di prestazioni, vorrei creare un secondo indice non raggruppato su GUID2 e GUID1. Le prestazioni potrebbero rallentarsi se dichiaro l'indice come univoco?
R Le prestazioni non verranno penalizzate se si dichiara l'indice non raggruppato come univoco. In realtà, in questo modo si riducono i livelli della struttura dell'indice.
Quando un indice non raggruppato viene dichiarato non univoco, l'indicatore di posizione delle righe viene aggiunto alla porzione principale delle voci di indice nelle pagine principali e non foglia. Lo scopo è di semplificare l'eliminazione e l'aggiornamento delle voci di indice, evitando la scansione di una catena di sinonimi in presenza di duplicati per una chiave. La voce specifica da modificare può essere individuata da un'operazione di ricerca nel sistema sul localizzatore chiavi avanzato. Ne consegue che quelle voci sono più lunghe (considerevolmente, con la chiave del cluster scelta). Di conseguenza, le pagine principali e non foglia verranno naturalmente compilate con più rapidità. Se l'indice è univoco, dovrebbe essere dichiarato come tale.
Il punto è questo: a prescindere che la tabella abbia un indice raggruppato o meno, per qualsiasi indice non raggruppato sulla tabella che non viene dichiarato univoco, verrà aggiunto un indicatore alle voci di indice nelle pagine principali e non foglia.
Per di più, se si utilizza una colonna identificatore int come chiave surrogata e si aggiungono due indici univoci (GUID1, GUID2) e (GUID2, GUID1), in questo modo, probabilmente, le prestazioni miglioreranno poiché gli indici avranno una chiave di clustering di 4 byte anziché di 32 byte.

Blocchi di aggiornamenti
D Ho una stored procedure con la seguente struttura:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
Questa stored procedure consente a un solo chiamante di assumere il blocco, lasciando tutti gli altri in attesa. Posso ottenere lo stesso funzionamento riducendo il livello di isolamento?
Sembra che READ COMMITTED sia il livello di isolamento corretto perché questa transazione presenta solo una query e se altre transazioni si trovano nel processo di aggiornamento dello stesso record, questa transazione attende l'altra. È vero?
R Non è l'impostazione serializzabile di questo esempio che fa attendere gli altri chiamanti: è l'aggiornamento stesso. Sì, è possibile impostare il livello di isolamento su READ COMMITTED e l'aggiornamento utilizzerà naturalmente un blocco aggiornamento su qualsiasi indice che utilizza. Questo comporta dei problemi per gli altri processi che eseguono la stessa istruzione, i quali verranno bloccati fino al completamento dell'aggiornamento. (Inoltre, se l'aggiornamento rappresenta l'unica istruzione, la transazione esplicita non è necessaria; ciascuna istruzione si trova implicitamente nella propria transazione se non si trova in una esplicita).
Tuttavia, in assenza di righe corrispondenti alla clausola WHERE nell'istruzione UPDATE, l'uso del livello di isolamento serializzabile impedisce l'inserimento o la modifica di questo tipo di righe in altre transazioni. Se l'istruzione UPDATE fosse stata eseguita nel livello di isolamento READ COMMITTED, questo non sarebbe accaduto e le altre transazioni avrebbero potuto inserire righe qualificate per l'aggiornamento. Se il codice di stored procedure è identico al codice mostrato, non ha senso eseguire queste azioni (serializzabile o transazione); è sufficiente eseguire l'aggiornamento.

Si ringraziano i seguenti professionisti IT di Microsoft per la propria esperienza tecnica: Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip e Frankie Yuen.


 Utilit&#224; sotto i riflettori: Inventario dei criteri di gruppo
Utilità sotto i riflettori
Inventario dei criteri di gruppo
Grog Steen
Scarica il codice per questo articolo: GPInventory.exe (150KB)

COME PUOI RICORDARTI di quello che hai se non ne tieni traccia? Avere a portata di mano i dettagli del proprio inventario può essere di grande aiuto nella gestione delle riunioni sull'assegnazione del budget e dei controlli annuali. E naturalmente, i capi vogliono sapere sempre chi ha cosa e perché e quanto tempo ci vorrà per eseguire un aggiornamento.
Uno strumento che può rivelarsi utile in questi casi è Group Policy Inventory (GPInventory.exe), integrato nel Resource Kit di Microsoft Windows Server® 2003. Questo programma consente di ricercare e recuperare le informazioni di sistema tramite query RSOP (Resultant Set of User Policy) e/o WMI (Windows® Management Instrumentation) da host remoti multipli, come indicato nella figura. Ovviamente il programma recupera facilmente le informazioni sui Criteri di gruppo ma consente anche di estrarre informazioni di sistema dettagliate, ad esempio le applicazioni installate, il nome e la velocità del processore o l'elenco degli aggiornamenti rapidi installati. E non è finita qui! Poiché fa parte del Resource Kit di Microsoft Windows Server® 2003, è completamente gratuito.
Figura 1 Utilizzo di GPInventory per la raccolta di informazioni
Figura 1 Utilizzo di GPInventory per la raccolta di informazioni (Fare clic sull'immagine per ridurla)
Figura 1 Utilizzo di GPInventory per la raccolta di informazioni
Figura 1 Utilizzo di GPInventory per la raccolta di informazioni (Fare clic sull'immagine per ingrandirla)
Esiste più di un modo per utilizzare GPInventory.exe. Ad esempio, se si desidera verificare lo stato della garanzia, è possibile raccogliere i numeri di serie o di servizio dei computer dalla rete senza doverli estrarre da ogni singola casella. E ancora, se ci si trova in un ambiente di laboratorio e si desidera sapere se una macchina è attualmente in uso, è possibile rivolgersi agli utenti registrati attualmente nel sistema senza muoversi dalla propria postazione. Se è impostato un blade server su cui vengono scaricate regolarmente immagini (ad esempio, per ripulire e ripristinare il proprio ambiente QA), è possibile verificare la data di installazione del computer per sapere quando è stata applicata l'ultima immagine.
GPInventory è inoltre molto facile da utilizzare. Basta puntarlo sul file contenente l'elenco dei computer di cui creare l'inventario, selezionare le query da eseguire e quindi elaborare l'elenco. Questo strumento si connette ad ogni computer dell'elenco ed esegue le query. In caso di una query rapida, è inoltre possibile selezionare i computer direttamente da Active Directory® e le azioni di query da eseguire dal menu Query.
Per eseguire una query RSOP su un computer, è necessaria l'autorizzazione Genera gruppo di criteri risultante (Registrazione), di cui i gruppi Domain Admins e Delegate Admins dispongono per impostazione predefinita. Le query WMI richiedono i diritti amministrativi nel computer remoto, a meno che non si utilizzi lo snap-in MMC del Controllo WMI per la concessione dei diritti Abilita account e Abilita remoto sullo spazio dei nomi root\cimv2 a un utente alternativo.
Dopo avere eseguito la query, è possibile salvare i risultati come file di testo delimitato da tabulazione o XML. Entrambi possono essere poi importati in Microsoft® Excel® per l'analisi. È possibile ordinare ed applicare un filtro automatico per trovare tutti i dettagli.
GPInventory supporta inoltre l'esecuzione sulla riga di comando, pertanto è facile configurare un'operazione pianificata per richiedere informazioni di sistema e salvarle direttamente in un file XML senza l'intervento tramite GUI. Ciò può essere molto utile per query con esecuzione prolungata, che meglio si adattano a un'esecuzione in periodi di inattività.
Lo strumento dispone di una serie predefinita di query RSOP e WMI, tuttavia è possibile aggiungere, modificare e aggiornare il file di query con un elenco personalizzato, secondo le proprie esigenze. Il documento Guida fornito indica come definire una nuova query nel file XML di elenco query.
GPInventory.exe è uno strumento eccezionale per raccogliere informazioni su computer che utilizzano Windows in tutta la rete, per inventari, criteri di gruppo o informazioni sullo stato. Troverai un collegamento allo strumento Group Policy Inventory nella sezione download del nostro sito Web.

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


 The Cable Guy: Supporto QoS in Windows
The Cable Guy
Supporto QoS in Windows
Joseph Davies
Questo articolo si riferisce a una versione preliminare di Windows Server, "Longhorn". Tutte le informazioni qui contenute potrebbero essere soggette a modifiche.

La qualità del servizio (QoS) comprende una serie di tecnologie per gestire in modo economico il traffico di rete in modo da migliorare le procedure utente in ambienti aziendali e domestici. Le tecnologie QoS consentono di misurare la larghezza di banda, rilevare le variazioni nelle condizioni della rete (come congestione o disponibilità di larghezza di banda)
e aumentare la priorità o diminuire la velocità del traffico. Ad esempio, è possibile applicare la qualità del servizio (QoS) per assegnare la priorità alla distribuzione di traffico sensibile a latenza (come applicazioni video e voce) e controllare l'impatto del traffico non sensibile a latenza, come il trasferimento di dati per operazioni di massa. Il recapito con priorità per il traffico TCP/IP richiede il supporto di host e dispositivi infrastruttura di rete. In questo articolo vengono descritti i metodi per utilizzare QoS con host basati su Microsoft® Windows®.
Il problema principale relativo alla definizione di QoS per reti TCP/IP riguarda il modo in cui specificare e fornire il recapito con priorità di traffico IP. Sebbene RFC 791 per IP originale abbia definito il campo Tipo di servizio (TOS, Type of Service) con la capacità di specificare le caratteristiche di precedenza, ritardo, velocità effettiva, affidabilità e costo, IP è fondamentalmente una tecnologia di commutazione pacchetti basata sui datagrammi e di massimo sforzo che generalmente si occupa di ogni pacchetto allo stesso modo, in base al principio del primo arrivato.

Configurazione del recapito con priorità
Per fornire il servizio di recapito con priorità, sono poche le cose da fare. È possibile configurare l'infrastruttura di rete per offrire una gestione speciale per il traffico contrassegnato, quindi fare in modo che gli host mittenti contrassegnino il proprio traffico in uscita. In alternativa, è possibile far programmare dinamicamente l'infrastruttura di rete agli host mittenti, così da offrire una gestione speciale basata sulle caratteristiche del relativo traffico in uscita (come indirizzi e numeri di porta).
Per il traffico TCP/IP, è possibile utilizzare diversi metodi per fornire la funzione di recapito con priorità. Ad esempio, al livello di interfaccia di rete per Ethernet, la codifica IEEE 802.1p contrassegna i frame inviati da un host per la funzione di recapito con priorità utilizzando un campo di priorità a 3 bit nell'intestazione VLAN (Virtual Local Area Network, rete locale virtuale) del frame Ethernet. L'intestazione VLAN si trova nell'intestazione Ethernet, tra il campo Indirizzo origine e il campo Lunghezza (per un frame IEEE 802.3) o il campo EtherType (per un frame Ethernet II).
L'implementazione della codifica 802.1p su un host mittente richiede che la scheda di rete e il driver di periferica supportino 802.1p e che il supporto 802.1p della scheda di rete sia attivato. Generalmente, il supporto 802.1p può essere attivato sulla scheda Avanzate dalle proprietà di un driver scheda di rete. È necessario che sia attivato anche il supporto 802.1p degli switch Ethernet.
Al livello di interfaccia di rete per connessioni senza fili IEEE 802.11, la certificazione della Wi-Fi Alliance per Wi-Fi Multimedia (WMM) definisce quattro categorie di accesso per definire la priorità del traffico di rete. Queste categorie di accesso sono (dal grado di priorità più alto al più basso) voce, video, massimo sforzo e background. Il supporto host per la definizione della priorità WMM richiede che entrambe le schede di rete senza fili e i relativi driver supportino WMM. I punti di accesso (Access Point, AP) senza fili richiedono l'attivazione di WMM.
Al livello Internet, è possibile utilizzare i Servizi differenziati e impostare il valore di DSCP (Differentiated Services Code Point) nell'intestazione IP. Come definito in RFC 2472, il valore DSCP è rappresentato dai 6 bit di alto livello del campo TOS di IP Versione 4 (IPv4, IP version 4) e del campo Classe di traffico di IP Versione 6 (IPv6, IP version 6).
I più moderni router aziendali supportano la differenziazione del traffico DSCP ma, per impostazione predefinita, generalmente tale funzione è disattivata. Durante l'inoltro, i router che supportano DSCP leggono il valore di DSCP e collocano il pacchetto in una coda specifica. Ad esempio, è possibile configurare i router per collocare i pacchetti inoltrati in code a priorità alta, con massimo sforzo o inferiori a massimo sforzo, in base ai valori di DSCP definiti. Configurando le code e i valori di DSCP, il traffico contrassegnato DSCP può avere livelli di servizio differenziati. Ad esempio, il traffico di rete di importanza critica viene inoltrato per primo e non viene ritardato da altro traffico dati per operazioni di massa di priorità inferiore. La specifica WMM definisce in che modo le categorie di accesso WMM vengono mappate sui valori di DSCP. Un AP senza fili che supporta WMM legge il valore di DSCP e gestisce il traffico in base alla relativa categoria di accesso.
Al livello Internet, è possibile utilizzare anche RSVP (Resource Reservation Protocol), un protocollo di segnale definito in RFC 2205. Gli host possono utilizzare questo protocollo per tentare di riservare larghezza di banda attraverso la rete per un endpoint. Tuttavia, RSVP non ha larga diffusione sulla rete e al momento non è supportato in Windows XP, Windows Server® 2003, Windows Vista™ né nella versione successiva di Windows Server, nome in codice "Longhorn" (attualmente in fase beta).
Per inviare pacchetti contrassegnati per il recapito con priorità, applicazioni o componenti del sistema operativo è necessario specificare i valori della priorità 802.1p o il valore di DSCP. Nelle sezioni successive verrà descritto in che modo i componenti di Windows o le applicazioni basate su Windows possono specificare la priorità 802.1p per frame Ethernet o il valore di DSCP per il traffico TCP/IP.

QoS in Windows XP e Windows Server 2003
Windows XP e Windows Server 2003 forniscono le API per assegnare i parametri QoS al traffico. Gli sviluppatori di applicazioni possono utilizzare le API Winsock (Windows Sockets) e GQoS (Generic QoS) per applicare parametri QoS a livello di applicazione per singoli socket. Gli amministratori di rete possono utilizzare gli strumenti di gestione del traffico scritti per richiedere all'API TC (Traffic Control) di applicare i parametri QoS a livello host.
È possibile utilizzare Winsock e l'opzione socket IP_TOS per impostare il valore di DSCP per i pacchetti in uscita per un socket. Tuttavia, per impostazione predefinita, lo stack TCP/IP ignora l'opzione socket IP_TOS. Per utilizzare l'opzione socket IP_TOS, occorre per prima cosa creare e impostare il valore del Registro di sistema DWORD DisableUserTOSSetting=0 nella seguente chiave del Registro di sistema (vedere la Figura 1):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Figura 1 Impostazione del valore del Registro di sistema di DisableUserTOSetting
Figura 1 Impostazione del valore del Registro di sistema di DisableUserTOSetting
Riavviare il computer per applicare questa impostazione del Registro di sistema.
Per specificare il valore di DSCP per il traffico senza dover utilizzare l'opzione socket IP_TOS, utilizzare l'API GQoS. GQoS fa parte di Windows Sockets 2.0 (Winsock2). La maggior parte delle applicazioni abilitate all'utilizzo di QoS adoperano l'API GQoS per richiamare le funzionalità di QoS in Windows. GQoS in Windows XP Service Pack 2 (SP2) consente a un'applicazione di impostare un valore di DSCP, rallentandone il traffico in uscita. Per impostare le priorità 802.1p su computer che eseguono Windows XP SP2, occorre utilizzare l'API TC.
L'API TC consente di accedere ai meccanismi di controllo del traffico che regolano il traffico di rete sull'host locale. Consente inoltre di controllare direttamente i valori di DSCP, le codifiche 802.1p e la velocità. Gli amministratori di rete possono utilizzare i programmi di gestione del traffico per richiamare direttamente l'API TC per conto di applicazioni non compatibili con QoS. Dal momento che si tratta di un'API di livello inferiore rispetto all'API GQoS, l'API TC richiede privilegi di amministratore.
A differenza dell'API GQoS, l'API TC consente di aggregare il traffico proveniente da più applicazioni sullo stesso host mittente in un unico flusso QoS. Come parte di questa aggregazione, il traffico può essere identificato da una combinazione dei relativi indirizzi IP di origine e destinazione, porte di origine e destinazione e protocollo (TCP o UDP). Ad esempio, tutto il traffico inviato a un indirizzo IP di destinazione specifico può essere incluso in un unico flusso QoS per qualsiasi porta di origine e destinazione, a prescindere dall'applicazione mittente sull'host. L'API GQoS, d'altra parte, consente a un'applicazione di definire la propria gestione QoS sui dati inviati attraverso un socket.
Per supportare la funzionalità QoS, i computer basati su Windows XP e Windows Server 2003 devono avere il componente Utilità di pianificazione pacchetti QoS installato e attivato dalle proprietà delle connessioni di rete nella cartella Connessioni di rete (vedere la Figura 2). Per impostazione predefinita, il componente Utilità di pianificazione pacchetti QoS (Psched.sys) è installato e attivato per i computer che eseguono Windows XP. Il componente Utilità di pianificazione pacchetti può essere installato in Windows Server 2003.
Figura 2 Configurazione di Utilità di pianificazione pacchetti QoS
Figura 2 Configurazione di Utilità di pianificazione pacchetti QoS

QoS in Windows Vista e Windows Server "Longhorn"
Il supporto QoS in Windows Vista e Windows Server "Longhorn" è stato migliorato e semplificato. Per il personale IT, è ora possibile utilizzare QoS basata su criteri per impostare i valori di DSCP e controllare la velocità di invio dell'applicazione senza dover utilizzare API o modificare applicazioni esistenti. Per gli sviluppatori, le API GQoS e TC sono supportate, sebbene il supporto per queste API non sia pianificato per le future versioni di Windows. Inoltre, l'opzione IP_TOS Winsock è stata rimossa. Per sostituire le API GQoS e TC e semplificare il supporto QoS in applicazioni aggiornate o future, Windows Vista e Windows Server "Longhorn" supportano la nuova API QoS2, nota anche come Servizio audio/video Windows di qualità (qWAVE).
QoS basata su criteri in Windows Server "Longhorn" e Windows Vista consente di offrire un miglior servizio all'utente finale, controllare i costi di larghezza di banda o negoziare livelli di servizio di qualità superiore con provider di larghezza di banda o reparti. È possibile gestire in modo centralizzato la larghezza di banda della rete di computer che eseguono Windows Vista o Windows Server "Longhorn" indipendentemente dall'applicazione e in tutta l'infrastruttura Active Directory®. Dal momento che la gestione del traffico avviene sotto il livello applicazione, le applicazioni esistenti non devono essere modificate per la gestione del traffico di QoS basata su criteri.
Le impostazioni di QoS basata su criteri in Windows Server "Longhorn" e Windows Vista consentono di assegnare la priorità e gestire il traffico in uscita in base alle seguenti condizioni:
  • Applicazione mittente (percorso e nome eseguibile)
  • Prefissi indirizzo o indirizzi IPv4 o IPv6 di origine o destinazione
  • Protocollo (TCP, UDP o entrambi)
  • Porte di origine o destinazione o intervalli di porte (TCP o UDP)
I criteri di QoS vengono applicati a una sessione di accesso utente o a un computer come parte di un oggetto Criteri di gruppo (GPO) collegata a un contenitore Active Directory come un dominio, un sito o un'unità organizzativa (UO) o possono essere applicati a un gruppo di protezione. Come parte di Criteri di gruppo, i criteri di QoS sono basati sull'infrastruttura di gestione esistente di Active Directory.
QoS basata su criteri consente di definire la priorità di traffico. È possibile configurare un criterio di QoS per contraddistinguere il traffico IPv4 o IPv6 in uscita con uno specifico valore di DSCP. Inoltre, è possibile gestire l'uso della larghezza di banda per il traffico in uscita. È possibile configurare un criterio di QoS con una limitazione della velocità per il traffico in uscita. Con la limitazione della velocità, i componenti di QoS limitano il traffico di rete in uscita aggregato a una precisa velocità. Per i computer, è possibile gestire l'uso della larghezza di banda per il traffico in entrata configurando le impostazioni avanzate in modo da specificare la velocità del traffico TCP in entrata impostando un valore massimo per la dimensione della finestra di ricezione TCP.
In Windows Vista e Windows Server "Longhorn", l'Utilità di pianificazione pacchetti QoS è installata e attivata per impostazione predefinita. Il componente Pacer.sys è un nuovo driver filtro leggero NDIS (Network Device Interface Specification) 6.0 che controlla la pianificazione dei pacchetti per QoS basata su criteri e per il traffico di applicazioni abilitate all'utilizzo di QoS. Pacer.sys sostituisce Psched.sys in Windows XP e Windows Server 2003.
Per distribuire QoS basata su criteri sulla Intranet, configurare i criteri di QoS basati su computer o su utente e applicarli al contenitore Active Directory appropriato. I computer basati su Windows Vista o Windows Server "Longhorn" scaricano e applicano le relative impostazioni di QoS basata su criteri durante l'aggiornamento dei criteri di gruppo di configurazione del computer o di configurazione dell'utente.
Sulle reti vengono spesso elaborati sia dati che applicazioni audio/video (AV), quindi è necessaria una soluzione di QoS che attribuisca una priorità al traffico AV legato ai tempi rispetto al traffico di dati. Inoltre, le reti tendono sempre più a divenire wireless, con la conseguente introduzione di ulteriori complicazioni per le applicazioni sensibili a latenza e larghezza di banda disponibile.
La funzione qWAVE in Windows Vista fornisce una raccolta di moduli di software per la QoS che risolvono i problemi di rete introdotti dalle applicazioni AV e dalle reti senza fili. qWAVE è integrato nel sottosistema QoS e funziona su più tecnologie per la definizione delle priorità dei pacchetti a livello di interfaccia di rete e Internet. qWAVE supporta contemporaneamente più flussi di AV (flussi in tempo reale che richiedono QoS) e flussi di dati (flussi di massimo sforzo, come trasferimenti di posta elettronica o file).
Con le tecnologie qWAVE viene rilevata e monitorata la larghezza di banda della LAN, vengono individuate le caratteristiche di QoS della rete e viene garantito il controllo di ammissione distribuito per uno sfruttamento corretto e coerente della larghezza di banda della rete. Tali tecnologie consentono di utilizzare le tecniche di streaming AV più avanzate, in modo che le applicazioni possano adattarsi in modo dinamico alle diverse condizioni della rete e sono disponibili agli sviluppatori solo dall'API QoS2.
L'API QoS2 in Windows Vista e Windows Server "Longhorn" sostituisce l'API GQoS e l'opzione IP_TOS Winsock, quindi dovrebbe essere più facile da utilizzare rispetto all'API GQoS.

Ulteriori informazioni
Per ulteriori informazioni su QoS, Technet mette a disposizione diversi documenti molto utili. Inizia dal sito Web Microsoft Quality of Service (in inglese). Consulta anche la sezione QoS del Windows Core Networking (in inglese).

Joseph Daviesè un technical writer di Microsoft. Dal 1992 tiene corsi e scrive su argomenti legati alle reti Microsoft. Ha scritto cinque libri per Microsoft Press® ed è autore della rubrica mensile Cable Guy su TechNet.


 Windows PowerShell: Creare script una riga alla volta
Windows PowerShell
Creare script una riga alla volta
Don Jones

Nei precedenti articoli ho spesso insistito sul fatto che Windows PowerShell è una shell. È fatta per essere utilizzata in modo interattivo come la shell (o prompt dei comandi) cmd.exe che probabilmente tutti conoscono. Ma Windows PowerShell supporta anche un linguaggio di script più robusto del linguaggio batch di cmd.exe e potente
quanto i linguaggi come VBScript, se non di più. Tuttavia il fatto che Windows PowerShell™ sia una shell interattiva rende la creazione di script molto facile da imparare. In pratica è possibile sviluppare script in modo interattivo all'interno della shell, il che consente di creare gli script una riga alla volta e vedere immediatamente il risultato del proprio lavoro.
Questa tecnica di creazione degli script iterativa facilita anche il debug. Poiché si vedono subito i risultati dello script, è possibile apportare modifiche o correzioni rapidamente quando qualcosa non funziona come previsto.
In questo articolo presenterò un esempio di creazione interattiva di script in Windows PowerShell. Creerò uno script che legge nomi di servizi da un file di testo e imposta la modalità di avvio di ogni servizio su Disattivato.
Quello che mi interessa sia chiaro è il concetto di creare script in Windows PowerShell a pezzetti, invece di cercare di affrontare l'intero script in un solo colpo. È possibile suddividere qualsiasi attività amministrativa si debba eseguire nei suoi componenti e poi stabilire come far funzionare ogni pezzo separatamente. Come vedremo in seguito, Windows PowerShell dispone di ottimi modi per legare insieme tutti questi pezzi. Lavorando su piccole porzioni alla volta, sviluppare lo script finale risulterà più facile.

Lettura di nomi da un file
Scoprire come leggere i file di testo in Windows PowerShell può richiedere pazienza. Se eseguo Help *file*, ottengo semplicemente la guida per il cmdlet Out-File, che invia testo a un file invece di leggerlo dal file. E questo non mi aiuta. I nomi dei cmdlet di Windows PowerShell però hanno una loro logica che posso sfruttare a mio vantaggio. Quando Windows PowerShell recupera qualcosa, il nome del cmdlet normalmente comincia con Get. Eseguo quindi Help Get* per visualizzare questi cmdlet e poi scorro nell'elenco per cercare Get-Content. Sembra promettente! Allora eseguo Help Get-Content per sapere cosa succede (Figura 1) e sembra proprio quello che mi serve.
Figura 1 Esecuzione di Help Get-Content per ottenere ulteriori informazioni
Figura 1 Esecuzione di Help Get-Content per ottenere ulteriori informazioni (Fare clic sull'immagine per ridurla)
Figura 1 Esecuzione di Help Get-Content per ottenere ulteriori informazioni
Figura 1 Esecuzione di Help Get-Content per ottenere ulteriori informazioni (Fare clic sull'immagine per ingrandirla)
Windows PowerShell considera quasi tutto come un oggetto e i file di testo non fanno eccezione. Tecnicamente un file di testo è un insieme di righe, ciascuna delle quali si comporta come un oggetto indipendente. Di conseguenza, se ho creato un file di testo denominato C:\services.txt e vi ho inserito nomi di servizi (ponendo ogni nome su una riga separata all'interno del file), Windows PowerShell può leggere i singoli nomi utilizzando il cmdlet Get-Content. Poiché lo scopo di questa presentazione è dimostrare la creazione interattiva di script, per cominciare mi limiterò ad eseguire Get-Content, assegnarvi il nome del file di testo e vedere cosa succede:
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
Come previsto, Windows PowerShell legge il file e ne visualizza il nome. Naturalmente non voglio solo visualizzare i nomi, ma ora so che Get-Content funziona come mi aspettavo.

Modifica di un servizio
La prossima cosa da fare è modificare la modalità di avvio di un servizio. Di nuovo, per prima cosa devo trovare il cmdlet giusto. Quindi eseguo Help *Service*. Viene visualizzato un elenco breve e il cmdlet Set-Service sembra l'unico adatto alle mie necessità. Voglio testare questo cmdlet per essere sicuro di capire come funziona prima di incorporarlo in uno script. Help Set-Service mostra il funzionamento previsto del cmdlet e basta fare un rapido test per conferma:
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

Combinazione delle parti
A questo punto devo combinare la possibilità di leggere i nomi dei servizi da un file con il cmdlet Set-Service e qui entrano in gioco le potenti funzionalità di pipeline di Windows PowerShell. Con la pipeline, l'output di un cmdlet può essere inoltrato come input a un secondo cmdlet. La pipeline inoltra oggetti interi. Se si inserisce nella pipeline un insieme di oggetti, la pipeline inoltra ogni oggetto separatamente. Questo significa che l'output di Get-Content, che come ricorderemo è un insieme di oggetti, può essere inviato a Set-Service attraverso la pipeline. Poiché Get-Content inoltra un insieme, ogni oggetto (o riga di testo) dell'insieme viene inoltrato separatamente a Set-Service. Il risultato è che Set-Service viene eseguito una volta per ogni riga del file di testo. Il comando è simile al seguente:
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
Ed ecco cosa succede:
  1. Il cmdlet Get-Content viene eseguito e legge l'intero file. Ogni riga del file viene considerata come un oggetto separato che con gli altri forma un insieme di oggetti.
  2. L'insieme di oggetti viene inviato a Set-Service attraverso la pipeline.
  3. La pipeline esegue il cmdlet Set-Service una volta per ogni oggetto di input. Per ogni esecuzione, l'oggetto di input viene inoltrato a Set-Service come primo parametro del cmdlet, che è il nome del servizio.
  4. Set-Service viene eseguito utilizzando l'oggetto di input come primo parametro e gli eventuali altri parametri specificati, in questo caso il parametro -startuptype.
La cosa interessante è che a questo punto ho già ottenuto il mio scopo e non ho ancora creato uno script. Questa stessa azione sarebbe difficile da eseguire nella shell Cmd.exe e richiederebbe decine di righe di codice in VBScript. Windows PowerShell invece fa tutto con una riga sola. Però, non ho ancora finito. Come si vede, il comando non fornisce molte informazioni di stato o feedback. A parte l'assenza di errori, è difficile vedere se effettivamente è successo qualcosa. Ora che ho acquisito dimestichezza con la funzionalità necessaria per eseguire l'attività in questione, posso iniziare a migliorarla passando alla vera e propria creazione di uno script.
Windows PowerShell Prompt Here di Michael Murgolo (in inglese)
Uno dei più famosi Microsoft® PowerToys for Windows® e uno dei miei preferiti è lo strumento Open Command Window Here (Apri finestra di comando qui). Disponibile tra i Microsoft PowerToys for Windows XP o negli strumenti del Resource Kit di Windows Server® 2003, Open Command Window Here consente di fare clic con il pulsante destro del mouse su una cartella o un'unità disco in Esplora risorse per aprire una finestra di comando impostata sulla cartella selezionata.
Mentre stavo approfondendo la mia conoscenza su Windows PowerShell, mi sono trovato a desiderare che avesse la stessa funzionalità. Allora ho preso il file .inf di configurazione di Open Command Window Here, cmdhere.inf, dagli strumenti del Resource Kit di Windows Server 2003 e l'ho modificato per creare un menu di scelta rapida "Windows PowerShell Prompt Here". Questo file .inf si trova nel post di blog originale sul quale si basa questo articolo (disponibile all'indirizzo leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx). Per installare lo strumento basta fare clic con il pulsante destro del mouse sul file .inf e selezionare Installa.
Mentre creavo la versione per Windows PowerShell di questo strumento, ho scoperto un bug nell'originale: se si disinstallava Open Command Window Here, rimaneva una voce del menu di scelta rapida attiva. Quindi ho creato una versione aggiornata di cmdhere.inf, anch'essa disponibile nel post di blog originale.
Entrambi questi PowerToys sfruttano il fatto che queste voci del menu di scelta rapida sono configurate nel Registro di sistema all'interno delle chiavi associate ai tipi di oggetto Directory e Drive, nello stesso modo in cui le azioni del menu di scelta rapida sono associate ai tipi di file. Ad esempio, quando si fa clic con il pulsante destro del mouse su un file .txt in Esplora risorse, all'inizio dell'elenco vengono visualizzate diverse azioni (ad esempio Apri, Stampa e Modifica). Per capire come sono state configurate queste voci, esaminiamo l'hive del Registro di sistema HKEY_CLASSES_ROOT.
Aprendo l'editor del Registro di sistema ed espandendo HKEY_CLASSES_ROOT, vengono visualizzate le chiavi con i nomi dei tipi di file come .doc, .txt e così via. Facendo clic sulla chiave .txt, si vede che il valore (Default) è txtfile (vedere la Figura A). Questo è il tipo di oggetto associato a un file .txt. Scorrendo verso il basso ed espandendo la chiave txtfile e poi la chiave shell al suo interno, vengono visualizzate le chiavi con i nomi di alcune delle voci del menu di scelta rapida per un file .txt. Non vengono visualizzate tutte le chiavi, perché vi sono altri modi per creare menu di scelta rapida. In ognuna di queste chiavi c'è una chiave di comando. Il valore (Default) nella la chiave di comando è la riga di comando che Windows esegue quando si seleziona tale voce dal menu di scelta rapida.
Gli strumenti per il prompt dei comandi e per il prompt di Windows PowerShell utilizzano questa tecnica per configurare le voci del menu di scelta rapida Open Command Window Here (Apri finestra di comando qui) e Windows PowerShell Prompt Here. Non vi sono tipi di file associati a unità e directory, ma vi sono chiavi Drive e Directory in HKEY_CLASSES_ROOT associate a tali oggetti.
Figura A Le voci del menu di scelta rapida sono configurate nel Registro di sistema
Figura A Le voci del menu di scelta rapida sono configurate nel Registro di sistema (Fare clic sull'immagine per ridurla)
Figura A Le voci del menu di scelta rapida sono configurate nel Registro di sistema
Figura A Le voci del menu di scelta rapida sono configurate nel Registro di sistema (Fare clic sull'immagine per ingrandirla)

Michael Murgolo è un consulente senior per le infrastrutture dei servizi di consulenza Microsoft. Lavora in particolare su sistemi operativi, distribuzione, servizi di rete, Active Directory, gestione dei sistemi, automazione e gestione delle patch.

Creazione interattiva di script
Una cosa da fare è eseguire più cmdlet per ogni servizio elencato in C:\services.txt. In questo modo potrò visualizzare il nome del servizio e qualsiasi altra informazione necessaria per poter seguire l'avanzamento dello script.
Prima ho utilizzato la pipeline per inoltrare oggetti da un cmdlet a un altro. Questa volta invece utilizzerò una tecnica più simile agli script definita "costrutto Foreach" che ho presentato nell'articolo del mese scorso. Il costrutto Foreach può accettare un insieme di oggetti ed eseguire più cmdlet per ogni oggetto dell'insieme. Indico una variabile che rappresenti l'oggetto corrente per l'intero ciclo. Ad esempio, il costrutto potrebbe iniziare nel modo seguente:
foreach ($service in get-content c:\services.txt)
Sto ancora eseguendo lo stesso cmdlet Get-Content per recuperare il contenuto del file di testo. Questa volta chiedo al costrutto Foreach di riprodurre a ciclo continuo l'insieme di oggetti restituiti da Get-Content. Il ciclo viene eseguito una volta per ogni oggetto e l'oggetto corrente viene inserito nella variabile $service. A questo punto devo solo specificare il codice che deve essere eseguito all'interno del ciclo. Per prima cosa cercherò di riprodurre il comando di una riga originale, per semplificare al massimo ed evitare di perdere funzionalità:
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
Qui ci sono alcune cose interessanti. Come si può notare, la prima riga del costrutto Foreach con una parentesi graffa aperta. Tutto ciò che si trova tra parentesi graffe è considerato interno al ciclo Foreach e verrà eseguito una volta per ogni oggetto nell'insieme di input. Dopo avere inserito la parentesi graffa aperta { e premuto Invio, il prompt di Windows PowerShell è diventato >> (Figura 2). Questo indica che PowerShell sa che ho iniziato un costrutto e sta aspettando che lo concluda. Poi ho digitato il cmdlet Set-Service. Questa volta ho utilizzato $service come primo parametro, dato che rappresenta il nome del servizio corrente letto dal file di testo. Nella riga seguente concludo il costrutto con una parentesi graffa chiusa. Dopo avere premuto due volte Invio, Windows PowerShell esegue immediatamente il codice.
Figura 2 Windows PowerShell sa che è stato iniziato un costrutto
Figura 2 Windows PowerShell sa che è stato iniziato un costrutto (Fare clic sull'immagine per ridurla)
Figura 2 Windows PowerShell sa che è stato iniziato un costrutto
Figura 2 Windows PowerShell sa che è stato iniziato un costrutto (Fare clic sull'immagine per ingrandirla)
Funziona, immediatamente. Quello che ho scritto assomiglia a uno script, ma Windows PowerShell lo sta eseguendo in tempo reale e non viene memorizzato in nessun file di testo. Ora riscriverò tutto, aggiungendo una riga di codice per visualizzare il nome del servizio corrente:
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
Si noti che sto chiedendo di visualizzare qualcosa e ho racchiuso questo qualcosa tra virgolette doppie. Le virgolette indicano a Windows PowerShell che questa è una stringa di testo e non un altro comando. Tuttavia, quando si usano virgolette doppie invece delle virgolette singole, Windows PowerShell cerca eventuali variabili nella stringa di testo. Se ne trova una, sostituisce al nome della variabile il suo valore effettivo. In questo modo, quando viene eseguito questo codice, si vedrà visualizzato il nome del servizio corrente.
Ma questo non è ancora uno script!
Finora ho utilizzato Windows PowerShell in modo interattivo, un ottimo sistema per vedere immediatamente i risultati di quello che si scrive. Ma prima o poi mi stancherò di riscrivere in continuazione queste righe di codice. Per questo Windows PowerShell può anche eseguire script. In realtà, gli script di Windows PowerShell seguono la definizione più letterale di script: essenzialmente Windows PowerShell legge semplicemente il file di testo dello script e "digita" ogni riga che trova, esattamente come se l'utente stesse digitando le righe manualmente. Questo significa che tutto ciò che ho fatto fino a questo punto può essere incollato in un file di script. Quindi ora utilizzerò il Blocco note per creare il file disableservices.ps1 nel quale incollerò quanto segue:
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
Ho collocato questo file nella cartella C:\test. Ora cercherò di eseguirlo da Windows PowerShell:
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
Ops... Dove ho sbagliato? Windows PowerShell è impostato sulla cartella C:\test, ma non ha trovato lo script. Perché? Per motivi di sicurezza, Windows PowerShell è progettato in modo da non eseguire mai script dalla cartella corrente, per impedire che uno script possa dirottare un comando del sistema operativo. Ad esempio, non posso creare uno script dir.ps1 e fare in modo che venga eseguito al posto del normale comando dir. Se devo eseguire uno script dalla cartella corrente, devo specificare un percorso relativo:
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
E adesso? Ancora non funziona. Il percorso è quello giusto, ma Windows PowerShell avvisa che non è possibile eseguire script. Questo accade perché, per impostazione predefinita, Windows PowerShell non è in grado di eseguire script. Ancora una volta si tratta di una precauzione di sicurezza per evitare i problemi che conosciamo tutti con VBScript. Per impostazione predefinita, gli script dannosi non possono essere eseguiti in Windows PowerShell perché nessuno script può essere eseguito per impostazione predefinita. Per eseguire lo script, devo modificare esplicitamente i criteri di esecuzione:
PS C:\test> set-executionpolicy remotesigned
Il criterio di esecuzione RemoteSigned consente l'esecuzione di script senza firma dal computer locale. Gli script scaricati devono sempre avere una firma per poter essere eseguiti. Un criterio migliore è AllSigned, che esegue solo script che hanno una firma digitale basata su un certificato emesso da un autore attendibile. Io però non ho sottomano un certificato e non posso firmare i miei script, quindi RemoteSigned è una buona scelta per questa situazione. Ora riproverò a eseguire lo script:
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
Voglio far notare che il criterio di esecuzione RemoteSigned che stiamo usando non è la scelta ottimale, ma solo una buona scelta. C'è infatti una soluzione di gran lunga migliore. Sarebbe molto più sicuro ottenere un certificato di firma codice, utilizzare il cmdlet Set-AuthenticodeSignature di Windows PowerShell per firmare i miei script e impostare il criterio di esecuzione AllSigned, che offre una protezione maggiore.
Esiste anche un altro criterio, Unrestricted, che è decisamente da evitare. Questo criterio consente l'esecuzione senza restrizioni di qualsiasi script, anche gli script dannosi provenienti da posizioni remote, il che può rappresentare un grosso rischio. Consiglio quindi di non utilizzare il criterio Unrestricted per alcun motivo.

Risultati immediati
Le funzionalità di script interattive di Windows PowerShell consentono di collaudare rapidamente gli script o anche solo piccole parti di script. Si ottengono risultati immediati e quindi si possono facilmente modificare gli script per ottenere esattamente i risultati desiderati. Alla fine è possibile spostare il codice in un file .ps1 per renderlo permanente e facilmente accessibile in futuro. E ricorda: se possibile, è necessario applicare una firma digitale a questi file .ps1 in modo da poter lasciare Windows PowerShell impostato sul criterio di esecuzione AllSigned, l'impostazione più sicura tra quelle che consentono l'esecuzione degli script.

Don Jones è il guru degli script di SAPIEN Technologies e coautore di Windows PowerShell: TFM (vedere www.SAPIENPress.com). Contatta Don all'indirizzo don@sapien.com.


 Hey, Scripting Guy!: Inseguire automobili... e XML
Hey, Scripting Guy!
Inseguire automobili... e XML
I Microsoft Scripting Guy
Scarica il codice per questo articolo: HeyScriptingGuy2007_02.exe (150KB)

"NON SO perché il mio cane insegue le automobili", recita una vecchia battuta. "Cosa se ne farebbe poi se ne raggiungesse una?"
Bella domanda, a cui gli Scripting Guy tra l'altro non sanno rispondere. A meno che a raggiungere l'auto non sia Lucy, il cane del quartiere. Siamo assolutamente certi che quel cane andrebbe a rapinare un'enoteca e poi userebbe l'auto per la fuga. E a giudicare dalle condizioni dei giardinetti qui davanti, siamo pronti a scommettere che non si fermerebbe ai servizi sulla strada, non so se ci siamo capiti...
Se dovessimo riportare la vecchia battuta all'attuale era informatica, potrebbe diventare così: "Non so perché il mio amministratore di sistema insiste a voler imparare XML. Cosa se ne farebbe poi se lo imparasse?"
Nota A nostra discolpa, avevamo detto solo che avremmo aggiornato la vecchia battuta, non che l'avremmo resa divertente.
Onestamente, forse XML è una tecnologia leggermente sopravvalutata, almeno per quanto riguarda la gestione dei sistemi. La verità è che molti amministratori di sistema hanno vissuto a lungo e felicemente senza mai scrivere un solo script che interagisse con un file XML e non prevediamo che le cose cambino da un momento all'altro.
Detto questo, è anche vero che sempre più applicazioni adottano XML come standard per l'archiviazione dei dati. E perché no? Dato che non sono altro che file di testo un po' arzigogolati, questi file di dati XML sono facili e veloci da creare, sono trasferibili da una piattaforma all'altra e non richiedono programmi di database complicati e costosi. Hai un sistema operativo e un editor di testo? Allora puoi creare un database XML.
Il che significa, naturalmente, che c'è almeno una cosa che un amministratore di sistema può fare con XML: scrivere script per inviare query a un file XML come se fosse un vero e proprio database. E allora, chi meglio degli Scripting Guy per offrire qualche suggerimento su come farlo?
Bene, bersaglio centrato. Se dovessimo provare a indovinare, scommetteremmo che in questo momento Lucy sia troppo impegnata a scavare nelle aiuole di qualche vicino per scrivere un articolo su XML.
Per cominciare, esaminiamo un semplice file XML (Figura 1), un file di database con quattro script pubblicati nella rubrica quotidiana Hey, Scripting Guy!.
Figure 1 Hey, Scripting Guy! Script in XML (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
Come si può vedere, è un piccolo file molto semplice. Ogni singolo script si trova sotto un tag <Script>. D'ora in avanti chiameremo questi script "record". Sì, è vero, gli esperti di XML non li chiamerebbero mai record. Ma non è un problema: il nostro scopo qui è mostrare come applicare una cosa che si conosce già, ossia le tecniche di query ai database, a un nuovo e diverso tipo di origine dati. Abbiamo pensato di concentrarci per prima cosa sull'aspetto pratico della questione per poi magari tornare sull'argomento in futuro e fornire la terminologia corretta.
Quindi, torniamo ai record. Ogni record contiene i seguenti campi: <Category> (categoria), <Subcategory> (sottocategoria), <Keyword> (parola chiave), <Title> (titolo) e <URL>.
Non vedo un grande entusiasmo tra il pubblico. Forse possiamo migliorare le cose mostrando uno script che consente di aprire questo file XML e restituire il contenuto:
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Nota Attenzione: questi nomi di tag distinguono tra maiuscole e minuscole. La versione corretta è "/Repository/Script", non "/repository/script" o "/REPOSITORY/SCRIPT".
D'accordo, nemmeno questo ha fatto una grande impressione. Ma è proprio questo il punto: non è assolutamente difficile come si potrebbe pensare.
Come si può vedere nel codice, per cominciare creiamo un'istanza dell'oggetto Microsoft.XMLDOM, l'oggetto COM utilizzato per lavorare con i file XML. Poi impostiamo la proprietà Async su False. In questo modo è possibile garantire che l'intero file venga letto in memoria prima di restituire il controllo allo script. Utilizziamo poi il metodo Load per leggere il file C:\Scripts\Scripts.xml:
xmlDoc.Load("C:\Scripts\Scripts.xml")
Appena il file è stato caricato in memoria, possiamo usare il metodo selectNodes per selezionare i record specificati dal database:
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
Osserviamo attentamente il parametro inoltrato a selectNodes. In realtà, questo rappresenta il percorso all'interno del file XML. Il nostro file XML ha la seguente struttura:
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
"È importante?" chiederete. In una parola, sì! Quando si lavora con i file XML, la struttura è molto importante. Ad esempio, come possiamo ricavare le singole proprietà di un record? È facile: Accediamo al tag <Repository> seguito dal tag <Script> seguito dai tag delle singole proprietà. E guarda un po'. Questo è lo stesso percorso specificato come parametro per selectNodes. Facciamo semplicemente seguire questo percorso da /*, che significa "Seleziona tutte le proprietà per questi record". In altre parole, l'insieme restituito sarà composto da tutte le proprietà di tutti i record del database, come una query "Select * From" in Strumentazione gestione Windows® (WMI).
Nota Prova a usare lo script di esempio e vedrai esattamente cosa intendiamo.
Il resto dello script è facile: ci limitiamo a impostare un ciclo For Each per scorrere tutto l'insieme e restituire il valore della proprietà Text per ogni elemento e ogni proprietà:
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Molto più facile che inseguire le automobili.
Ma hai ragione: se avessimo voluto semplicemente restituire l'intero contenuto del file, avremmo potuto lasciar perdere XML e usare semplicemente FileSystemObject. Avrebbe potuto essere un filino più complicato, ma solo un filino. Se la nostra intenzione era meravigliare e far pensare "Ehi, dopotutto questo XML è veramente utile", allora probabilmente abbiamo ancora parecchia strada da fare.
E allora vediamo di rimediare. Nel primo script abbiamo ottenuto i valori delle proprietà per tutti i record. Va bene, ma se quello che ci interessava ottenere fosse stato semplicemente il titolo dello script? Lo possiamo fare? Un attimo solo...
Va bene, secondo Lucy basta modificare il comando selectNodes aggiungendo la proprietà che ci interessa alla fine del percorso. In altre parole:
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
L'unico motivo per cui la prima volta abbiamo ottenuto tutte le proprietà è che abbiamo usato il carattere jolly *. Ora otteniamo solo la proprietà Title. Perché? Perché è l'unico valore della proprietà che abbiamo chiesto.
Nota Guarda un po': XML ti dà esattamente quello che chiedi. Senza offesa, Lucy, ma crediamo che XML sia il nuovo migliore amico dell'uomo!
E naturalmente si può ottenere più di una proprietà. Ad esempio, questo comando modificato restituisce i valori per le proprietà Title e URL:
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
È vero che la sintassi non è semplicissima, ma una volta abituati non è poi così difficile. Per cominciare, specifichiamo la parte principale del percorso, proprio come abbiamo fatto prima:
    /Repository/Script/
Aggiungiamo poi delle parentesi e al loro interno specifichiamo le proprietà da restituire. Si noti che usiamo la barra verticale, ossia il carattere |, come separatore tra le singole proprietà. In altre parole:
    (Title | URL)
Come abbiamo già detto, magari non è bellissimo, ma funziona.
Ed è possibile anche ottenere più di due proprietà. Basta continuare ad aggiungere barre verticali per ottenere tutte le informazioni desiderate. Ad esempio, il seguente comando restituisce tre proprietà (Title, URL e Keyword):
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
Interessante, no?
Beh, a noi sembra interessante. Sei proprio incontentabile. Ma di nuovo non hai tutti i torti: finora abbiamo semplicemente recuperato informazioni su tutti i record del database. Non che ci sia niente di male in questo. Spesso è esattamente ciò che serve. Però ci saranno anche dei casi (molti casi) in cui si vogliono recuperare informazioni relative solo a un sottoinsieme di quei record. Ad esempio, si potrebbero voler ottenere solo le informazioni relative agli script la cui Keyword (parola chiave) è uguale a databases. Allora si potrebbe usare una query come questa:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
Di nuovo, la sintassi è un po' strana. D'altra parte, però, è anche semplice e lineare. Dopo avere specificato il percorso principale, inseriamo la clausola "Where" (ad esempio, dove x è uguale a y) tra parentesi quadre, in questo modo:
/Repository/Script [Keyword = ‘databases’]
Come probabilmente avrai già capito, il nostro equivalente della clausola Where indica allo script di restituire solo gli elementi in cui l'attributo Keyword è uguale a databases. Si noti che databases è racchiuso tra virgolette singole. Non solo va bene così, ma è praticamente necessario. Se il termine filtro è racchiuso tra virgolette doppie, si verifica un errore di sintassi quando si cerca di eseguire lo script.
Nota Perché? Perché, ricordiamo, l'intera stringa di query "/Repository/Script [Keyword = 'databases']" è racchiusa tra virgolette doppie.
Naturalmente non si può usare solo il segno di uguale (=) per filtrare i dati. Si possono usare i segni maggiore di (>) o minore di (<), oltre ai noti segni di maggiore o uguale (<=) e minore o uguale (>=). Si può anche negare uno qualsiasi di questi segni facendolo precedere da un punto esclamativo. Ad esempio, questo comando richiede tutti gli script in cui la Keyword non è uguale a databases (notare il segno !=).
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
Un attimo: chi ha detto "Va bene, si può impostare un filtro, ma scommetto che non si può impostare un filtro e specificare le proprietà che devono essere restituite"? Certo che si può:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
Se tutto va bene, questo comando restituirà solo la proprietà Title per tutti gli script in cui la Keyword è uguale a databases. Vediamo se funziona:
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
Vediamo se possiamo infilarci un altro comando prima di chiudere. Anche se stiamo facendo progressi, forse stiamo ancora ottenendo più record di quelli che effettivamente vogliamo. Dopotutto il comando precedente restituisce un insieme di script Microsoft® Access® e di script Microsoft SQL Server™. Perché? Perché in tutti questi script la Keyword è uguale a 'databases'. E se volessimo limitare i dati restituiti agli script in cui la Keyword è uguale a 'databases' e la Subcategory è uguale a 'Microsoft SQL Server'? È possibile filtrare per criteri multipli?
Ma c'era bisogno di chiederlo?
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
È la stessa sintassi di base. Abbiamo semplicemente utilizzato due criteri separati (ossia Keyword = 'databases' e Subcategory = 'Microsoft SQL Server') collegandoli con l'operatore AND.
Nota Sì, è vero: con questo semplice e piccolo file XML avremmo potuto semplicemente richiedere tutti gli script in cui la Subcategory è uguale a 'Microsoft SQL Server'. Ma sarebbe stato poco interessante e molto meno istruttivo.
Si possono utilizzare anche clausole OR. Ad esempio, poniamo di avere una quantità di script di Microsoft Office, tra cui script con Subcategory uguale a Microsoft Excel®, Microsoft PowerPoint®, Microsoft Outlook® e così via. È possibile limitare i dati restituiti solo agli script delle sottocategorie Microsoft Word o Microsoft Access? Ma certo:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
Meglio così? D'accordo, questo non sarà uno di quegli articoli che ti cambierà la vita, però ci sono buone probabilità che prima o poi risulterà utile poter inviare una query a un file XML in questo modo. Ma sta a te scegliere: puoi imparare alcune tecniche di base per XML o inseguire le automobili. Dipende da te. Se scegli le automobili e ti capita di incontrare Lucy, il cane del quartiere, salutala da parte degli Scripting Guy. E dille di starsene fuori dal nostro giardino!
Hey, Scripting Guy! - Ogni giorno
Hai appena letto l'articolo Hey, Scripting Guy! di questo mese e pensato che fosse il miglior pezzo tecnico mai letto. Potresti addirittura arrivare a dire che è il miglior pezzo mai scritto in assoluto. Non solo, ma stai tenendo d'occhio con impazienza la posta in attesa del prossimo numero di TechNet Magazine solo per poter leggere un altro articolo come questo.
Che cosa stai aspettando? Vuoi saperne di più su Lucy, il cane del vicinato, o leggere le ultime imprese dello Scripting Son? Sai come è andato il campionato annuale di Turducken l'anno scorso? Tieniti aggiornato su questi importanti argomenti leggendo gli articoli quotidiani (ebbene sì, abbiamo detto quotidiani), di Hey, Scripting Guy!. Ogni giorno dal lunedì al venerdì (tranne i festivi e i giorni in cui gli Scripting Guy sono in vacanza), puoi leggere le ultime notizie sul baseball giocato nelle scuole, il football e il basket giocati nelle università e ogni tanto anche le previsioni del tempo locali. D'accordo, sono locali solo per chi abita a Redmond, ma chi non vuole sapere com'è il tempo a Redmond?
Non solo, ma imparerai anche qualcosa di nuovo sugli script ogni giorno. Sì, nascoste tra queste storie avvincenti ci sono anche informazioni sugli script. In ogni articolo, gli Scripting Guy rispondono a domande reali inviate da lettori che si ritengono essere reali. Puoi leggere l'articolo quotidiano in linea all'indirizzo microsoft.com/technet/scriptcenter/resources/qanda. Inoltre, poiché hanno già risposto a centinaia di domande, gli archivi sono piuttosto corposi e quindi rappresentano un'ottima fonte di informazioni sugli script (vedi microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx).
Hai una domanda per gli Scripting Guy? C'è una remota possibilità di ottenere una risposta inviando la domanda all'indirizzo scripter@microsoft.com. Se invece non la invii non esiste nemmeno questa remota possibilità, quindi non hai niente da perdere. A differenza di un biglietto della lotteria, è gratis e le probabilità sono leggermente maggiori.

I Microsoft Scripting Guy lavorano o, per meglio dire, sono stipendiati da Microsoft. Quando non si dedicano al baseball (o vaie altre attività) da giocatori, allenatori o semplici spettatori gestiscono il TechNet Script Center. Consultalo alla pagina www.scriptingguys.com.


 Controllo protezione: Distribuzione di EFS: Parte 1:
Controllo protezione
Distribuzione di EFS: Parte 1:

Al giorno d'oggi tutti hanno sentito parlare della perdita di dati personali o riservati a causa del furto di computer portatili o dell'abbandono di computer in luoghi sbagliati. I computer portatili vengono smarriti regolarmente. La totale protezione dei dati sui computer portatili è essenziale, in quest'epoca caratterizzata da furti di identità dove il rispetto delle normative è più che mai fondamentale.
L'uso di EFS (Encrypting File System), contenuto in Windows® fin dalla versione Windows 2000, potrebbe essere una soluzione in quanto fornisce una crittografia basata su disco, incorporata e a prestazioni elevate. EFS si integra perfettamente con Esplora risorse, tanto che gli utenti finali spesso non si rendono conto di utilizzare un file crittografato. Inoltre, EFS funziona altrettanto bene con le tecnologie di autenticazione e controllo di accesso originali di Windows, pertanto gli utenti non hanno bisogno di ricordare password diverse per accedere ai loro dati. Infine, EFS offre opzioni semplici da gestire per il recupero dei dati qualora un utente perdesse l'accesso alle sue chiavi di crittografia (ad esempio, in caso di cancellazione o danneggiamento del suo profilo utente o di perdita della smart card).
EFS utilizza la tecnologia di crittografia incorporata in Windows per generare, memorizzare e distribuire chiavi di crittografia complesse per la protezione dei dati. In Windows XP Service Pack 1 (SP1) e versioni successive, EFS utilizza l'algoritmo AES (Advanced Encryption Standard) con una chiave a 256 bit per la codifica dei dati sul disco. Queste chiavi simmetriche sono inoltre protette da una coppia asimmetrica di chiavi (RSA). EFS codifica ogni file con la sua chiave AES, quindi codifica questa chiave con la chiave RSA dell'utente e ne memorizza il risultato nel file. Per ulteriori informazioni sulla crittografia EFS, vedere "Risorse EFS" nella barra laterale. Per adesso non concentrerò l'attenzione sul lato strettamente tecnico di EFS, ma piuttosto su come distribuirlo e renderlo utilizzabile nell'ambiente degli utenti. Per questo motivo, il presente articolo presuppone una conoscenza precedente dei concetti di crittografia EFS.

Una nota sulla protezione di EFS
Alcune applicazioni sembrano essere in grado di decifrare o decodificare la crittografia EFS. Nessuna di queste applicazioni è capace di decrittografare effettivamente l'AES (o Data Encryption Standard, DES, o Expanded Data Encryption Standard, DESX), sono piuttosto in grado di accedere alla chiave privata EFS dell'utente forzandone la password in maniera brutale. La cosa importante da tenere a mente a proposito della crittografia EFS è che le chiavi private utilizzate per generare e proteggere i dati crittografati utilizzano Data Protection API (DPAPI). Per proteggere i dati, DPAPI utilizza i derivati delle credenziali di accesso di un utente; ne consegue che la protezione dei dati con EFS è efficace quanto la password dell'utente. Con Windows Vista™ è ora possibile memorizzare i certificati di crittografia EFS sulle smart card, cosa che modifica questo paradigma e aumenta considerevolmente la protezione relativa dei dati protetti da EFS.
Quanto deve essere lunga la password per resistere a questi attacchi? Considerate le funzionalità hardware e gli algoritmi moderni di attacco delle password, si consiglia una password (o più correttamente, passphrase) di 11 caratteri come minimo. Una passphrase di 11 caratteri o più lunga è estremamente resistente ai metodi odierni più avanzati, compresi gli attacchi hash precalcolati (come Rainbow Table, per ulteriori informazioni vedere la pubblicazione sul blog "Why you shouldn't be using passwords of any kind on your Windows networks" in "Risorse" nella barra laterale).

Utilizzare PKI o no?
Una delle convinzioni erronee più diffuse su EFS è che, per funzionare, richieda un'infrastruttura a chiave pubblica (PKI). Sebbene EFS possa integrarsi e sfruttare facilmente i vantaggi di una PKI, qualora l'organizzazione ne possieda già una, non si tratta di un requisito essenziale. Detto ciò, la decisione di utilizzare o meno una PKI durante la distribuzione dell'EFS avrà un impatto su molte decisioni di distribuzione future, pertanto deve essere vagliata con cura.
Il vantaggio principale dell'utilizzo di una PKI con EFS è la capacità di eseguire i processi di archiviazione e di ripristino della chiave. EFS consente agli amministratori di eseguire il ripristino dei dati, tuttavia il ripristino automatico è disponibile soltanto con una PKI e solo quando viene eseguito Windows Server® 2003 Enterprise Edition come Autorità di certificazione (CA). Il ripristino dei dati è il processo tramite cui l'utente che perde l'accesso alla sua chiave di crittografia può fornire i suoi dati crittografati a un amministratore designato noto come Data Recovery Agent (Agente di ripristino dei dati, DRA), il quale può quindi decrittografare i dati e riconsegnarli all'utente, oppure ricrittografarli per essere utilizzati con una nuova chiave privata. Il DRA è una figura importante nel processo di crittografia dell'utente, in quanto tutto ciò che l'utente codifica con la sua chiave viene codificato anche con una copia della chiave del DRA. Pertanto se l'utente perde la chiave, interviene il DRA il quale recupera i dati del testo crittografato, vi applica la sua chiave DRA per la decrittografia (o la ricrittografia), quindi riconsegna i dati all'utente. L'approccio del DRA è funzionale, tuttavia può essere difficile da gestire se l'utente ha crittografato grandi quantità di dati oppure non dispone di personale IT locale che funga da DRA.
Il ripristino della chiave, d'altra parte, richiede che l'autorità di certificazione esegua una copia della chiave di crittografia dell'utente durante il processo di creazione della chiave e ne memorizzi in maniera sicura la copia nel database della suddetta autorità di certificazione. In seguito, se l'utente perde l'accesso ai file codificati, l'amministratore della CA deve semplicemente consultare tale database e recuperare la chiave dell'utente. A questo punto l'utente avrà immediatamente accesso ai suoi dati senza richiedere l'intervento di un DRA. Grazie a questo processo, il ripristino della chiave può rivelarsi più veloce ed efficiente. Notare, tuttavia, che la procedura consigliata consiste nell'avere sempre a disposizione un DRA, anche nei casi di ripristino della chiave, per fornire un meccanismo di backup in caso di perdita delle chiavi. Inoltre questo consente alle grandi organizzazioni di disporre di un sistema di ripristino distribuito, dove gli amministratori IT locali possono recuperare i dati degli utenti senza essere costretti a coinvolgere il gruppo di amministratori della PKI.
Un altro potenziale vantaggio dell'utilizzo della PKI con EFS è che facilita una condivisione più agevole dei file codificati. Tenere presente che EFS non si limita esclusivamente ai computer portatili, infatti è uno strumento ugualmente prezioso nelle situazioni in cui non si possa garantire la protezione fisica di un computer. In queste situazioni, utenti multipli potrebbero avere bisogno di accedere agli stessi dati crittografati. Benché il supporto di Windows per la condivisione di file crittografati sia relativamente limitato, in quanto contempla soltanto la condivisione di file singoli e non delle directory, può tuttavia rivelarsi uno strumento utile. Per facilitare la condivisione dei file EFS, l'utente che condivide il file deve avere accesso alle chiavi pubbliche degli utenti con cui sta condividendo i file (cosa più facile se tali utenti dispongono di un valido certificato EFS pubblicato nel loro account in Active Directory®). Benché sia possibile eseguire manualmente tale pubblicazione, utilizzando l'autorità di certificazione (CA) di Windows installata in modalità Enterprise (integrata in Active Directory) il processo viene reso completamente automatico.

Gestione delle chiavi EFS
Se si dispone, e si può utilizzare, una PKI basata su Windows Server 2003, generare certificati EFS per gli utenti è un processo semplice. Una CA di Windows Server 2003 viene fornita con una serie predefinita di modelli di certificati, compreso il modello EFS di base. Tuttavia questo modello fa parte della versione 1 e non supporta l'archiviazione delle chiavi. Pertanto, prima di renderlo disponibile nella propria CA, è necessario duplicare il modello per crearne uno nuovo nella versione 2 (ad esempio, lo si potrebbe chiamare EFS con archiviazione delle chiavi, come indicato nella Figura 1). In questo nuovo modello, accedere alla scheda Gestione richiesta e selezionare l'opzione di archiviazione della chiave di crittografia dell'utente. Si noti che prima di attivare quest'opzione è necessario configurare correttamente l'archiviazione della chiave sulla CA. La sezione risorse contiene un'eccellente descrizione del processo. È necessario inoltre impostare questo modello affinché sostituisca il modello EFS di base per assicurarsi che i client utilizzino la nuova versione (vedere la Figura 2).
Figura 1 EFS con archiviazione delle chiavi
Figura 1 EFS con archiviazione delle chiavi (Fare clic sull'immagine per ridurla)
Figura 1 EFS con archiviazione delle chiavi
Figura 1 EFS con archiviazione delle chiavi (Fare clic sull'immagine per ingrandirla)
Figura 2 Sostituzione del modello EFS di base
Figura 2 Sostituzione del modello EFS di base (Fare clic sull'immagine per ridurla)
Figura 2 Sostituzione del modello EFS di base
Figura 2 Sostituzione del modello EFS di base (Fare clic sull'immagine per ingrandirla)
Per consentire l'accesso all'iscrizione al corretto gruppo di utenti, occorre impostare le corrette autorizzazioni sul modello. Poiché il componente EFS in Windows richiederà automaticamente un certificato al primo utilizzo di EFS, generalmente non è necessario consentire agli utenti di autoiscriversi nel modello EFS. Infatti, si sconsiglia di attivare l'autoiscrizione per i certificati EFS a meno di essere certi che tutti gli utenti autoiscritti utilizzeranno EFS. La Figura 3 indica le impostazioni di iscrizione di EFS. L'emissione di certificati a utenti che potrebbero non utilizzare mai EFS, aumenta inutilmente la dimensione del database della CA. Benché la dimensione del database della CA non sia limitata, può diventare più difficile da gestire (in particolare con Microsoft Management Console o MMC) man mano che il numero di certificati emessi aumenta.
Figura 3 Impostazione delle autorizzazioni utente EFS
Figura 3 Impostazione delle autorizzazioni utente EFS (Fare clic sull'immagine per ridurla)
Figura 3 Impostazione delle autorizzazioni utente EFS
Figura 3 Impostazione delle autorizzazioni utente EFS (Fare clic sull'immagine per ingrandirla)
Infine, se è necessario supportare la condivisione dei file crittografati, può essere utile far pubblicare automaticamente dalla CA il certificato dell'utente in Active Directory.
Una volta configurato correttamente il modello nella propria CA, la prima volta che un utente esegue la crittografia di un file con EFS otterrà il suo certificato da tale CA e questa archivierà automaticamente la sua chiave privata.

Gestione delle chiavi DRA
Il passo successivo da considerare, se si dispone di una PKI, è se utilizzare o meno i certificati DRA generati dalla CA. Perché non si dovrebbero utilizzare i certificati DRA dalla propria PKI? Si consideri uno scenario in cui l'autorità di certificazione emette un certificato con un periodo di validità relativamente breve (due anni o meno). Tale CA non sarà in grado di emettere alcun certificato con una durata di validità superiore alla propria, vale a dire che i certificati DRA avranno una validità di due anni al massimo. Ciò può risultare in operazioni di ripristino dei dati considerevolmente più complicate. Quest'esempio ipotetico è illustrato nello scenario seguente.
  1. Un utente codifica un file nel gennaio del 2006; i certificati DRA emessi nel suo computer per mezzo di Criteri di gruppo hanno una validità di due anni (scadono a gennaio 2008).
  2. L'utente continua a lavorare con EFS, crittografando nuovi file.
  3. Nel gennaio del 2008 i certificati DRA scadono e tramite Criteri di gruppo l'amministratore emette nuovi certificati.
  4. Da questo momento in poi, tutte le operazioni di crittografia utilizzano i nuovi certificati DRA (compresi tutti i file aperti dall'utente e codificati con vecchi DRA; una volta salvati, questi utilizzeranno i nuovi DRA); tuttavia tutti i successivi file che l'utente non tocca risulteranno protetti solo con i vecchi DRA.
  5. L'utente danneggia accidentalmente il suo profilo e richiede il ripristino dei dati.
  6. L'amministratore IT deve disporre di due serie di certificati DRA: quelli nuovi per tutti i file toccati a partire dal Passaggio 3 e quello vecchio per tutti i file che non sono stati toccati da allora.
Benché l'amministratore IT possa eseguire uno script dopo il Passaggio 3 per aggiornare tutti i file col nuovo DRA (utilizzando cipher.exe /u), potrebbe essere un processo lungo. Inoltre, e per maggiore chiarezza, le coppie di chiavi DRA possono essere utilizzate anche dopo la loro data di scadenza, anche se il componente EFS non consentirà alcuna nuova operazione di crittografia, a condizione che un certificato DRA scaduto sia incluso nei suoi criteri di ripristino. I vecchi file crittografati con la coppia di chiavi DRA scadute, possono ovviamente essere recuperati. Pertanto le coppie di chiavi DRA non devono mai essere eliminate, nemmeno al termine del periodo di validità. Non è possibile sapere quando se ne avrà bisogno di nuovo.
Per queste ragioni, si consiglia che gli ambienti aventi CA con certificati di validità brevi impieghino certificati DRA autofirmati che abbiano una durata di validità superiore. L'utilità di crittografia contiene un'opzione (cipher.exe /r) che crea automaticamente le coppie di chiavi dell'agente di ripristino EFS con una validità di 100 anni (vedere la Figura 4). Il certificato di questa coppia di chiavi può essere allegato quindi agli oggetti Criteri di gruppo (GPO, Group Policy Object) ed utilizzato come DRA in tutta l'organizzazione. Poiché il componente EFS non controlla la catena di certificati DRA, i certificati autofirmati saranno validi senza dover apportare alcuna modifica all'elenco di Autorità di certificazione principale attendibili presente nei sistemi. A prescindere dalla durata di validità della CA di un'organizzazione, si consiglia sempre di creare almeno un certificato DRA a lunga scadenza e di allegarlo a un oggetto Criteri di gruppo che copra l'intero dominio. Questa è l'opzione di fallback per il ripristino dei dati, da utilizzare qualora tutte le altre opzioni siano vane. Ciò è particolarmente importante se si utilizzano chiavi DRA generate da CA in mancanza di un archivio di chiavi della CA. Nell'eventualità che un certificato DRA venga compromesso, è possibile aggiornare l'oggetto Criteri di gruppo con un nuovo certificato e utilizzare cipher.exe/u per aggiornare i file, come indicato precedentemente.

Figura 4 Esecuzione di Ciquer /R (Fare clic sull'immagine per ridurla)

Figura 4 Esecuzione di Ciquer /R (Fare clic sull'immagine per ingrandirla)
Risorsa EFS
Per ottenere ulteriori informazioni sui dettagli e le procedure consigliate per EFS, visitare i seguenti siti.
  • Perché si sconsiglia di utilizzare password di qualsiasi tipo sulle reti Windows
  • Implementazione dei passaggi per l'archiviazione delle chiavi
  • Encrypting File System in Windows XP and Windows Server 2003

Distribuzione di KRA e DRA
L'archiviazione delle chiavi consente agli amministratori CA la capacità di recuperare chiavi crittografate garantite per conto dell'utente. Ovviamente, si tratta di una funzionalità estremamente riservata e importante, in quanto può consentire a un amministratore della CA di decrittografare tutti i dati presenti nell'organizzazione che utilizza una chiave firmata dalla CA. Pertanto l'archiviazione e il ripristino delle chiavi dovrebbero essere gestiti con la massima cura e solo un numero esiguo di fidati addetti alla sicurezza dovrebbe possederne l'autorizzazione. A ragione della natura riservata del ripristino delle chiavi, se si desidera farne affidamento come meccanismo principale per recuperare l'accesso a dati crittografati EFS, è importante richiedere che un processo di escalation, chiaramente definito per le richieste di ripristino, sia inviato al proprio team di amministrazione della CA. Il processo di ripristino dovrebbe essere avviato solo dopo aver vagliato attentamente la richiesta. Quindi, una volta che la chiave è stata effettivamente recuperata, dovrebbe essere fornita all'utente tramite un metodo protetto (in altre parole non tramite posta elettronica) in quanto la chiave recuperata fornisce l'accesso a tutti i dati protetti da EFS.
Le chiavi dell'agente di recupero chiavi, o semplicemente chiavi KRA, vengono generate e gestite dagli amministratori della CA e non vengono manifestate tramite Criteri di gruppo. Infatti EFS non può determinare da solo se una chiave utilizzata sia stata archiviata o meno, ma esegue semplicemente le operazioni di crittografia, come sempre. Inoltre, le chiavi KRA create sulla CA non sono affatto specifiche a EFS. Una CA che adotta l'archiviazione delle chiavi disporrà di n numero di chiavi KRA ad essa associate a livello della CA, che saranno utilizzate per proteggere tutte le chiavi archiviate dalla CA. Queste chiavi possono contenere quelle utilizzate con EFS, messaggi di posta elettronica sicuri o qualsiasi altra attività relativa a certificati che preveda la crittografia. Le chiavi KRA devono essere memorizzate in maniera sicura dai singoli agenti di recupero chiavi e devono esistere almeno due KRA in grado di fornire un fallback qualora una delle chiavi venisse perduta.
La prima volta che un amministratore accede al controller di dominio in un dominio appena creato, si genera un criterio di ripristino predefinito a livello di dominio che utilizza un certificato autofirmato e la coppia di chiavi memorizzata nel profilo dell'amministratore sul DC. Questo certificato DRA avrà una validità di tre anni. Si consiglia di rimuovere tale certificato predefinito e di sostituirlo con certificati autofirmati con validità superiore o con certificati emessi dalla propria PKI. Se questo certificato auto firmato predefinito non viene rimosso, tre anni dopo la sua creazione EFS bloccherà la crittografia di nuovi file in tutto il dominio. Ciò avviene perché il certificato sarà allora scaduto e EFS eviterà la crittografia di qualsiasi altro dato se nei suoi criteri di ripristino è presente un certificato DRA scaduto. Benché sia possibile eseguire Windows XP e sistemi più recenti senza disporre di alcun criterio di ripristino, si consiglia vivamente di non effettuare questa operazione. Infatti, qualora un utente, per un motivo qualsiasi, perdesse l'accesso alla sua chiave di crittografia e non fosse possibile eseguirne il ripristino, tutti i suoi dati andrebbero irrevocabilmente perduti.
Come già indicato, le chiavi DRA possono essere autofirmate oppure emesse da una CA. Nella maggior parte dei casi, l'opzione migliore è un approccio ibrido, con almeno due DRA autofirmati e a lunga validità utilizzati come agente di ripristino da tutta l'organizzazione come ultima risorsa. Poiché i certificati DRA vengono distribuiti tramite gli oggetti Criteri di gruppo, dispongono delle stesse funzionalità di ereditarietà di altri oggetti Criteri di gruppo (GPO). In altre parole, l'algoritmo standard di applicazione e accumulo di oggetti Criteri di gruppo delle unità organizzative, locali, di sito e di dominio, che controlla l'applicazione di altre impostazioni dei GPO, si applica anche ai DRA. Pertanto, un'organizzazione può facilmente implementare un approccio a più livelli con i DRA, dove il gruppo IT centrale dispone dell'accesso ai DRA dell'intera azienda, ma dove anche i gruppi IT locali continuano a gestire specifiche aree di responsabilità. Questa è una risorsa preziosa, in particolare per grosse organizzazioni distribuite su una vasta area geografica, in quanto riduce la necessità di trasferire grandi quantità di dati crittografati attraverso collegamenti WAN per facilitare il ripristino dei dati. La Figura 5 mostra una tipica distribuzione di DRA a più livelli.
Figura 5 Distribuzione di DRA multilivello
Figura 5 Distribuzione di DRA multilivello
In questo caso, un utente nell'unità organizzativa Baton Rouge dispone di sei DRA per ogni file codificato: due dai suoi amministratori locali, due dal gruppo IT dell'America del Nord e due dal livello di dominio. Pertanto, se l'utente perde l'accesso ai suoi dati crittografati, li può recuperare da un DRA locale in Baton Rouge o dal gruppo IT dell'America del Nord. Come risorsa finale, se questi quattro DRA non fossero disponibili o fossero stati perduti, per recuperare i dati potrebbero intervenire i DRA a livello di dominio. Il processo è essenzialmente lo stesso a prescindere da quale DRA abbia eseguito il ripristino. Per prima cosa l'utente deve rendere i dati disponibili al DRA. È importante che il DRA adotti le misure necessarie per assicurare che la richiesta sia legittima e provenga dal vero proprietario dei dati. Fatto ciò, il DRA carica il certificato DRA, decrittografa i dati (e preferibilmente li ricodifica) e quindi li rinvia all'utente finale. Alcune organizzazioni optano inoltre per il ripristino locale: il DRA visita fisicamente l'utente in questione, carica la sua coppia di chiavi DRA nel profilo, decrittografa i dati e rimuove la coppia di chiavi. L'utente può così accedere ai suoi dati in formato testo normale e può ricodificarli con una nuova chiave. Si noti che questo approccio è molto meno sicuro in quanto la coppia di chiavi DRA viene copiata (anche se temporaneamente) nel computer locale, tuttavia ciò consente di risparmiare tempo, in particolare quando si devono recuperare grandi quantità di dati.
Si noti che se il ripristino dovesse essere fornito all'utente attraverso l'archiviazione e il recupero della chiave, la richiesta di ripristino sarebbe gestita in maniera completamente separata da questo processo. Invece di utilizzare un DRA, la richiesta di recupero chiavi dell'utente verrebbe rivolta agli amministratori dell'autorità di certificazione, i quali vagliano la richiesta e accedono all'archivio per recuperare la chiave privata dell'utente. Gli amministratori delle autorità di certificazione rendono disponibile all'utente questa chiave privata in maniera protetta, ad esempio collocandola in un sito Web protetto per il download. (Se l'utente utilizzava una smart card per memorizzare la sua chiave EFS, disponibile con Windows Vista, è necessario che anche tale chiave venga emessa nuovamente). Quando l'utente carica questa chiave nel suo profilo ottiene accesso immediato a tutti i suoi dati crittografati.
Poiché le coppie di chiavi DRA e KRA possono essere utilizzate per decrittografare dati riservati, è importante che siano adeguatamente protette. Le coppie di chiavi DRA e KRA non devono essere memorizzate nei normali profili desktop degli amministratori (i profili in cui eseguono le loro normali attività quotidiane). Ma devono essere memorizzate in maniera protetta e non in linea sulle unità floppy, ottiche o flash conservate in un luogo fisicamente protetto. Quando si dovrà effettuare nuovamente il ripristino, l'agente di recupero dati potrà caricare la coppia di chiavi su una workstation di ripristino da tali supporti, eseguire l'operazione di ripristino e rimuovere la coppia di chiavi. Alcune organizzazioni particolarmente impegnate nella protezione designano workstation dedicate per il ripristino, allo scopo di massimizzare la protezione di tali coppie di chiavi; tuttavia, non è un requisito obbligatorio per tutte le organizzazioni.

Nella prossima puntata
Una volta esaminati gli aspetti relativi alla pianificazione EFS su gestione delle chiavi, ripristino dei dati e Active Directory, il mese prossimo, nella Parte 2 di questo argomento, verranno prese in considerazione le richieste di distribuzione lato cliente. L'attenzione sarà posta su diversi argomenti: controllo dell'uso di EFS attraverso Criteri di gruppo, scelta di cosa crittografare, crittografia automatica dei dati attraverso script di accesso e miglioramenti lato client che consentiranno a Esplora risorse di utilizzare i dati protetti da EFS ancora più facilmente.

Come consulente senior, ha progettato soluzioni di protezione per le aziende Fortune 100 nonché per i clienti della difesa e civili americani. Attualmente è Program Manager presso il gruppo Windows Server e si dedica alle tecnologie di protezione e accesso remoto.


 Desktop File: Estensione di Windows PE
Desktop File
Estensione di Windows PE
Wes Miller

Anche prima del rilascio di Windows PE più di cinque anni fa, alcuni clienti chiedevano già più funzionalità. Sfortunatamente, Windows PE non è stato progettato per essere facilmente esteso allo stesso modo, ad esempio, di Windows XP Embedded, cioè mediante l'aggiunta di ulteriori livelli del sistema operativo. Certo, era previsto che Windows PE disponesse del rudimentale supporto di
Win32® (per far funzionare la maggior parte delle applicazioni Windows®) e del supporto di connettività di rete e archiviazione di massa (per comunicare in rete e poter installare Windows). Però, sin dall'inizio la shell è stata limitata. Utilizzando cmd.exe invece della shell tradizionale di Esplora risorse, abbiamo limitato le potenzialità dell'ambiente Windows PE e, ciò che più conta, l'abbiamo fatto perché l'ambiente predefinito fosse facilmente utilizzabile tramite script per tutte le attività di automazione.
Tuttavia, è possibile estendere Windows PE, a condizione di ricordare che hai dei limiti. Le applicazioni potrebbero non funzionare o funzionare in modo anomalo se richiedono una delle tecnologie elencate nella Figura 1 (l'elenco non è esaustivo).
Figure 1 API di Windows mancanti (Close Figure 1)

.NET Framework (qualsiasi versione)
ADSI (Active Directory® Services Interfaces)
DirectX®
MDAC (Microsoft Data Access Components)
Jet (Access)
Visual Basic® (comprese le versioni precedenti .NET)
Qualunque tipo di eseguibile che richiede un framework non installato originariamente con Windows.
Esplora risorse o Internet Explorer
Windows Media® Player
SAPI, MAPI, TAPI (rispettivamente, le API di Windows per la sintesi vocale, la posta e la telefonia)
Se non si sa da cosa dipende l'applicazione, è necessario scoprirlo. Ma come? Quando tentavamo di far funzionare i componenti ADO, HTA (Applicazioni HTML) e WSH (Windows Script Host) in Windows PE prima del rilascio, abbiamo affrontato lo stesso problema. Tuttavia, è bene notare che mentre in questo articolo verrà descritto come tenere traccia di queste dipendenze, l'aggiunta di eventuali binari di Windows all'immagine di Windows PE oltre quanto compreso nel comando MKIMG non è inclusa nel Contratto di Licenza con l'utente finale (EULA). Sarà necessario acquisire un addendum alla licenza da Microsoft per implementare modifiche di questa natura nell'ambiente.

Informazioni sulle dipendenze
Se si apre il file .inf di un'applicazione in Blocco Note e lo si esamina attentamente, si può imparare molto. Infatti, questo è spesso il metodo più semplice per capire un'applicazione e individuarne le dipendenze. La cosa importante da sapere su Windows PE è che generalmente è così compatto che sarà necessario eseguire il debug di molti livelli di dipendenze, sia quelle dirette dell'applicazione, sia quelle di queste ultime, per far sì che l'applicazione venga eseguita in maniera corretta. Essenzialmente, se non si sta attenti si può verificare una vera e propria cascata di dipendenze. Con l'aggiunta accidentale o voluta di alcuni componenti, l'immagine può aumentare notevolmente di dimensioni e complessità.
Se è disponibile un file .inf che descrive l'applicazione, è possibile ottenere degli indizi sulle dipendenze trovando le chiavi del Registro di sistema aggiunte dal file .inf al sistema. Cercare le sezioni CopyFiles e AddReg. Queste voci indicano applicazioni, DLL e altri file da cui dipende l'applicazione. Dei tre componenti aggiuntivi per Windows PE (ADO, HTA e WSH), WSH è stato il più semplice da creare. Poiché una versione ridistribuibile di WSH era ancora disponibile per le versioni più vecchie di Windows e poiché è presente un file .inf attualmente incorporato in Windows che esegue le associazioni di file per WSH (in %windir%\inf\wsh.inf), la sua istallazione in Windows PE è stata abbastanza facile.

Orca e la creazione di istantanee
Se l'applicazione in questione viene distribuita come un file MSI (Microsoft® Installer), si possono fare due cose per individuare le dipendenze. Se non si ha grande dimestichezza con MSI, è possibile utilizzare Orca (uno strumento per la modifica di file Windows Installer distribuito come parte di Windows Server® 2003 R2 SDK: go.microsoft.com/fwlink/?LinkId=77941) per visualizzarlo. Inoltre è possibile installare il file MSI per i componenti desiderati, eseguendo un'analisi di tipo prima e dopo dei file e delle chiavi del Registro di sistema che hanno subito modifiche. È possibile eseguire un dump del Registro di sistema, installare l'applicazione, esportare nuovamente il Registro di sistema, quindi eseguire WinDiff su quest'ultimo (vedere "Utilizzo di WinDiff" nella barra laterale). Il risultato può essere utilizzato poi come modello per le modifiche da apportare al Registro di sistema. Il problema è che il numero di modifiche può essere estremamente elevato. Tuttavia, può essere l'opzione migliore se non si dispone di un file .inf e non si può entrare in contatto con l'autore dell'applicazione.
Si potrebbe avere una buona conoscenza del processo di realizzazione di istantanee di un'applicazione. Essenzialmente, è la stessa analisi di tipo prima e dopo che si effettua per eseguire l'applicazione. Microsoft distribuiva (con Windows 2000) uno strumento che svolgeva questa operazione, ma tale strumento non funziona con le versioni più recenti di Windows. Numerose applicazioni commerciali (repackager di installazioni) possono farlo, così come alcune utilità gratuite. Per risolvere il problema, installare Platform SDK (vedere il collegamento nel paragrafo precedente), che contiene WinDiff. Si noti che per eseguire il confronto con WinDiff, sarebbe meglio installare l'applicazione su Windows Server 2003, Service Pack 1 (SP1) perché dovrebbe essere la versione di Windows PE in uso: Windows PE 1.6 creato dalla Standard Edition o dall'Enterprise Edition (con SP1). Eseguendo questa attività in Windows Server 2003 si otterrà un ambiente più simile a quello che si otterrebbe in Windows PE (dove ovviamente non è possibile eseguire un file MSI). Seguire la procedura descritta in "Utilizzo di WinDiff" nella barra laterale.
In questo modo verranno visualizzate molte delle informazioni modificate. Purtroppo, non esiste un metodo semplice per esportare le informazioni modificate dalle acquisizioni del Registro di sistema o dei file per creare un manifesto qualsiasi per installare l'applicazione. È necessario incorporare le modifiche manualmente. Ed è qui che abbiamo incontrato alcuni dei problemi più complessi con la prima versione di Windows PE. Arrivare al funzionamento corretto dei componenti HTA è stato complicato poiché in Microsoft (al di fuori di Internet Explorer®) non era disponibile una definizione per questi ultimi. Servendoci delle differenze, siamo stati in grado di ottenere un supporto di HTA sufficiente per il suo funzionamento. Oltre ad aggiungere manualmente queste chiavi nel Registro di sistema di Windows PE, è possibile decidere di aggiungerle dopo l'avvio di Windows PE. È possibile esaminare i file OC.bat e OC2.bat utilizzati per installare il supporto di HTA, WSH e/o DAO in Windows PE mediante lo script buildoptionalcomponents.vbs disponibili negli strumenti di generazione di Windows PE.

Strumenti utili
Anche dopo aver isolato le dipendenze dirette, spesso non è possibile trovare tutti i binari da cui dipende l'applicazione. Ad esempio, non si sa se l'applicazione richiede un'altra DLL o OCX per eseguire un'attività. Come è possibile scoprirlo? Mark Russinovich di Sysinternals fame (ora Technical Fellow di Microsoft) ha scritto l'utilità pratica listdlls che si occupa proprio di questo. Listdlls può essere scaricato da microsoft.com/technet/sysinternals/utilities/ListDlls.mspx. Per utilizzarla, è necessario eseguire il comando listdlls.exe > dlls.txt e poi esaminare l'output. Nella Figura 2 viene illustrato l'output di listdlls eseguito su se stesso. Si può confrontare questo elenco con i file DLL e OCX contenuti in Windows PE per determinare se vi sono tutte le dipendenze dell'applicazione (nel caso di listdlls, sono già presenti). Per il supporto HTA in Windows PE, listdlls è stato di fondamentale importanza nell'identificazione di alcune dipendenze che non potrebbero essere altrimenti identificate.
Figura 2 Output di lisdlls eseguito su se stesso
Figura 2 Output di lisdlls eseguito su se stesso (Fare clic sull'immagine per ridurla)
Figura 2 Output di lisdlls eseguito su se stesso
Figura 2 Output di lisdlls eseguito su se stesso (Fare clic sull'immagine per ingrandirla)
Tuttavia, solo perché una DLL è presente nell'elenco non significa necessariamente che l'applicazione ne abbia bisogno per essere eseguita. Se si carica Blocco Note, ad esempio, si vedrà che esso carica uxtheme.dll. In Windows PE, questa DLL non è disponibile e, infatti, poiché non vengono utilizzati i temi di Windows, non sarà mai caricata. Sapere quali DLL indicate da listdlls sono effettivamente necessarie e quali vengono caricate da Windows su richiesta è, sfortunatamente, un'arte oscura che richiederà un certo numero di tentativi ed errori o una notevole dimestichezza con gli aspetti basilari di Windows (per questo, consiglio il libro di Mar Russinovich e David Solomon, Microsoft Windows Internals, Fourt Edition, (Microsoft Press®, 2004) (in inglese).
Infatti, Mark inserisce la stessa funzionalità in Process Explorer, da utilizzare in alternativa a Task Manager di Windows e disponibile gratuitamente. La differenza è che listdlls crea un output che, secondo me, è codificato più semplicemente e viene utilizzato per trovare e raccogliere le dipendenze mancanti.
Si noti che anche dopo aver aggiunto una DLL all'immagine, potrebbe esserci dell'altro da fare. Praticamente, esistono due tipi di DLL: quelle che richiedono la registrazione e quelle che non la richiedono. Sfortunatamente, non esiste un metodo semplice per distinguerle, a parte provare a registrarle. Per registrare una DLL (o OCX), è necessario eseguire regsvr32 nomedll.dll. Se tutto funziona correttamente, viene visualizzata una finestra di dialogo che informa che la DLL è stata registrata. In caso contrario, è possibile che non si riceva un messaggio o, più probabile, che venga visualizzata una finestra di dialogo che informa che la DLL non è stata registrata o che non è stato possibile registrarla. Durante lo sviluppo dei componenti facoltativi HTA e ADO per Windows PE, abbiamo scoperto che le DLL richiedono memoria scrivibile durante la registrazione, per scrivere temporaneamente un file .inf per l'installazione o per registrare altre dipendenze (ad esempio una directory specifica di cui hanno bisogno). In Windows PE, questo significava che l'operazione non sarebbe riuscita. Fortunatamente, con Windows PE 2.0, le attività come queste funzioneranno, poiché per impostazione predefinita è disponibile un'area scratch temporanea.
Un terzo strumento creato da Mark e recentemente rilasciato è Process Monitor. Process Monitor può essere considerato come un sovrainsieme di Regmon e Filemon, che tuttavia fornisce ancora più dettagli, aggiungendo un livello di comunicazione completamente nuovo tra processi. Questo strumento incredibilmente potente può contribuire a risolvere i problemi delle applicazioni in Windows e a rispondere a domande su ciò che succede realmente con le interdipendenze di DLL. Process Monitor può essere scaricato.

Rimozione di file di Windows PE
Oltre alla possibilità di aggiungere elementi a Windows PE, sono state spesso richieste istruzioni per ridurre le dimensioni di Windows PE. Esiste una procedura che consente di ridurre leggermente le dimensioni di Windows PE. La copia di Windows PE concessa in licenza dovrebbe contenere una raccolta di strumenti di generazione e alcuni documenti. Uno di questi documenti è un file di guida denominato winpe.chm. Se si apre questo file e si esplora la sezione Windows Preinstallation Environment User's Guide (in inglese), dovrebbe apparire un argomento relativo alla riduzione delle dimensioni di Windows PE. In questa sezione viene elencata una raccolta di file che si possono rimuovere in sicurezza (presupponendo che non se ne abbia bisogno). Sono disponibili tre sezioni relative ai file rimovibili:
  • I file dei tipi di carattere possono essere sempre rimossi in sicurezza.
  • I file .inf e le utilità che hanno a che vedere con la rete possono essere rimossi, ma solo se non si prevede di utilizzare mai la rete.
  • Le utilità della riga di comando non devono essere rimosse. Sconsiglio la rimozione di queste utilità a meno che non se ne conosca la funzione e si sappia cosa potrebbe succedere in caso di rimozione.
Una volta determinati i file da escludere in sicurezza, è sufficiente scrivere un file batch o un altro script e rimuoverli dalla build di Windows PE quando mkimg.cmd ha terminato la generazione.

Modifica del Registro di sistema di Windows PE
Si può vedere che abbiamo fatto una scelta cosciente di non di installare i componenti facoltativi durante la generazione. Nonostante questo abbia causato un aumento dei tempi in fase di esecuzione, ha evitato tuttavia la necessità di progettare un metodo del tutto nuovo per reinserire questi componenti in Windows PE. Quest'operazione è impossibile da eseguire per mancanza di tempo, il che avrebbe comportato probabilmente la loro totale omissione. Ma che succede se si desidera fare una modifica al Registro di sistema, ad esempio aggiungere modifiche al Registro di sistema per l'applicazione desiderata, o modificare semplicemente una chiave che potrebbe contribuire a far funzionare l'applicazione? Tutto ciò può essere fatto senza problemi utilizzando regedit (Figura 3). Procedere come descritto di seguito:
  1. Eseguire regedit e selezionare l'hive HKEY_LOCAL_MACHINE.
  2. Scegliere File | Carica hive, quindi passare alla posizione della build di Windows PE. Selezionare setupreg.hiv in I386\System32\ (o MiniNT\System32, se si tratta di un'immagine da collocare su un disco rigido).
  3. Inserire un nome temporaneo per l'hive, ad esempio WinPE e passare a questo nodo in HKLM.
  4. Modificare questa chiave di conseguenza. È interessante notare che questo nodo è effettivamente identico al nodo HKLM\System su un'installazione normale di Windows.
  5. Una volta apportate le modifiche, scegliere la chiave in HKLM che è stata creata al Passaggio 3 (è molto importante eseguire quest'operazione alla lettera per non correre il rischio di danneggiare il sistema).
  6. Scegliere File | Scarica hive..., confermare la finestra di dialogo Sì | No e assicurarsi di smontare ogni volta il Registro di sistema, poiché se fosse bloccato impedirebbe una generazione corretta di Windows PE.
Figura 3. Apertura del Registro di sistema di Windows PE
Figura 3. Apertura del Registro di sistema di Windows PE (Fare clic sull'immagine per ridurla)
Figura 3. Apertura del Registro di sistema di Windows PE
Figura 3. Apertura del Registro di sistema di Windows PE (Fare clic sull'immagine per ingrandirla)
Questa procedura consente di modificare HKLM\System. Sono disponibili anche due altre chiavi in I386\System32 che consentono di modificare altre aree del Registro di sistema: DEFAULT è l'hive predefinito per gli utenti (anche SYSTEM, che viene eseguito come quando si utilizza Windows PE) e SOFTWARE, che è lo stesso di HKLM\Software. Come sempre, modificare il Registro di sistema con cautela e soltanto in caso di effettiva necessità.
A questo punto si è in possesso delle informazioni necessarie per iniziare il trasferimento dello strumento preferito per la risoluzione dei problemi o il ripristino in Windows PE. Il prossimo mese, mi occuperò della suite PSTools, una raccolta di strumenti di gestione del sistema molto utili scritta anch'essa da Mark Russinovich.
Utilizzo di WinDiff
WinDiff consente di trovare le dipendenze dell'applicazione. È sufficiente attenersi alla seguente procedura perché l'installazione e l'esecuzione riescano:
  1. Preparare il sistema per l'installazione. Si desidera ridurre al minimo il tempo e le modifiche ai file o al Registro di sistema tra l'istantanea iniziale e finale.
  2. Aprire un prompt dei comandi ed eseguire reg export HKLM C:\HKLM1.reg per effettuare un'esportazione completa dell'hive HKEY_Local_Machine.
  3. Eseguire dir C:\*.* /S > C:\C1.txt per effettuare un dump completo di tutti i file sull'unità C: (presupponendo che C: sia l'unità di sistema).
  4. Installare l'applicazione e configurare eventuali impostazioni post-installazione.
  5. Eseguire reg export HKLM C:\HKLM2.reg.
  6. Eseguire dir C: \*.* /S > C: \C2.txt.
  7. Aprire WinDiff e scegliere File | Compare Files... (Confronta file) e selezionare HKLM1.reg nella prima finestra di dialogo File Open (Apri file) e HKLM2.reg nella seconda.
  8. Viene visualizzato un messaggio in rosso che indica quale è più recente. Armarsi di pazienza, quest'operazione può richiedere del tempo dato che le esportazioni di HKLM possono avere grandi dimensioni.
  9. Fare doppio clic sul testo in rosso per visualizzare le differenze.
  10. È possibile configurare quanto viene visualizzato nel confronto selezionando Options | Show Right-Only Lines (Opzioni | Mostra solo righe sulla destra). In questo modo verrà attivata la visualizzazione delle sole righe aggiunte di recente nel secondo file del confronto (in questo modo, vengono visualizzati solo i nuovi file e le nuove chiavi del Registro di sistema).
Si noti che potrebbe essere necessario utilizzare la funzione Find (Trova) per individuare le chiavi relative all'applicazione. Nelle figure A e B è possibile vedere le modifiche ai file e al Registro di sistema per un'applicazione fittizia da me creata. Fortunatamente in WinDiff sono disponibili le funzioni di copia e incolla. Per utilizzare queste funzioni è sufficiente fare clic sulla riga !> e selezionare le righe desiderate.
Figura A Voci di WinDiff
Figura A Voci di WinDiff (Fare clic sull'immagine per ridurla)
Figura A Voci di WinDiff
Figura A Voci di WinDiff (Fare clic sull'immagine per ingrandirla)
Figura B Chiave specifica in WinDiff
Figura B Chiave specifica in WinDiff (Fare clic sull'immagine per ridurla)
Figura B Chiave specifica in WinDiff
Figura B Chiave specifica in WinDiff (Fare clic sull'immagine per ingrandirla)

Wes Millerè un responsabile allo sviluppo di Pluck www.pluck.com, Austin (Texas). Wes ha lavorato in precedenza per Winternals Software ad Austin e in Microsoft come Program Manager e Product Manager per Windows. Wes è contattabile all'indirizzo technet@getwired.com.


 Appunti: Non funziona pi&#249;
Appunti
Non funziona più
R'ykandar Korra'ti

"Non capisco, continuo a perdere il collegamento".
"A qualunque ora? Succede mentre stai facendo qualcosa di particolare? Ti colleghi da un computer particolare?"
"No. Un momento sono in linea, l'altro no. Puf! Andata."
"Questo non mi aiuta molto. Mi serve qualcos'altro. Un suggerimento, un indizio, qualunque cosa."
"Ti ho detto tutto ciò che so. A volte perdo il collegamento. Puoi aiutarmi?"
Le dico che ci lavorerò su. Non c'è molto nei registri del router, talvolta però il nostro traffico diminuisce davvero, segno che c'é qualcosa che non va, ma solo per un minuto o due, dopo di che tutto torna normale. Niente errori, né schemi ricorrenti, solo di tanto in tanto niente traffico. È strano. Poi, per fortuna:
Squilla il telefono collegato alla linea DSL.
Cade la nostra connessione IP.
Stai scherzando, penso. E ancora, si ripete: se qualcuno chiama il numero di telefono DSL, quello che nessuno utilizza e che nessuno dovrebbe conoscere, la nostra connessione si interrompe. La più grande calamità di cui, stando al punto vendita di servizi numero uno dell'azienda telefonica, non sarebbe mai dovuta accedere, è invece capitata, in modo vistoso e innegabile.
Per di più, siamo soltanto a 274 metri dalla sottostazione. Non dovrebbe succedere. Controllo i cavi, reimposto ogni cosa, pulisco persino i contatti per vedere se può essere di aiuto. Ma, naturalmente, non serve a nulla. Quindi, chiamo la compagnia telefonica. "Lo sa che la sua azienda mi ha promesso che la connessione non sarebbe mai stata interrotta dalle telefonate in arrivo? Indovini un po' che succede? Possiamo subire attacchi DoS da quelli del telemarketing".
Forse potrebbe dipendere dal rame...
Forse potrebbe dipendere dal rame...
L'indomani esce un articolo tecnico e si scopre che, inspiegabilmente, risultiamo essere distanti oltre 900 metri dalla sottostazione, abbastanza distanti da permettere a qualche squinternato di tagliarci fuori con un piccolo magnete di una bussola. Alla fine scopriamo che, in passato, quando il quartiere è stato cablato, tutte le linee telefoniche sono state raggruppate e ogni linea inviata a un edificio dell'isolato, con l'idea di evitare il futuro bisogno di utilizzare nuovi cavi. E questo può funzionare in un mondo in cui predomina la trasmissione voce analogica, ma con la DSL ogni centimetro di quelle diramazioni viene calcolato come distanza dalla sottostazione, diminuendo la potenza del segnale.
Fortunatamente, il problema è stato risolto in modo facile e veloce. Tutte le diramazioni laterali della linea sono state scollegate, con l'appunto "NON RICOLLEGARE. PORZIONE DSL IN USO". Finalmente! Una distanza di soli 274 metri, un segnale molto più potente e, ancora più importante, nessuna perdita della portante se il telefono squilla.
Morale della favola: non dare per scontato che un problema di connessione sia un mistero o addirittura causato dal software. A volte basta poco. Chiedere sempre agli addetti della compagnia telefonica di controllare la potenza del segnale DSL reale durante l'installazione, anche se dicono che non è necessario. Chi lo sa cos'altro può essere collegato lì, che aspetta solo il momento giusto per creare confusione. E non prestare fede alla storia sulla distanza dalla sottostazione. Chi può sapere dove vanno a finire quei fili? Indovina. Loro hanno gli strumenti e la tecnologia: facciamoglieli utilizzare. Sarai contento della tua decisione. In particolare, una volta che il telemarketing ha individuato il numero DSL utilizzato.

R'ykandar Korra'ti, responsabile della posta di una piccola cooperativa di provider di servizi Internet, vive vicino Seattle con la sua amica Anna. Dopo essersi occupata della spedizione di prodotti per posta presso Microsoft, al momento sta cercando una scuola di specializzazione in un campo così oscuro da non avere addirittura un nome. I potenziali Faculty Advisor possono contattarla all'indirizzo darako@murkworks.net.


 Windows Confidential: Quasi una benedizione
Windows Confidential
Quasi una benedizione
Raymond Chen

Quando si inserisce un CD o DVD, la shell "analizza" il disco per determinarne il tipo di contenuto. Di conseguenza, viene indicato alla shell l'azione di AutoPlay da eseguire. I dettagli precisi su come viene eseguita l'analisi non sono documentati poiché si tratta di sistemi euristici che potranno essere modificati in futuro, se si trova un algoritmo migliore.
Formalmente, se l'algoritmo fosse contenuto nella documentazione sarebbe soggetto ai termini contrattuali previsti e ciò impedirebbe di modificarlo in versioni successive. Ufficialmente, quindi, i dettagli dell'algoritmo vengono omessi.
Chi non ha mai scritto documentazione SDK potrebbe non rendersi conto che ciò può comportare obblighi contrattuali. Una volta dichiarato pubblicamente che qualcosa funziona in un certo modo, non è possibile modificarlo. In tal caso, chi si basava su questa convinzione potrebbe dichiarare "Non è esattamente in linea con quanto specificato nella documentazione. Avete cambiato le regole a gioco iniziato".
Fatta questa premessa, ecco una descrizione veloce e incredibilmente semplificata di come Windows® XP Service Pack 2 (SP2) classifica il contenuto di CD e DVD dati che non dispongono di un file autorun.inf. Le versioni future di service pack e di Windows potrebbero funzionare diversamente. Dico "incredibilmente semplificata" perché l'algoritmo reale è una tabella decisioni a 61 passaggi che tiene conto di tutti i generi di tutte le informazioni come se l'applicazione in primo piano rispondesse alla notifica "Query cancel AutoPlay" (AutoPlay annullamento query), se è in esecuzione un programma a schermo intero, anche se si tratta di un computer portatile che è stato recentemente inserito nell'alloggiamento di espansione o da esso disinserito. Ma andiamo a esaminare solo il passaggio dell'analisi del contenuto.

In primo luogo, la shell verifica se l'utente ha specificato "Nessuna azione" come azione per tutti i tipi di contenuto. In tal caso, non viene eseguita alcuna analisi. La decisione è semplicemente "Nessuna azione".
In caso contrario, la shell deve esaminare ogni file sul disco (fino a quattro livelli di directory) e riunirli in una delle seguenti categorie in base al tipo rilevato: immagini, musica, filmati.
I file che non rientrano in una di queste categorie vengono ignorati. Se tra tutti i file esaminati è rappresentata soltanto una categoria (ad esempio, tutti i file sul disco sono file musicali), ciò determina il tipo di disco. Se è rappresentata più di una categoria, il disco viene considerato di contenuto misto.
Questo significa che la copertina album di un CD musicale fa sì che il CD sia considerato da Windows XP SP2 come CD di contenuto misto. Si tratta di una di quelle caratteristiche che potrebbero richiedere alcune modifiche. Ma si supponga che questo algoritmo sia stato modificato e che si decida che un'immagine occasionale su un CD di MP3 non debba far sì che un disco venga classificato come di contenuto misto. Un'azienda potrebbe avere un CD con file audio e solo qualche immagine. L'azienda, in verità, si basa sul fatto che il CD venga riconosciuto come di contenuto misto. Ma quando l'algoritmo viene modificato, il CD viene erroneamente classificato come musicale. E adesso quell'azienda ha un problema. Ma di chi è la colpa? Dell'azienda che fa affidamento sui dettagli dell'algoritmo di analisi? O di Windows che è responsabile di aver modificato l'algoritmo?
Ecco, in Windows Vista™, l'algoritmo è stato modificato, per quanto in misura minima. In Windows Vista, sono stati eseguiti diversi controlli per ignorare l'algoritmo per alcune configurazioni del disco ben note. Ad esempio, se nella directory principale del disco è presente una cartella DCIM, si presuppone sia composta da immagini digitali. Vedremo se qualcuno se ne accorge.

Raymond Chen, The Old New Thing (in inglese), come nel suo libro omonimo (Addison-Wesley, 2007), vengono illustrate la storia di Windows e la programmazione in Win32. Raymond si domanda a cosa somiglia il sole.