 TechNet Magazine April 2007
TechNet Magazine April 2007
APRIL 2007
Amministrazione di Windows

In questo numero Mark Russinovich riesamina di nuovo il kernel di Windows Vista per osservarne i miglioramenti riguardanti la protezione, l'affidabilità e il ripristino. Il ripristino di Active Directory è il protagonista di questo mese. Piuttosto che reagire di fronte a un'emergenza, programmare in anticipo un piano di ripristino Active Directory adatto allo scopo. Infine, prima di decidere se Windows XP Embedded non ha posto all'interno della tua organizzazione, continua a leggere, resterai sorpreso.

Gestione

Come raggiungere il giusto equilibrio tra capacità hardware ed efficienza dei costi? Questo mese spiegheremo il modo in cui System Center Capacity Planner consente di modellare i requisiti dell'infrastruttura per eseguire una corretta pianificazione. In aggiunta, vedremo come combinare Systems Management Server, WMI e lo script per una migliore creazione di report inventario clienti e come distribuire gli aggiornamenti personalizzati con SMS.
FUNZIONALITÀ
Amministrazione di Windows Il kernel di Windows Vista: parte 3

In questo numero, riassumiamo la discussione approfondita sulle novità nel kernel di Windows Vista. In quest'ultima puntata, verranno prese in considerazione le modifiche e le nuove funzionalità relative all'affidabilità, al ripristino e alla protezione.

Mark Russinovich Ripristino di emergenza: utenti e gruppi Active Directory

Il ripristino di dati in Active Directory può essere un'operazione molto complessa, tuttavia è necessario disporre di un piano di ripristino adeguato. Illustreremo come Active Directory memorizza, elimina, ripristina e replica gli oggetti in modo da poter essere pronti la prossima volta che viene cancellato accidentalmente un utente o un'appartenenza al gruppo.

Gil Kirkpatrick Perché Windows XP Embedded è importante

Forse non saprai che Windows XP Embedded potrebbe essere proprio quello che ci vuole per l'infrastruttura IT della tua organizzazione. Scopri come Windows XP Embedded può ridurre le spese generali di amministrazione, far risparmiare denaro e migliorare la protezione.

Don Jones Gestione Pianificare con System Center Capacity Planner

Un hardware insufficiente porta a tempi di risposta ridotti mentre un hardware eccessivo è uno spreco di risorse per il budget e l'amministrazione. Imparerai a utilizzare System Center Capacity Planner per modellare la rete e valutare con precisione le necessità dell'infrastruttura.

John Savill Inventari clienti avanzati con SMS

Microsoft Systems Management Server 2003 raccoglie molte informazioni, ma non abbastanza da soddisfare tutte le esigenze. Scopri come la combinazione di script, WMI e la conoscenza di SMS può consentire l'espansione di inventari SMS per raccogliere e creare report di ogni più piccola informazione.

Wes Dobry Distribuzione degli aggiornamenti software personalizzati con SMS 2003 R2

Systems Management Server 2003 R2 consente di utilizzare le funzionalità di gestione e aggiornamento per distribuire gli aggiornamenti personalizzati. Scopri due nuovi strumenti, Inventory Tool for Custom Updates e Custom Updates Publishing Tool, che consentono di distribuire gli aggiornamenti propri insieme a quelli di sviluppatori di terze parti.

Steve Rachui
COLONNE
Dal redattore

Potremmo sbagliarci...

Joshua Trupin Casella degli strumenti

Nuovi prodotti per professionisti IT

Greg Steen SQL: domande & risposte

Nuova creazione di indici, lunghezza della coda del disco e altro

A cura di Nancy Michell Utilità in primo piano

Autoruns

Lance Whitney The Cable Guy

Impostazioni dei Criteri di gruppo wireless per Windows Vista

Joseph Davies Windows PowerShell

Filtraggio e formattazione dei dati

Don Jones 		Hey, Scripting Guy!

Gestire in modo semplice utenti e gruppi locali

Gli Scripting Guys di Microsoft Controllo della protezione

Configurazione guidata della protezione

John Morello Desktop file

Con sistemi x64

Wes Miller Inside Microsoft.com

Come utilizzare Active Directory Federation Services

Jim Guthrie Taccuino

Le gioie (e i dolori) dell'apprendimento

Mark D. Scott Windows Confidential

Il potere dei bug

Raymond Chen


 Amministrazione di Windows: Il kernel di Windows Vista: parte 3
Amministrazione di Windows Mark Russinovich

Il kernel di Windows Vista: parte 3
Panoramica:
  • Affidabilità
  • Ripristino
  • Protezione

Con questa serie di articoli si sono analizzati i miglioramenti del kernel di Windows Vista relativi a processi, I/O, gestione della memoria, avvio del sistema, arresto del sistema e risparmio di energia. In questa terza e ultima puntata
vengono illustrati i miglioramenti apportati alle funzionalità nelle aree di affidabilità, ripristino e protezione.
Una funzionalità che non verrà esaminata in questa serie è il controllo dell'account utente, che comprende alcune tecnologie, tra cui la virtualizzazione di file system e Registro di sistema per le applicazioni legacy, il consenso all'elevazione per accedere ai diritti amministrativi e il meccanismo dei livelli di integrità di Windows® per isolare i processi in esecuzione con i diritti amministrativi dai processi meno-privilegiati in esecuzione nello stesso account. In uno dei prossimi numeri di TechNet Magazine sarà pubblicato un articolo interamente dedicato al controllo dell'account utente.
Windows Vista™ migliora l'affidabilità del sistema e la capacità di diagnosticare i problemi di sistema e applicazioni grazie a numerosi miglioramenti e nuove funzionalità. Traccia eventi per Windows (ETW) del kernel, ad esempio, è sempre attivo e genera eventi traccia per file, Registro di sistema, interrupt e altri tipi di attività in un buffer circolare. Quando si verifica un problema, la nuova Infrastruttura diagnostica Windows (WDI) cattura un'istantanea del buffer e l'analizza localmente oppure la invia al supporto Microsoft per la risoluzione del problema.
Il nuovo monitoraggio di affidabilità e prestazioni di Windows consente agli utenti di mettere in correlazione gli errori, come arresti anomali o blocchi del sistema, con le modifiche apportate alla configurazione del sistema. Lo strumento di riparazione del sistema (SRT) sostituisce la Console di ripristino di emergenza per il ripristino non in linea di sistemi che non si avviano.
Esistono tre ulteriori aree che hanno beneficiato delle modifiche a livello di kernel e quindi meritano un'attenzione particolare: Gestione transazioni kernel, la migliore gestione degli arresti anomali del sistema e Versioni precedenti.

Gestione transazioni kernel
Uno degli aspetti più noiosi dello sviluppo di software è la gestione delle condizioni di errore. Questo è soprattutto vero se, nel corso dell'esecuzione di un'operazione ad alto livello, un'applicazione completa uno o più sottoprocessi che apportano modifiche al file system o al Registro di sistema. Un servizio di aggiornamento software di un'applicazione, ad esempio, potrebbe apportare diverse modifiche al Registro di sistema, sostituire uno degli eseguibili dell'applicazione e non riuscire più a ottenere l'accesso per l'aggiornamento di un secondo eseguibile. Per non lasciare l'applicazione in uno stato incoerente, il servizio deve tenere traccia di tutte le modifiche eseguite ed essere in grado di annullarle. La verifica del codice di ripristino dall'errore è complessa e, di conseguenza, spesso ignorata. Gli errori nel codice di ripristino rendono quindi vano lo sforzo.
Le applicazioni scritte per Windows Vista sono in grado, con un minimo sforzo, di garantire funzionalità di ripristino dall'errore in modo automatico utilizzando il nuovo supporto transazionale in NTFS e il Registro di sistema con Gestione transazioni kernel. Quando un'applicazione deve eseguire numerose modifiche correlate, è possibile creare una transazione di Distributed Transaction Coordinator (DTC) e un handle di transazione di Gestione transazioni kernel oppure creare direttamente un handle di Gestione transazioni kernel e associare le modifiche dei file e delle chiavi del Registro di sistema alla transazione. Se tutte le modifiche riescono, l'applicazione esegue il commit della transazione e le modifiche vengono applicate, ma l'applicazione può revocare in qualsiasi momento la transazione e annullare le modifiche.
Un ulteriore vantaggio è costituito dal fatto che le altre applicazioni non rilevano le modifiche apportate in una transazione finché non viene eseguito il commit della transazione. Le applicazioni che utilizzano il DTC in Windows Vista e nel nuovo Windows Server® con nome in codice "Longhorn" potranno coordinare le transazioni con SQL Server™, Microsoft® Message Queue Server (MSMQ) e altri database. Un servizio di aggiornamento dell'applicazione che utilizza le transazioni di Gestione transazioni kernel non lascerà mai l'applicazione in uno stato incoerente. È per questo che in Windows Update e in Ripristino configurazione di sistema si utilizzano le transazioni.
In qualità di nucleo del supporto delle transazioni, Gestione transazioni kernel consente ai gestori delle risorse di transazione come NTFS e il Registro di sistema di coordinare i rispettivi aggiornamenti per una serie specifica di modifiche apportate da un'applicazione. In Windows Vista, NTFS utilizza un'estensione denominata TxF per il supporto delle transazioni. Il Registro di sistema utilizza un'estensione simile denominata TxR. Questi gestori delle risorse in modalità kernel collaborano con Gestione transazioni kernel per coordinare lo stato della transazione, proprio come i gestori delle risorse in modalità utente utilizzano DTC per coordinare lo stato della transazione in più gestori delle risorse in modalità utente. Anche le terze parti possono utilizzare Gestione transazioni kernel per implementare i propri gestori delle risorse.
TxF e TxR definiscono entrambi una nuova serie di API del file system e del Registro di sistema simili a quelli esistenti, con la differenza che questi contengono un parametro di transazione. Se un'applicazione deve creare un file all'interno di una transazione, viene dapprima utilizzato Gestione transazioni kernel per creare la transazione, quindi l'handle che ne risulta viene passato all'API della creazione del nuovo-file.
TxF e TxR si basano entrambi sulla funzionalità di registrazione del file system ad alta velocità del Common Log File System o CLFS (%SystemRoot%\System32\Clfs.sys) introdotto con Windows Server 2003 R2. TxR e TxF utilizzano CLFS per memorizzare in modo durevole le modifiche dello stato delle transazioni prima di eseguirne il commit. In tal modo le estensioni sono in grado di garantire ripristino transazionale e protezione anche in caso di interruzione dell'alimentazione. Oltre al registro di CLFS, TxR crea una serie di file di registro correlati per tenere traccia delle modifiche apportate dalle transazioni al file di Registro di sistema in %Systemroot%\System32\Config\Txr, come illustrato nella Figura 1, oltre a ulteriori serie di file di registro per ciascun hive del Registro di sistema dell'utente. TxF memorizza i dati di transazione per ciascun volume in una directory nascosta del volume denominata $Extend\$RmMetadata.
Figura 1 File di registrazione di TxR degli hive del Registro di sistema
Figura 1 File di registrazione di TxR degli hive del Registro di sistema (Fare clic sull'immagine per ridurla)
Figura 1 File di registrazione di TxR degli hive del Registro di sistema
Figura 1 File di registrazione di TxR degli hive del Registro di sistema (Fare clic sull'immagine per ingrandirla)

Miglior supporto in caso di arresto anomalo
Quando si verifica un errore in modalità kernel irreversibile, causato da un driver di dispositivo difettoso, da hardware guasto o dal sistema operativo, Windows tenta di evitare il danneggiamento dei dati memorizzati su disco arrestando il sistema dopo la famigerata "schermata blu" e, se così configurato, scrivendo il contenuto di parte o dell'intera memoria fisica in un file dei dettagli dell'arresto anomalo. I file con i dettagli dell'arresto anomalo sono utili perché, quando si riavvia il sistema dopo un arresto anomalo, il servizio Microsoft di analisi dell'arresto anomalo (OCA) può analizzarli alla ricerca della causa principale del problema. È possibile analizzare i file personalmente utilizzando gli strumenti di debug per Windows.
Nelle versioni precedenti di Windows, tuttavia, il supporto per il file con i dettagli dell'arresto anomalo non veniva attivato fino a che il processo Gestione sessione (%Systemroot%\System32\Smss.exe) non inizializzava i file di paging. Dunque un qualsiasi errore critico che si verificava prima di tale momento provocava una schermata blu senza però alcun file con i dettagli dell'arresto anomalo. Poiché l'inizializzazione dei driver di dispositivo viene eseguita prima dell'avvio di Smss.exe, gli arresti anomali che si verificavano prima di tale avvio non producevano file con i dettagli dell'arresto anomalo, rendendo così molto complessa la diagnosi della causa del problema.
Con Windows Vista il periodo di tempo in cui è possibile che si verifichino arresti anomali senza la generazione di un file con i dettagli si è ridotto in modo notevole. Ora il supporto del file con i dettagli dell'arresto anomalo viene inizializzato dopo l'avvio di tutti i driver di dispositivo, ma prima del caricamento dei driver di avvio del sistema. Grazie a questa modifica, quando si verifica un arresto anomalo durante la prima parte del processo di avvio, il sistema riesce a catturare i dettagli dell'arresto, consentendo a OCA di aiutare gli utenti a risolvere il problema. Inoltre, in Windows Vista i dati vengono salvati in un file di dump in blocchi di 64 KB, mentre nelle versioni precedenti di Windows il file veniva scritto utilizzando blocchi di 4 KB. Ne consegue che i file di dump di grandi dimensioni vengono scritti con velocità fino a 10 volte maggiori.
In Windows Vista è migliorata anche la gestione dei blocchi delle applicazioni. Quando un'applicazione si bloccava nelle versioni precedenti di Windows, eseguiva un gestore di eccezioni non gestite. Il gestore avviava il processo Segnalazione errori applicazioni Microsoft (AER) (%Systemroot%\System32\Dwwin.exe) e veniva visualizzata una finestra di dialogo con cui si informava l'utente del blocco di un'applicazione e si richiedeva di inviare una segnalazione di errore a Microsoft. Tuttavia, se lo stack del thread principale del processo veniva danneggiato durante il blocco, anche il gestore di eccezioni non gestite si bloccava durante l'esecuzione. Ne risultavano l'interruzione del processo da parte del kernel, la scomparsa immediata delle finestre del programma e l'assenza della finestra di dialogo di segnalazione errori.
In Windows Vista la gestione degli errori viene sottratta al contesto del processo bloccato grazie a un nuovo servizio, Segnalazione errori Windows (WER). Il servizio è implementato da una DLL (%Systemroot%\System32\Wersvc.dll) all'interno di un processo di hosting di servizi. Quando si blocca, l'applicazione esegue ancora un gestore di eccezioni non gestite, ma il gestore invia un messaggio al servizio WER e il servizio avvia il processo Segnalazione problemi di WER (%Systemroot%\System32\Werfault.exe) visualizzando una finestra di dialogo di segnalazione degli errori. Se lo stack è danneggiato e il gestore di eccezioni non gestite si blocca, il gestore viene eseguito e si blocca di nuovo occupando alla fine tutto lo stack del thread (spazio della memoria di lavoro), interviene il kernel che invia il messaggio di notifica del blocco al servizio.
È possibile apprezzare la differenza fra questi due approcci nelle figure 2 e 3, che illustrano il rapporto tra i processi di Accvio.exe, un programma di test che si blocca, e i processi di segnalazione degli errori evidenziati in verde, in Windows XP e Windows Vista. La nuova architettura di Windows Vista per la gestione degli errori prevede che i programmi non vengano più interrotti in modo invisibile all'utente, senza offrire a Microsoft la possibilità di ottenere un resoconto e agli sviluppatori di software l'opportunità di migliorare le applicazioni.
Figura 2a Gestione degli errori delle applicazioni in Windows XP
Figura 2a Gestione degli errori delle applicazioni in Windows XP (Fare clic sull'immagine per ridurla)
Figura 2a Gestione degli errori delle applicazioni in Windows XP
Figura 2a Gestione degli errori delle applicazioni in Windows XP (Fare clic sull'immagine per ingrandirla)
Figura 2b
Figura 2b (Fare clic sull'immagine per ridurla)
Figura 2b
Figura 2b (Fare clic sull'immagine per ingrandirla)
Figura 3a Gestione degli errori delle applicazioni in Windows Vista
Figura 3a Gestione degli errori delle applicazioni in Windows Vista (Fare clic sull'immagine per ridurla)
Figura 3a Gestione degli errori delle applicazioni in Windows Vista
Figura 3a Gestione degli errori delle applicazioni in Windows Vista (Fare clic sull'immagine per ingrandirla)
Figura 3b
Figura 3b

Copia Shadow del volume
Con Windows XP è stata introdotta una tecnologia denominata Copia Shadow del volume per creare istantanee temporizzate dei volumi di un disco. Le applicazioni di backup possono utilizzare queste istantanee per ottenere immagini di backup coerenti, ma le istantanee restano altrimenti nascoste e conservate solo per la durata del processo di backup.
Le istantanee non sono delle copie complete dei volumi. Sono piuttosto delle viste di un volume da un punto precedente che comprende i dati del volume sostituiti dalle copie di settori di volume modificati dopo lo scatto dell'istantanea. Il driver del provider di istantanee di volume (%Systemroot\%System32\Drivers\Volsnap.sys) controlla le operazioni eseguite con i volumi ed esegue copie di backup dei settori prima di consentirne la modifica, memorizzando i dati originali in un file associato all'istantanea nella directory delle informazioni del volume di sistema del volume.
In Windows Server 2003 la gestione delle istantanee era disponibile agli amministratori sul server e agli utenti sui sistemi client grazie alle copie shadow per cartelle condivise. Questa funzionalità consentiva di scattare istantanee persistenti, a cui gli utenti potevano accedere tramite la scheda Versioni precedenti delle finestre di dialogo delle proprietà di Esplora risorse relative alle cartelle e ai file archiviati nelle condivisioni del server.
Con la funzionalità Versioni precedenti di Windows Vista il supporto è stato esteso a tutti i sistemi client, con la creazione automatica di istantanee di volume, in genere una volta al giorno, a cui è possibile accedere tramite le finestre di dialogo delle proprietà di Esplora risorse, utilizzando la stessa interfaccia utilizzata dalle copie shadow per cartelle condivise. È quindi possibile visualizzare, ripristinare o copiare le versioni precedenti di file e directory modificati o eliminati accidentalmente. L'implementazione di Versioni precedenti della funzionalità Copia Shadow del volume di Windows Vista, sebbene non sia una tecnologia del tutto nuova, ottimizza la funzionalità omologa di Windows Server 2003 per l'uso negli ambienti dei desktop client.
In Windows Vista si sfruttano inoltre le istantanee di volume per unificare i meccanismi di protezione dei dati di utente e sistema ed evitare il salvataggio di dati di backup ridondanti. Quando una modifica apportata all'installazione o configurazione di un'applicazione causa dei comportamenti errati o non desiderati, è possibile utilizzare Ripristino configurazione di sistema, una funzionalità introdotta nella linea di sistemi operativi Windows NT ® con Windows XP, per ripristinare lo stato di file di sistema e dati esistente al momento della creazione del punto di ripristino.
In Windows XP la funzionalità Ripristino configurazione di sistema utilizza un driver di filtro del file system, un tipo di driver in grado di rilevare le modifiche a livello di file, per eseguire copie di backup dei file di sistema subito prima della modifica. In Windows Vista la funzionalità Ripristino configurazione di sistema utilizza le istantanee di volume. Quando si utilizza l'interfaccia utente di Ripristino configurazione di sistema in Windows Vista per tornare a un punto di ripristino, si copiano le versioni precedenti dei file di sistema modificati dall'istantanea associata al punto di ripristino nel volume corrente.

BitLocker
Windows Vista è la versione di Windows meglio protetta mai prodotta. Oltre al motore antispyware di Windows Defender, in Windows Vista sono state implementate molte funzionalità di protezione e difesa, tra cui la crittografia di un intero volume con BitLocker™, la firma del codice per il codice in modalità kernel, i processi protetti, la sequenza casuale di caricamento nello spazio degli indirizzi e i miglioramenti della protezione del servizio Windows e del controllo degli account utente.
Un sistema operativo può applicare i propri criteri di protezione solo quando è attivo, quindi è necessario adottare misure aggiuntive per proteggere i dati quando la protezione fisica di un sistema può essere compromessa con un accesso non autorizzato ai dati dall'esterno del sistema operativo. I meccanismi basati sull'hardware come le password del BIOS e la crittografia sono due delle tecnologie più diffuse per impedire l'accesso non autorizzato, soprattutto nei computer portatili, che sono più soggetti a smarrimento o furto.
In Windows 2000 è stata introdotta la Crittografia file system (EFS) e, nella rispettiva incarnazione di Windows Vista, all'EFS sono stati apportati numerosi miglioramenti rispetto alle implementazioni precedenti, con miglioramento delle prestazioni, supporto per la codifica del file di paging e archiviazione delle chiavi EFS dell'utente su smart card. Non è tuttavia possibile utilizzare EFS per proteggere l'accesso ad aree sensibili del sistema, come i file di hive del Registro di sistema. Se, ad esempio, Criteri di gruppo consente di accedere al computer portatile anche quando non si è connessi a un dominio, i sistemi di verifica delle credenziali di dominio vengono memorizzati nella cache del Registro di sistema, in modo che un utente malintenzionato possa utilizzare degli strumenti per ottenere l'hash della password dell'account di dominio da impiegare per tentare di ottenere la password con uno strumento apposito. La password consentirebbe agli utenti malintenzionati di accedere all'account e ai file EFS (se non si è memorizzata la chiave EFS su una smart card).
Per facilitare la crittografia completa del volume di avvio (il volume con la directory di Windows), compresi tutti i file di sistema e i dati, in Windows Vista è stata aggiunta una funzionalità per la crittografia dell'intero volume denominata Crittografia unità BitLocker di Windows. A differenza di EFS, che viene implementato dal driver del file system NTFS e opera a livello di file, BitLocker esegue la crittografia a livello di volume utilizzando il driver FVE (Full Volume Encryption) (%Systemroot%\System32\Drivers\Fvevol.sys) come illustrato nella Figura 4.
Figura 4 Driver di filtro FVE di BitLocker
Figura 4 Driver di filtro FVE di BitLocker (Fare clic sull'immagine per ridurla)
Figura 4 Driver di filtro FVE di BitLocker
Figura 4 Driver di filtro FVE di BitLocker (Fare clic sull'immagine per ingrandirla)
FVE è un driver di filtro ed è in grado di rilevare automaticamente tutte le richieste di I/O inviate da NTFS al volume, crittografando i blocchi alla scrittura e decrittografandoli quando vengono letti utilizzando la chiave FVEK assegnata al volume durante la configurazione iniziale per BitLocker. Per impostazione predefinita, i volumi vengono crittografati utilizzando una chiave AES a 128 bit e una chiave di diffusione a 128 bit. Poiché crittografia e decrittografia avvengono sotto NTFS nel sistema di I/O, il volume appare a NTFS come se fosse decrittografato e non è nemmeno necessario che NTFS rilevi l'attivazione di BitLocker. Se di tenta di leggere i dati del volume dall'esterno di Windows, tuttavia, i dati sembrano essere casuali.
La FVEK viene crittografata con una chiave master del volume (VMK) e viene memorizzata in un'area di metadati speciale del volume. Quando si configura BitLocker, è possibile scegliere tra alcune opzioni per la protezione della VMK, a seconda dell'hardware del sistema. Se nel sistema è disponibile un TPM (Trusted Platform Module) conforme alla v1.2 delle specifiche TPM con il supporto del BIOS associato, sarà possibile crittografare la VMK con il TPM, impostare il sistema in modo che la VMK venga crittografata utilizzando una chiave memorizzata nel TPM e un'altra memorizzata su un dispositivo flash USB oppure crittografare la chiave utilizzando una chiave memorizzata nel TPM e un PIN immesso all'avvio del sistema. Per i sistemi che non dispongono di un TPM, BitLocker consente di crittografare la VMK utilizzando una chiave memorizzata su un dispositivo flash USB esterno. In tutti i casi sarà necessario un volume di sistema NTFS da 1,5 GB non crittografato, il volume in cui memorizzare Boot Manager e dati di configurazione di avvio (BCD).
Il vantaggio dell'utilizzo di un TPM consiste nella possibilità di utilizzare le funzionalità del TPM con BitLocker per garantire che la VMK non venga decrittografata e il volume di avvio sbloccato se il BIOS o i file di avvio del sistema risultano modificati rispetto al momento dell'attivazione di BitLocker. Quando si crittografa il volume di sistema per la prima volta, e ogni volta che si esegue l'aggiornamento di uno dei componenti menzionati, BitLocker calcola l'hash SHA-1 di tale componente e memorizza ciascun hash, definito misura, in registri di configurazione di piattaforma (PCR) diversi del TPM con l'aiuto del driver di dispositivo TPM (%Systemroot%\System32\Drivers\Tpm.sys). BitLocker utilizza quindi il TPM per eseguire il sealing della VMK, un'operazione che prevede l'impiego di una chiave privata memorizzata nel TPM per crittografare la VMK e i valori memorizzati nei PCR, insieme agli altri dati che BitLocker passa al TPM. BitLocker memorizza quindi la VMK sottoposta a sealing e la FVEK crittografata nella regione di metadati del volume.
Quando viene avviato, il sistema misura il proprio hash e il codice di caricamento del PCR e scrive l'hash nel primo PCR del TPM. Quindi viene eseguito l'hash del BIOS e tale misura viene memorizzata nel PCR appropriato. Il BIOS esegue invece l'hash del componente successivo nella sequenza di avvio, ovvero il Record di avvio principale (MBR) del volume di avvio, e questo processo continua fino a quando non viene misurato il caricatore del sistema operativo. Ciascuna porzione successiva di codice eseguita è responsabile della misurazione del codice caricato e della memorizzazione della misurazione nel registro del TPM appropriato. Quando, infine, l'utente sceglie il sistema operativo da avviare, il Boot Manager (Bootmgr) legge la VMK crittografata dal volume e chiede al TPM di rimuovere il sealing. Il TPM eseguirà la decrittografia corretta della VMK solo se tutte le misurazioni sono rimaste identiche rispetto al momento del sealing della VMK, compreso il PIN facoltativo.
È possibile immaginare questo schema come una catena di verifica, dove ciascun componente della sequenza di avvio descrive al TPM il componente successivo. Il TPM divulgherà il segreto solo se tutte le descrizioni corrispondono a quelle originali. BitLocker quindi protegge i dati crittografati anche quando il disco viene rimosso e collocato in un altro sistema, il sistema viene avviato utilizzando un sistema operativo diverso oppure i file non decrittografati del volume di avvio sono danneggiati.

Verifica dell'integrità del codice
Il malware implementato come driver di dispositivo in modalità kernel, compresi i rootkit, viene eseguito allo stesso livello di privilegio del kernel ed è quindi il più difficile da individuare e rimuovere. Il malware di questo tipo può modificare il comportamento del kernel e degli altri driver in modo da diventare praticamente invisibile. L'integrità del codice di Windows Vista per la funzionalità del codice in modalità kernel, anche definita firma codice in modalità kernel (KMCS), consente il caricamento dei driver di dispositivo solo se questi sono pubblicati e firmati in modo digitale da sviluppatori vagliati da una delle poche autorità di certificazione (CA). KMCS viene applicato per impostazione predefinita a Windows Vista per i sistemi a 64 bit.
Poiché le autorità di certificazione richiedono il versamento di una tariffa per i servizi forniti ed eseguono verifiche di base in background, come l'identità dell'azienda, è molto difficile produrre malware anonimo in modalità kernel che possa essere eseguito in Windows Vista a 64 bit. È inoltre possibile che il malware che riesce a superare i processi di verifica lasci degli indizi che consentano di risalire all'autore, quando il malware viene scoperto su un sistema attaccato. Sono previsti anche usi secondari di KMCS, come l'invio delle informazioni sul contatto al team OCA di Windows quando si sospetta che un driver difettoso provochi l'arresto anomalo dei sistemi del cliente e lo sblocco del contenuto multimediale ad alta definizione.
KMCS utilizza le tecnologie di crittografia a chiave pubblica impiegate per oltre un decennio da Windows e richiede che nel codice in modalità kernel sia presente una firma digitale generata da una delle autorità di certificazione attendibili. Se un produttore di software presenta un driver al laboratorio per la qualità dell'hardware Windows (WHQL) di Microsoft e il driver supera i test di affidabilità, Microsoft diventa l'autorità di certificazione che firma il codice. La maggior parte dei produttori otterrà le firme da WHQL, ma quando un driver non partecipa al programma di test di WHQL, il produttore non intende sottoporre il driver ai test di WHQL o il driver è un driver di avvio che viene caricato nella fase iniziale dell'avvio di sistema, i produttori devono firmare direttamente il proprio codice. A tal fine, i produttori devono dapprima ottenere un certificato di firma del codice rilasciato da una delle autorità di certificazione che Microsoft riconosce come attendibile per firmare il proprio codice in modalità kernel. Il produttore quindi esegue l'hash digitale del codice, firma l'hash crittografandolo con una chiave privata e inserisce certificato e hash crittografato nel codice.
Quando viene tentato il caricamento di un driver, Windows decrittografa l'hash contenuto nel codice utilizzando la chiave pubblica memorizzata nel certificato, quindi verifica che l'hash corrisponda a quello contenuto nel codice. L'autenticità del certificato viene verificata allo stesso modo, ma con l'utilizzo della chiave pubblica dell'autorità di certificazione, che è contenuta in Windows.
Windows verifica anche i concatenamenti di certificati associati fino a una delle autorità principali incorporate nel caricatore di avvio di Windows e nel kernel del sistema operativo. È preferibile non tentare mai di caricare un driver a 64 bit non firmato su un sistema di produzione. A differenza della gestione dei componenti Plug and Play, che prevede la visualizzazione di una finestra di dialogo di avviso quando viene richiesto il caricamento di un driver non firmato con la conferma che è stato testato da WQHL, in Windows Vista a 64 bit viene scritto un evento nel registro eventi dell'applicazione di controllo dell'integrità del codice in modo invisibile all'utente, come quello visualizzato nella Figura 5, ogni volta che viene bloccato il caricamento di un driver non firmato. Anche in Windows Vista a 32 bit vengono controllate le firme dei driver, ma viene consentito il caricamento dei driver non firmati. Il blocco di tali driver comporterebbe problemi con i sistemi Windows XP aggiornati che richiedono i driver caricati in Windows XP e che consentono il supporto per l'hardware per cui esistono solo driver di Windows XP. Tuttavia, anche in Windows Vista a 32 bit vengono scritti degli eventi nel registro eventi dell'applicazione di controllo dell'integrità del codice quando viene caricato un driver non firmato.
Figura 5 Eventi di tentativo di caricamento di driver non firmati
Figura 5 Eventi di tentativo di caricamento di driver non firmati (Fare clic sull'immagine per ridurla)
Figura 5 Eventi di tentativo di caricamento di driver non firmati
Figura 5 Eventi di tentativo di caricamento di driver non firmati (Fare clic sull'immagine per ingrandirla)
Poiché la firma del codice viene comunemente utilizzata per etichettare il codice come una versione ufficiale rigorosamente verificata, in genere i produttori evitano di firmare il codice di prova. In Windows Vista è quindi disponibile una modalità di firma delle versioni di prova che è possibile attivare e disattivare con lo strumento Bcdedit (descritto nel mio su TechNet Magazine del marzo 2007), che prevede il caricamento di driver in modalità kernel firmati digitalmente con un certificato di prova generato da un'autorità di certificazione interna. Questa modalità è stata progettata per l'uso da parte dei programmatori durante lo sviluppo del codice. Quando Windows viene utilizzato in questa modalità, sul desktop vengono visualizzati dei contrassegni, come nella Figura 6.
Figura 6 Modalità con firma di prova di Windows Vista
Figura 6 Modalità con firma di prova di Windows Vista

Processi protetti
Il contenuto multimediale di prossima generazione, come HD-DVD, BluRay e altri formati registrati sotto AACS (Advanced Access Content System), si diffonderà sempre più negli anni a venire. In Windows Vista sono state integrate alcune tecnologie, definite collettivamente PMP (Protected Media Path), richieste dallo standard AACS per la riproduzione di questo tipo di contenuto. PMP comprende PUMA (Protected User-Mode Audio) e PVP (Protected Video Path) che insieme forniscono i meccanismi per i driver audio e video, oltre alle applicazioni di riproduzione di contenuto multimediale, per evitare l'acquisizione nel formato ad alta definizione con software o hardware non autorizzato.
PUMA e PVP definiscono interfacce e supporto specifici per i riproduttori di audio e video, i driver di dispositivo e l'hardware, ma PMP è inoltre basato su un meccanismo kernel generico introdotto in Windows Vista e definito "processo protetto". I processi protetti si basano sul costrutto del processo Windows standard che incapsula un'immagine eseguibile in esecuzione, le DLL corrispondenti, il contesto di protezione (l'account in cui viene eseguito il processo e i relativi privilegi di protezione) e i thread che eseguono il codice all'interno del processo, ma impedisce determinati tipi di accesso.
I processi standard implementano un modello di controllo dell'accesso che consente l'accesso completo al proprietario del processo e agli account amministrativi con il privilegio Debug di programmi. L'accesso completo consente a un utente di visualizzare e modificare lo spazio degli indirizzi del processo, compreso il codice e i dati associati nel processo. Gli utenti possono anche inserire dei thread nel processo. Questi tipi di accesso non sono compatibili con i requisiti di PMP, perché consentirebbero l'accesso al contenuto ad alta definizione e alle chiavi DRM (Digital Rights Management) memorizzate in un processo che riproduce il contenuto da parte di codice non autorizzato.
I processi protetti limitano l'accesso a una serie ridotta di interfacce informative e di gestione dei processi, che comprendono le query per il nome immagine del processo e l'interruzione o sospensione del processo. Il kernel rende, tuttavia, disponibili le informazioni diagnostiche sui processi protetti tramite le funzioni generiche di query dei processi, che restituiscono dati relativi a tutti i processi di un sistema e non richiedono l'accesso diretto al processo. Gli accessi che potrebbero danneggiare dei supporti sono consentiti soltanto ad altri processi protetti.
Inoltre, per evitare attacchi dall'interno, tutto il codice eseguibile caricato in un processo protetto, comprese l'immagine eseguibile e le DLL corrispondenti, deve essere firmato da Microsoft (WHQL) con un flag di ambiente protetto (PE) oppure, se è un codec audio, firmato dallo sviluppatore con un certificato DRM ottenuto da Microsoft. Poiché il codice in modalità kernel può ottenere accesso completo a qualunque processo, compresi i processi protetti, e Windows a 32 bit consente il caricamento di codice in modalità kernel non firmato, il kernel fornisce un'API per i processi protetti che richiede la "pulizia" dell'ambiente in modalità kernel e utilizza il risultato per sbloccare il contenuto solo se non viene caricato codice non firmato.
Individuazione di un processo protetto
Non esistono API che identifichino in modo specifico i processi protetti, ma è possibile individuarli in modo indiretto in base alla quantità ridotta di informazioni disponibili e all'impossibilità di eseguirne il debug anche da un account amministrativo. Il processo Isolamento grafico dispositivo audio (%Systemroot%\System32\Audiodg.exe) viene utilizzato per riprodurre i DVD codificati con il sistema CSS (Content Scramble System) ed è identificabile come processo protetto nel riquadro di Gestione attività per il fatto che in Gestione attività non è possibile ottenere la riga di comando, la virtualizzazione e lo stato di Protezione esecuzione programmi corrispondenti, anche quando il processo viene eseguito con diritti amministrativi.
Visualizzazione in Gestione attività del processo protetto audiodg
Visualizzazione in Gestione attività del processo protetto audiodg (Fare clic sull'immagine per ridurla)
Visualizzazione in Gestione attività del processo protetto audiodg
Visualizzazione in Gestione attività del processo protetto audiodg (Fare clic sull'immagine per ingrandirla)

Sequenza casuale di caricamento nello spazio degli indirizzi
Malgrado le contromisure come Protezione esecuzione programmi e la verifica avanzata degli errori del compilatore, gli autori di malware continuano a trovare vulnerabilità di overflow del buffer che consentono di contagiare i processi aperti alla rete, come Internet Explorer®, i servizi Windows e le applicazioni di terze parti, per stabilire delle teste di ponte in un sistema. Una volta attaccato un processo, tuttavia, gli utenti malintenzionati devono utilizzare le API Windows per raggiungere lo scopo di leggere i dati dell'utente o stabilire una presenza permanente, modificando le impostazioni della configurazione di utente o sistema.
La connessione di un'applicazione con i punti di ingresso dell'API esportati da DLL viene di solito gestita dal caricatore del sistema operativo, ma questi tipi di attacchi da malware non ottengono i vantaggi dei servizi del caricatore. Questo non rappresentava un problema per il malware nelle versioni precedenti di Windows, perché in tutte le versioni di Windows, immagini eseguibili di sistema e DLL venivano sempre caricate nella stessa posizione, consentendo al malware di presupporre gli indirizzi fissi di residenza delle API.
La funzione di sequenza casuale di caricamento nello spazio degli indirizzi (ASLR) di Windows Vista rende impossibile per il malware indovinare gli indirizzi delle API, caricando DLL di sistema ed eseguibili in una posizione diversa a ogni avvio del sistema. Nelle prime fasi del processo di avvio, Memory Manager sceglie a caso una modalità di caricamento dell'immagine DLL dai 256 diversi indirizzi allineati a 64 KB nell'area di 16 MB nella parte superiore dello spazio degli indirizzi in modalità utente. Non appena delle DLL con il nuovo flag di rilocazione dinamica nell'intestazione dell'immagine vengono caricate in un processo, Memory Manager le inserisce in memoria a partire dall'indirizzo di caricamento immagine scelto in modo casuale.
Gli eseguibili con il flag vengono trattati in modo simile, con il caricamento in un punto allineato a 64 KB casuale all'interno dei 16 MB dell'indirizzo di caricamento di base memorizzato nell'intestazione dell'immagine corrispondente. Inoltre, se una DLL o un eseguibile viene caricato di nuovo dopo essere stato scaricato da tutti i processi che lo utilizzano, Memory Manager seleziona un'altra posizione casuale per il caricamento. Nella Figura 7 viene illustrato un esempio di disposizione dello spazio degli indirizzi per un sistema Windows Vista a 32 bit, che comprende le aree da cui ASLR sceglie la modalità di caricamento immagini e l'indirizzo di caricamento dell'eseguibile.
Figura 7 Effetto di ASLR sugli indirizzi di caricamento di eseguibile e DLL
Figura 7 Effetto di ASLR sugli indirizzi di caricamento di eseguibile e DLL (Fare clic sull'immagine per ridurla)
Figura 7 Effetto di ASLR sugli indirizzi di caricamento di eseguibile e DLL
Figura 7 Effetto di ASLR sugli indirizzi di caricamento di eseguibile e DLL (Fare clic sull'immagine per ingrandirla)
Vengono rilocate solo le immagini con un flag di rilocazione dinamica, tra cui tutti gli eseguibili e le DLL di Windows Vista, poiché lo spostamento di immagini legacy potrebbe influire sulla logica interna utilizzata dagli sviluppatori per il caricamento delle immagini corrispondenti. Visual Studio® 2005 SP1 supporta l'impostazione del flag, in modo che gli sviluppatori di terze parti possano sfruttare i vantaggi offerti da ASLR.
La sequenza casuale di scelta degli indirizzi di caricamento delle DLL tra le 256 posizioni disponibili non rende impossibile l'individuazione della posizione effettiva di un'API da parte del malware, ma riduce in modo significativo la velocità con cui si propaga un worm di rete ed evita il malware che può contare su una sola possibilità per attaccare il sistema. Inoltre, la strategia di rilocazione di ASLR ha l'ulteriore vantaggio rappresentato da spazi degli indirizzi più densi rispetto alle versioni precedenti di Windows, con la creazione di aree più ampie di memoria libera per allocazioni di memoria contigue, la riduzione del numero di tabelle pagine allocate da Memory Manager per tenere traccia della disposizione dello spazio degli indirizzi e la riduzione al minimo degli errori del TLB (Translation Lookaside Buffer).

Miglioramento della protezione dei servizi
I servizi windows sono i bersagli ideali del malware. Molti dei servizi offrono accesso in rete alle funzionalità dei malware, esponendo a volte in modalità remota un accesso al sistema, mentre la maggior parte dei servizi viene eseguito con un privilegio superiore al semplice account utente standard, offrendo la possibilità di elevare i privilegi su un sistema locale nei casi in cui si dimostrino attaccabili da un malware. Per questo motivo, è iniziata un'evoluzione di Windows a partire dalle modifiche apportate a Windows XP SP2, con cui si sono ridotti al minimo necessario per i rispettivi ruoli i privilegi e gli accessi assegnati ai servizi. In Windows XP SP2, ad esempio, sono stati introdotti gli account Servizio locale e Servizio di rete, che prevedono solo un sottoinsieme dei privilegi disponibili per l'account in cui venivano sempre eseguiti i servizi in precedenza, ovvero Sistema locale. In tal modo si riduce al minimo l'accesso che un utente malintenzionato riesce a ottenere sfruttando un servizio.
ASLR in azione
È possibile notare gli effetti di ASLR paragonando gli indirizzi di caricamento delle DLL per un processo in due diverse sessioni di avvio, utilizzando uno strumento come Process Explorer di Sysinternals. In queste due schermate, acquisite in due sessioni diverse, Ntdll.dll è stato caricato prima all'indirizzo 0x77A30000, quindi all'indirizzo 0x77750000.
Indirizzi di base diversi per ntdll.dll
Indirizzi di base diversi per ntdll.dll (Fare clic sull'immagine per ridurla)
Indirizzi di base diversi per ntdll.dll
Indirizzi di base diversi per ntdll.dll (Fare clic sull'immagine per ingrandirla)
Indirizzi di base diversi per ntdll.dll
Indirizzi di base diversi per ntdll.dll (Fare clic sull'immagine per ridurla)
Indirizzi di base diversi per ntdll.dll
Indirizzi di base diversi per ntdll.dll (Fare clic sull'immagine per ingrandirla)

Nell'articolo precedente si è descritto come i servizi vengano eseguiti isolati dagli account utente nella rispettiva sessione, ma in Windows Vista viene esteso l'utilizzo del principio dei privilegi minimi, in modo da ridurre ulteriormente i privilegi e l'accesso ai file, alle chiavi del Registro di sistema e alle porte del firewall a cui viene assegnata la maggior parte dei servizi. In Windows Vista viene definito un nuovo account di gruppo, denominato Identificatore di protezione (SID), univoco per ciascun servizio. Il servizio può impostare le autorizzazioni per le proprie risorse in modo da consentire l'accesso solo al proprio SID, impedendo ai servizi eseguiti sotto lo stesso account utente di accedere quando un servizio viene attaccato. È possibile visualizzare il SID di un servizio utilizzando il comando sc showsid seguito dal nome del servizio, come nella Figura 8.
Figura 8 Visualizzazione di un SID di servizio
Figura 8 Visualizzazione di un SID di servizio (Fare clic sull'immagine per ridurla)
Figura 8 Visualizzazione di un SID di servizio
Figura 8 Visualizzazione di un SID di servizio (Fare clic sull'immagine per ingrandirla)
I SID di servizio proteggono l'accesso alle risorse di proprietà di un determinato servizio, ma per impostazione predefinita i servizi possono comunque accedere a tutti gli oggetti a cui è autorizzato ad accedere l'account utente sotto cui vengono eseguiti. Un servizio eseguito, ad esempio, sotto l'account Servizio locale potrebbe non essere in grado di accedere alle risorse create da un altro servizio, eseguito come Servizio locale in un altro processo, che ha protetto i propri oggetti con autorizzazioni che fanno riferimento a un SID di servizio. Tuttavia, lo stesso servizio può leggere e può scrivere in qualsiasi oggetto a cui Servizio locale è autorizzato ad accedere (eventuali gruppi di cui fa parte Servizio locale, come il gruppo Servizio).
Con Windows Vista viene quindi introdotto un nuovo tipo di servizio limitato, definito come servizio limitato in scrittura, che consente l'accesso in scrittura a un servizio solo per gli oggetti accessibili al SID di servizio corrispondente, al gruppo Everyone e al SID assegnato alla sessione di accesso. A tal fine, si utilizzano i SID limitati, un tipo di SID già implementato in Windows 2000. Quando il processo che apre un oggetto è un servizio limitato in scrittura, l'algoritmo di controllo dell'accesso viene modificato in modo che non sia possibile utilizzare un SID non assegnato a un processo, in entrambi i formati limitato e non limitato, per concedere al processo l'accesso in scrittura a un oggetto. È possibile individuare un servizio limitato con il comando seguente:
sc qsidtype [service]
Un'altra modifica consente a un servizio di impedire agli altri servizi in esecuzione sotto lo stesso account di accedere agli oggetti creati. Nelle versioni precedenti di Windows il creatore di un oggetto diventava anche il proprietario dell'oggetto e i proprietari potevano leggere e modificare le autorizzazioni dei propri oggetti, con un accesso completo ai propri oggetti. In Windows Vista è stato adottato il nuovo SID Diritti proprietario che, se presente nelle autorizzazioni di un oggetto, può limitare gli accessi garantiti a un proprietario per il proprio oggetto, eliminando addirittura i diritti di impostazione e query delle autorizzazioni.
Un ulteriore miglioramento al modello di protezione dei servizi in Windows Vista consente a uno sviluppatore di servizi di specificare con precisione i privilegi di protezione necessari al servizio per operare quando il servizio si registra in un sistema. Se, ad esempio, il servizio deve generare degli eventi di controllo, necessiterà del privilegio Controllo.
Quando avvia un processo che ospita uno o più servizi Windows, Gestione controllo servizi crea un token di protezione (l'oggetto kernel in cui sono riportati un account utente di processo, le appartenenze al gruppo e i privilegi di protezione) per il processo che comprende solo i privilegi richiesti dai servizi inclusi nel processo. Se un servizio specifica un privilegio che non è disponibile per l'account in cui viene eseguito, il servizio non verrà avviato. Quando nessuno dei servizi in esecuzione in un processo di un account Servizio locale necessita del privilegio Debug di programmi, ad esempio, Gestione controllo servizi elimina il privilegio dal token di protezione del processo. In tal modo, se il processo del servizio viene attaccato, il codice dannoso non potrà sfruttare privilegi che non siano stati esplicitamente richiesti dai servizi in esecuzione nel processo. Il comando sc qprivs consente di visualizzare i privilegi richiesti da un servizio.

Conclusioni
Con questo articolo si conclude l'analisi in tre parti delle modifiche apportate al kernel di Windows Vista. Esistono altri miglioramenti e funzionalità che non sono stati descritti o menzionati, come un nuovo un pool dei thread di lavoro per gli sviluppatori di applicazioni, nuovi meccanismi di sincronizzazione come i blocchi in lettura/scrittura condivisi, la codifica dei thread dei servizi, il supporto per il controllo del disco e il ridimensionamento del volume NTFS in linea e un nuovo meccanismo IPC del kernel denominato di ALPC (Advanced Local Procedure Call). Ulteriori informazioni su queste e altre funzionalità saranno riportate nella prossima edizione di Windows Internals prevista per la fine del 2007.
Visualizzazione del servizio limitato in scrittura
Un solo processo che ospita servizi di Windows Vista contiene servizi limitati ed è possibile identificarlo come il processo con la riga di comando con uno strumento di visualizzazione dei processi come Process Explorer:
svchost -k LocalServiceNoNetwork
I servizi configurati per l'esecuzione in questo processo sono Base Filtering Engine, Servizio Criteri di diagnostica, Windows Firewall, Avvisi e registri di prestazioni e l'avviatore del servizio Windows Media® Center.
In questa schermata viene illustrato il formato testuale del SID di servizio di Base Filtering Engine, NT SERVICE\BFE, riportato una volta con il flag Con restrizioni e una volta senza, dunque il processo può accedere alle risorse accessibili per l'account. Non è tuttavia detto che possa accedere ad altri oggetti in genere accessibili per l'account Servizio locale. Poiché, ad esempio, l'account NT AUTHORITY\SERVICE non è riportato nel token di processo con il flag Con restrizioni, il processo non può modificare gli oggetti che concedono l'accesso in scrittura solo a tale account ma non agli altri account del token con il flag Con restrizioni.
Anche i servizi che vengono eseguiti in questo processo dispongono di privilegi limitati, perché i privilegi elencati nella parte inferiore della finestra di dialogo delle proprietà sono un sottoinsieme dei privilegi disponibili per l'account Servizio locale.
Flag SID su un servizio
Flag SID su un servizio (Fare clic sull'immagine per ridurla)
Flag SID su un servizio
Flag SID su un servizio (Fare clic sull'immagine per ingrandirla)

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


 Amministrazione Windows - : Ripristino di emergenza: utenti e gruppi di Active Directory
Amministrazione Windows - Gil Kirkpatrick

Ripristino di emergenza: utenti e gruppi di Active Directory
Panoramica:
  • Funzionamento della replica e del collegamento di oggetti
  • Utilizzo di NTDSUTIL per i processi di backup e ripristino
  • Ripristino autorevole e ripristino non autorevole

Active Directory rappresenta uno dei servizi più importanti in una rete di Windows. Per evitare tempi di inattività e perdita di produttività, è essenziale sviluppare piani di ripristino di emergenza efficaci in caso di problemi correlati ad Active Directory. Sebbene questa considerazione possa sembrare ovvia, è tuttavia
sorprendente scoprire quanti amministratori non dispongano di un piano di ripristino per uno dei più comuni scenari di errore di Active Directory®, ovvero l'eliminazione accidentale dei dati.
L'eliminazione accidentale di oggetti è una delle cause principali più comuni degli errori di servizi. Nel corso di seminari e conferenze mi rivolgo spesso alla platea per chiedere se qualcuno si sia mai trovato nella necessità di gestire un errore di Active Directory dovuto all'eliminazione accidentale di dati. E ogni volta accade che quasi tutti alzino la mano.
Per comprendere la ragione della complessità del processo di ripristino dei dati, è necessario innanzitutto acquisire familiarità con le tematiche seguenti: modalità di archiviazione, replica ed eliminazione di oggetti in Active Directory e funzionamento dei processi di ripristino autorevole e non autorevole.

Archiviazione di oggetti
Active Directory è un database di oggetti specializzato che consente di implementare il modello di dati X.500/LDAP. L'archivio dati, denominato Directory Information Tree o DIT, è basato su ESE (Extensible Storage Engine), un motore di database basato su ISAM (Indexed Sequential Access Method). Dal punto di vista concettuale, Active Directory archivia il DIT in due tabelle: la tabella dei dati (che contiene gli oggetti e gli attributi effettivi di Active Directory) e la tabella dei collegamenti (che contiene le relazioni tra gli oggetti).
Ogni oggetto di Active Directory viene archiviato in una riga separata della tabella dei dati, con una colonna per ogni attributo. La tabella dei dati contiene tutte le voci relative a tutte le repliche archiviate nel controller di dominio. In un normale controller di dominio, la tabella dei dati contiene voci del contesto dei nomi (NC, Naming Context) dei domini, del contesto dei nomi della configurazione e del contesto dei nomi degli schemi. In un catalogo globale, la tabella dei dati contiene le voci relative a ciascun oggetto della foresta.
Active Directory prevede l'utilizzo del DNT (Distinguished Name Tag), un valore integer a 32 bit, per identificare in modo univoco ciascuna riga all'interno della tabella dei dati. Il DNT, utilizzato per fare riferimento agli oggetti internamente, è molto più piccolo di altri identificatori, come il nome distinto (DN, Distinguished Name) e l'objectGUID (una struttura binaria a 16 bit). Tuttavia, a differenza dell'objectGUID, il DNT è un identificatore locale ed è diverso in ciascun controller di dominio.

Collegamento di oggetti in Active Directory
Active Directory gestisce due tipi di relazioni tra gli oggetti nel DIT: la relazione padre-figlio (definita anche relazione di contenitore) e la relazione di tipo Riferimento (definita anche relazione di collegamento). Per implementare la relazione padre-figlio, Active Directory archivia una colonna aggiuntiva nella tabella dei dati denominata PDNT (Parent Distinguished Name Tag). Questa colonna contiene sempre il DNT del padre dell'oggetto.
Ogni attributo in Active Directory viene definito da un oggetto attributeSchema nel contenitore degli schemi di Active Directory. Alcuni attributi in Active Directory vengono definiti come attributi di collegamento, come determinato da un valore pari diverso da zero nell'attributo linkID dell'oggetto attributeSchema. Gli attributi di collegamento stabiliscono una relazione tra gli oggetti nella directory e possono essere a valore singolo o multivalore. L'attributo member di un oggetto gruppo è un esempio di attributo di collegamento multivalore, in quanto stabilisce un collegamento tra l'oggetto gruppo e i relativi oggetti membro.
Sebbene sembri che l'attributo member di un gruppo contenga i nomi distinti dei membri (come visualizzato ad esempio nello snap-in Utenti e computer di Active Directory) in Active Directory gli oggetti non vengono archiviati in questo modo. Quando si aggiunge il nome distinto di un oggetto membro a un attributo member di un gruppo, in Active Directory viene archiviato il DNT, non il nome distinto, dell'oggetto. Poiché il DNT non viene modificato, anche quando un oggetto viene rinominato, se si rinomina un oggetto utente, Active Directory non dovrà riorganizzare tutti i gruppi all'interno del sistema per aggiornare il nome distinto in ciascuno degli attributi member. Questo consente quindi ad Active Directory di mantenere l'integrità referenziale all'interno del DIT. Nella Figura 1 viene illustrata una rappresentazione, notevolmente semplificata, delle relazioni tra la tabella dei dati e la tabella dei collegamenti. In queste tabelle viene indicato che i tre oggetti utente, Molly Clark, Alexander Tumanov e Makoto Yamagishi, sono tutti membri del gruppo Senior Engineers.
Figure 1 Relazione tra le tabelle dei dati e le tabelle dei collegamenti (Close Figure 1)

Tabella dei dati |  |  |
DNT | PDNT | Classe dell'oggetto | Cn
14529 | 14401 | organizationalUnit | Engineers
14530 | 14529 | Gruppo | Senior Engineers
14531 | 14529 | Utente | Molly Clark
14532 | 14529 | Utente | Alexander Tumanov
14533 | 14529 | Utente | Makoto Yamagishi
Tabella dei collegamenti |  |  |
Attributo | DNT | Collegamento in avanti |
Member | 14530 | 14531 |
Member | 14530 | 14532 |
Member | 14530 | 14533 |
Questi collegamenti sono definiti collegamenti in avanti. Analogamente, Active Directory fornisce anche attributi di collegamento a ritroso. Questi attributi forniscono un riferimento dall'oggetto collegato all'oggetto che vi fa riferimento, ovvero l'oggetto con il collegamento in avanti. L'attributo memberOf per utenti e gruppi è un esempio di attributo di collegamento a ritroso. L'oggetto attributeSchema che descrive un attributo di collegamento a ritroso dispone di un valore linkID maggiore di uno rispetto al valore linkID pari dell'attributo di collegamento in avanti corrispondente. L'attributo member nello schema di Windows Server® 2003 R2 dispone ad esempio di un valore linkID pari a 2; l'attributo memberOf che funge da collegamento a ritroso dispone di un valore linkID pari a 3. Per ulteriori informazioni, nella Figura 2 viene fornito un elenco degli attributi collegati definiti per impostazione predefinita nello schema di Windows Server 2003 R2.
Figure 2 Attributi di collegamento nello schema di Windows Server 2003 R2 (Close Figure 2)

Attributo di collegamento in avanti | linkID | Attributo di collegamento a ritroso | Linked
member | 2 | memberOf | 3
manager | 42 | directReports | 43
owner | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOMPartitionSetLink | 1041
msDSNCReplicaLocations | 1044 |  |
msFRSHubMember | 1046 |  |
msCOMUserPartitionSetLink | 1048 | msCOMUserLink | 1049
msDSSDReferenceDomain | 2000 |  |
msDSHasInstantiatedNCs | 2002 |  |
msDSNonMembers | 2014 | msDSNonMembersBL | 2015
msDSMembersForAzRole | 2016 | msDSMembersForAzRoleBL | 2017
msDSOperationsForAzTask | 2018 | msDSOperationsForAzTaskBL | 2019
msDSTasksForAzTask | 2020 | msDSTasksForAzTaskBL | 2021
msDSOperationsForAzRole | 2022 | msDSOperationsForAzRoleBL | 2023
msDSTasksForAzRole | 2024 | msDSTasksForAzRoleBL | 2025
msDSHasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDShasMasterNCs | 2036 | msDsmasteredBy | 2037
msDSObjectReference | 2038 | msDSObjectReferenceBL | 2039
msDFSRComputerReference | 2050 | msDFSRComputerReferenceBL | 2051
msDFSRMemberReference | 2052 | msDFSRMemberReferenceBL | 2053
Gli attributi di collegamento a ritroso sono sempre multivalore e vengono gestiti automaticamente da Active Directory. Non è possibile infatti modificare direttamente un attributo di collegamento a ritroso. Sebbene sembri che sia possibile modificare l'attributo memberOf di un utente o gruppo tramite lo snap-in MMC Utenti e computer di Active Directory, in realtà lo snap-in consente di modificare solo l'attributo member del gruppo corrispondente e l'attributo memberOf viene automaticamente aggiornato da Active Directory in background. Per questo motivo, non è necessario disporre di autorizzazioni sull'oggetto utente per aggiungere l'utente a un gruppo, in quanto, in realtà, viene modificato solo l'attributo member dell'oggetto gruppo. Poiché ogni controller di dominio gestisce i relativi attributi di collegamento a ritroso in modalità locale, le modifiche ai collegamenti a ritroso non vengono mai replicate. Viene replicata solo la modifica all'attributo di collegamento in avanti, come l'attributo member di un gruppo.
In un normale controller di dominio, la tabella dei dati contiene voci relative agli oggetti dei domini e agli oggetti dei contenitori della configurazione e degli schemi. Alcuni tipi di gruppi possono tuttavia contenere riferimenti a oggetti che risiedono in un altro dominio. In che modo Active Directory archivia un DNT per un oggetto non contenuto nella relativa tabella dei dati? La risposta sta nel ruolo del proprietario FSMO (Flexible Single Master Operations) del master infrastrutture e nei cosiddetti oggetti non visibili (phantom).

Oggetti non visibili (phantom)
Quando si aggiunge un membro di un dominio a un gruppo di un altro dominio, Active Directory crea automaticamente nella tabella dei dati un oggetto speciale definito oggetto non visibile (phantom), che contiene l'objectGUID, l'objectSid e il nome distinto del nuovo membro. Questo oggetto fornisce un DNT che può essere archiviato nell'attributo member del gruppo. Se un controller di dominio è un catalogo globale, non è necessario che crei un oggetto non visibile (phantom) in quanto nella relativa tabella dei dati è già presente una voce per ciascun oggetto della foresta.
Il controller di dominio che contiene il ruolo FSMO del master infrastrutture controlla periodicamente le voci nella relativa tabella dei dati in base a un catalogo globale e, quando rileva che un oggetto è stato spostato, rinominato o aggiornato, aggiorna gli oggetti non visibili (phantom) nella tabella dei dati e replica le modifiche apportate negli altri controller di dominio all'interno del dominio. Grazie al conteggio dei riferimenti, il master infrastrutture è inoltre in grado di rimuovere gli oggetti non visibili (phantom) a cui nessun attributo di collegamento in avanti all'interno del dominio fa più riferimento.
Gli oggetti non visibili (phantom) consentono ai controller di dominio di gestire riferimenti a oggetti in altri domini all'interno della foresta, ma gli attributi di collegamento in avanti possono anche fare riferimento a oggetti all'esterno della foresta, ad esempio oggetti di un dominio trusted. In questo caso, Active Directory crea un oggetto denominato entità di protezione esterna (FSP, Foreign Security Principal) nel contenitore CN=ForeignSecurityPrincipals del contesto dei nomi del dominio. FSP contiene l'ID di protezione (SID, Security Identifier) dell'oggetto esterno e altri attributi che identificano l'oggetto nel dominio esterno, ma non esiste alcun processo in grado di garantire che l'oggetto FSP venga mantenuto aggiornato. Ai fini del ripristino dei dati, gli oggetti FSP verranno considerati alla stessa stregua di qualsiasi altro oggetto di Active Directory.

Eliminazione di oggetti
In questa sezione l'attenzione verrà focalizzata principalmente sul ripristino degli utenti e delle relative appartenenze ai gruppi. Gli stessi principi sono tuttavia applicabili al ripristino di altri attributi collegati.
Quando Active Directory elimina un oggetto, quest'ultimo non viene eliminato fisicamente dal DIT. L'oggetto viene invece contrassegnato come eliminato mediante l'impostazione del relativo attributo isDeleted su true, il che rende l'oggetto invisibile alle normali operazioni di directory. Active Directory rimuove tutti gli attributi non progettati per essere salvati, come definito dallo schema, e modifica il nome distinto relativo (RDN, Relative Distinguished Name) dell'oggetto in <RDN precedente>\0aDEL:<objectGUID>. Sposta quindi l'oggetto nel contenitore CN=Deleted Objects per il contesto dei nomi. Nel contesto dei nomi della configurazione sono presenti alcune classi di oggetti che Active Directory non sposta nel contenitore degli oggetti eliminati. Active Directory rimuove tutti i collegamenti in avanti agli altri oggetti contenuti nell'oggetto eliminato, con conseguente riduzione del relativo conteggio dei riferimenti nella tabella dei collegamenti. Se sono presenti altri oggetti che contengono collegamenti in avanti all'oggetto eliminato, Active Directory rimuoverà anche tali collegamenti.
L'oggetto risultante viene definito oggetto contrassegnato per rimozione. Active Directory replica l'oggetto contrassegnato per rimozione in altri controller di dominio, in cui vengono apportate le stesse modifiche. Tenere presente che Active Directory non replica le modifiche apportate ai collegamenti in avanti che fanno riferimento all'oggetto eliminato. Ogni controller di dominio apporta la modifica equivalente in modalità locale e pertanto non è necessario replicarla. Questo comportamento ha conseguenze sul ripristino delle appartenenze ai gruppi, come verrà illustrato più avanti in questo articolo.
Active Directory mantiene gli oggetti contrassegnati per rimozione nel DIT, come determinato dall'attributo tombstoneLifetime dell'oggetto CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain>. Il processo di garbage collection in ciascun controller di dominio rimuove gli oggetti contrassegnati per rimozione antecedenti rispetto alla durata oggetto contrassegnato per rimozione configurata. Per impostazione predefinita, la durata oggetto contrassegnato per rimozione è di 60 giorni per Windows® 2000, Windows Server 2003 e Windows Server 2003 R2. È invece di 180 giorni per Windows Server 2003 SP1.
La durata oggetto contrassegnato per rimozione ha un impatto significativo sul processo di ripristino. Non è possibile eseguire il ripristino di un backup anteriore alla durata oggetto contrassegnato per rimozione. Poiché agli oggetti che sono stati eliminati e successivamente sottoposti al processo di garbage collection nel dominio non sono più associati oggetti contrassegnati per rimozione, l'operazione di eliminazione non verrà mai replicata nuovamente nel controller di dominio ripristinato. Gli oggetti eliminati rimarranno nel controller di dominio ripristinato come oggetti residui e il controller di dominio ripristinato non eseguirà mai la convergenza con gli altri controller di dominio all'interno del dominio.

Replica di oggetti
Quando un controller di dominio esegue un'operazione di aggiornamento di qualsiasi tipo, ad esempio l'aggiunta di un oggetto o la modifica di un attributo, il controller di dominio assegna un numero univoco a 64 bit all'operazione di aggiornamento, definito numero di sequenza di aggiornamento (USN, Update Sequence Number). Active Directory contrassegna gli oggetti e gli attributi aggiornati con il numero di sequenza di aggiornamento per determinare se è necessario replicarli.
Gli oggetti in Active Directory vengono replicati in base ai singoli attributi. Se, ad esempio, si modifica un attributo di un oggetto, Active Directory replicherà solo tale attributo, non l'intero oggetto. Per eseguire questa operazione, Active Directory tiene traccia delle modifiche apportate a ciascun attributo con i metadati della replica. I metadati della replica per un attributo includono:
  • Il numero di sequenza di aggiornamento locale, che identifica l'operazione di modifica nel controller di dominio locale.
  • L'attributo invocationID del controller di dominio da cui ha origine la modifica (più specificamente l'attributo invocationID dell'oggetto nTDSSettings corrispondente del controller di dominio), che identifica una specifica generazione del DIT in un controller di dominio.
  • Il numero di sequenza di aggiornamento dell'operazione originale esistente nel controller di dominio di origine.
  • Un timestamp che contiene l'ora di sistema del controller di dominio in cui è stata apportata la modifica di origine.
  • Un numero di versione sequenziale a 32 bit che viene incrementato ogni volta che il valore viene modificato.
Quando un controller di dominio di destinazione richiede modifiche al partner del dominio di origine corrispondente, invia il numero di sequenza di aggiornamento dell'ultima modifica replicata al controller di origine insieme a un vettore di aggiornamento che include il numero di sequenza di aggiornamento di origine più elevato che il controller di dominio di destinazione ha rilevato in ciascun controller di dominio in cui è in corso la replica di una replica del contesto dei nomi. Il controller di dominio di origine utilizza queste informazioni per inviare solo gli aggiornamenti che il controller di dominio di destinazione non ha ancora rilevato.
Mentre elabora gli aggiornamenti degli attributi in ingresso, il controller di dominio di destinazione controlla il numero di versione di ciascun attributo. Se il numero di versione di un attributo in ingresso è maggiore della versione già esistente nel controller di dominio per tale attributo, verrà memorizzato il valore in ingresso. Se il numero di versione in ingresso è uguale alla versione già esistente nel controller di dominio, quest'ultimo confronta i timestamp e utilizza l'attributo con il timestamp più recente. Se i timestamp sono identici, il controller di dominio di destinazione sceglie il valore con l'attributo invocationID più elevato. Questo garantisce che ogni controller di dominio scelga lo stesso valore per ogni attributo replicato.

Replica del valore collegato
In Windows 2000, la replica degli attributi multivalore in Active Directory veniva eseguita allo stesso modo della replica degli attributi a valore singolo. Questo causava problemi per gli oggetti gruppo dinamici di grandi dimensioni il cui attributo member multivalore poteva essere modificato di frequente in controller di dominio differenti. Se un amministratore aggiungeva un utente a un gruppo in un controller di dominio e un altro amministratore aggiungeva un utente differente al gruppo in un altro controller di dominio all'interno dell'intervallo di latenza di replica, Active Directory sceglieva l'aggiunta più recente che sostituiva completamente quella precedente. Microsoft ha ovviato a questo problema in Windows Server 2003 con un processo definito replica del valore collegato (LVR, Linked Value Replication).
Utilizzando il livello di funzionalità della foresta di Windows Server 2003 o Windows Server 2003 interim, Active Directory replica i singoli valori degli attributi di collegamento in avanti multivalore separatamente, in cui ciascun valore dispone di propri metadati di replica. Questo consente di risolvere in modo efficace il problema riscontrato in Windows 2000 dove aggiornamenti quasi simultanei dell'appartenenza ai gruppi in controller di dominio differenti poteva causare una perdita di dati.
È necessario tuttavia prendere in considerazione un importante fattore. L'aumento del livello di funzionalità della foresta non determina la correzione automatica degli attributi di collegamento multivalore esistenti con i nuovi metadati della replica. Solo i valori che vengono aggiunti dopo l'aumento del livello di funzionalità della foresta includeranno i nuovi metadati. Questo avrà un effetto significativo sul ripristino delle appartenenze ai gruppi, come verrà illustrato più avanti.

Backup
Windows include l'utilità di base NTBACKUP, che può essere utilizzata per eseguire il backup dello stato di sistema di un controller di dominio. Lo stato di sistema di un controller di dominio include il relativo Registro di sistema, SYSVOL, i file DIT di Active Directory e i file di sistema critici. Anche la maggior parte delle utilità di backup di terze parti è in grado di eseguire il backup e il ripristino dello stato di sistema di un controller di dominio.
Per eseguire il backup dello stato di sistema di un file su disco, utilizzare il comando seguente:
NTBACKUP backup systemstate /F “<filename>”
In questo comando <nomefile> rappresenta il nome del file di backup da creare e deve utilizzare l'estensione .bkf.

Esecuzione di un ripristino non autorevole
Il ripristino degli oggetti di Active Directory eliminati dal backup è un processo a due fasi. È necessario innanzitutto riavviare il controller di dominio in modalità ripristino servizi directory (DSRM, Directory Services Restore mode) e successivamente ripristinare l'intero database DIT di Active Directory dal backup dello stato di sistema utilizzando l'utilità NTBACKUP di Windows o un prodotto di terze parti equivalente. Questo processo sovrascriverà l'intero DIT.
Esistono due metodi per avviare un controller di dominio in modalità ripristino servizi directory. Se si accede alla console di sistema del controller di dominio, arrestare e riavviare il controller di dominio, quindi premere F8 quando viene chiesto di aprire il menu di avvio di Windows. Selezionare Modalità ripristino servizi directory dal menu e immettere la password per la modalità ripristino servizi directory.
Se si gestisce il server in modalità remota, non si sarà in grado di accedere al menu di avvio di Windows. È possibile modificare le opzioni di avvio di sistema selezionando Proprietà da Risorse del computer, facendo clic sulla scheda Avanzate e selezionando il pulsante Impostazioni in Avvio e ripristino. Scegliere il pulsante Modifica nella sezione Avvio del sistema per modificare il file boot.ini, quindi aggiungere l'opzione /SAFEBOOT:DSREPAIR alla fine della riga, come illustrato nella Figura 3. Per ulteriori informazioni sulle opzioni per boot.ini, visitare il sito Web all'indirizzo microsoft.com/technet/ sysinternals/information/bootini.mspx.
Figura 3 Impostazione delle opzioni di avvio per la modalità ripristino servizi directory
Figura 3 Impostazione delle opzioni di avvio per la modalità ripristino servizi directory (Fare clic sull'immagine per ridurla)
Figura 3 Impostazione delle opzioni di avvio per la modalità ripristino servizi directory
Figura 3 Impostazione delle opzioni di avvio per la modalità ripristino servizi directory (Fare clic sull'immagine per ingrandirla)
Quando si riavvia il server, viene attivata la modalità ripristino servizi directory. Ricordare che è necessario rimuovere l'opzione /SAFEBOOT dal file boot.ini quando si desidera riavviare il controller di dominio in modalità normale.
Una volta eseguito l'accesso con la password per la modalità ripristino servizi directory, ripristinare il backup dello stato di sistema utilizzando di nuovo il comando NTBACKUP ma senza specificare alcun parametro. Non è possibile eseguire un ripristino utilizzando NTBACKUP dalla riga di comando. Quando viene visualizzata la procedura guidata, selezionare Ripristino dei file e delle impostazioni, quindi scegliere Avanti. Selezionare quindi il file di backup e la casella Stato del sistema, come illustrato nella Figura 4.
Figura 4 Utilizzo di Backup o ripristino guidato per ripristinare lo stato del sistema
Figura 4 Utilizzo di Backup o ripristino guidato per ripristinare lo stato del sistema (Fare clic sull'immagine per ridurla)
Figura 4 Utilizzo di Backup o ripristino guidato per ripristinare lo stato del sistema
Figura 4 Utilizzo di Backup o ripristino guidato per ripristinare lo stato del sistema (Fare clic sull'immagine per ingrandirla)
Se, a questo punto, si decidesse di avviare il controller di dominio di nuovo in modalità normale, il processo di replica di Active Directory ripristinerebbe la sincronizzazione tra il controller di dominio ripristinato e gli altri controller di dominio all'interno del dominio e tutti i dati ripristinati verrebbero sovrascritti dai dati correnti. Ovviamente, questo non è l'obiettivo che si intende raggiungere. È necessario invece un metodo che consenta di forzare la replica degli oggetti ripristinati negli altri controller di dominio all'interno del dominio.

Esecuzione di un ripristino autorevole
NTDSUTIL consente di aumentare il numero di versione di ciascun attributo di 100.000 volte per ciascun giorno trascorso tra la data del backup e la data del ripristino. A meno che non vi siano attributi che vengano aggiornati più di 100.000 volte al giorno (uno scenario piuttosto inverosimile), il numero di versione degli attributi ripristinati sarà di gran lunga maggiore rispetto ai numeri di versione contenuti in altri controller di dominio e l'oggetto ripristinato autorevolmente verrà replicato negli altri controller di dominio. Gli altri oggetti ripristinati in modo non autorevole dal backup verranno sovrascritti dai dati esistenti negli altri controller di dominio.
Dopo aver completato il ripristino non autorevole ma prima di eseguire il riavvio in modalità normale, utilizzare il programma NTDSUTIL per eseguire un ripristino autorevole degli oggetti che si desidera ripristinare. Il ripristino autorevole di un oggetto non consente di ripristinare effettivamente l'oggetto, ma assicura semplicemente che Active Directory replichi l'oggetto negli altri controller di dominio. A tal fine, NTDSUTIL assegna il successivo numero di sequenza di aggiornamento disponibile al numero di sequenza di aggiornamento locale degli attributi dell'oggetto. Questo determina l'invio dell'oggetto ai partner di replica la volta successiva che vengono sincronizzati. Per ripristinare un singolo oggetto, verificare che il controller di dominio venga avviato in modalità ripristino servizio directory, quindi attenersi alla procedura seguente:
  1. Aprire una finestra di comando e digitare:
    ntdsutil
  2. Al prompt di ntdsutil digitare:
    authoritative restore
  3. Al prompt di ripristino autorevole digitare:
    restore object “<DN of object to be restored>”
    Se, ad esempio, si desidera ripristinare l'account Molly Clark dall'unità organizzativa Eng nel dominio DRNET, immettere:
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    Se si desidera eseguire un ripristino autorevole di un'intera sottostruttura di directory, ad esempio un'unità organizzativa, immettere:
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    NTDSUTIL fornisce inoltre un comando di ripristino del database che consente di eseguire il ripristino autorevole dell'intero dominio e dei contesti dei nomi della configurazione e degli schemi. Il ripristino dell'intero dominio espone a notevoli pericoli e pertanto è consigliabile non utilizzare questa opzione. Se si desidera ripristinare un intero domino, è consigliabile ripristinare un controller di dominio e innalzare nuovamente di livello gli altri controller di dominio all'interno del dominio, come descritto in "Pianificazione del ripristino della foresta di Active Directory".
  4. Quando richiesto, confermare che il ripristino autorevole deve aumentare i numeri di versione dei rispettivi oggetti e dei relativi attributi.
  5. Uscire da ntdsutil (è necessario digitare quit due volte).
  6. Riavviare il controller di dominio nella modalità normale di Active Directory.
La volta successiva che il controller di dominio esegue la replica con i relativi partner, l'utente ripristinato verrà replicato. Tuttavia, il ripristino dell'oggetto utente rappresenta solo una parte del problema. Quando si inseriscono collegamenti di oggetti come quelli tra un gruppo e i relativi membri, la situazione diventa più complessa. Durante e dopo il processo di ripristino è possibile che ci si trovi a dover affrontare due problemi fondamentali, che verranno descritti nelle sezioni successive.
Ma prima occorre esaminare le possibile conseguenze dell'eliminazione di un oggetto con collegamenti a ritroso. Si supponga di eliminare un oggetto utente membro di uno o più gruppi. Ogni controller di dominio che dispone di una copia dell'oggetto utente lo convertirà in un oggetto contrassegnato per rimozione e rimuoverà eventuali riferimenti dalla tabella dei collegamenti, determinando pertanto la rimozione dell'oggetto utente da qualsiasi appartenenza ai gruppi nel dominio dell'utente. Tenere presente che la rimozione dell'utente dall'appartenenza ai gruppi non è una modifica replicata in quanto ogni controller di dominio aggiorna l'appartenenza al gruppo in modalità locale. Il numero di versione il numero di sequenza di aggiornamento locale dell'attributo member del gruppo restano invariati. Dopo un breve periodo di tempo, gli oggetti non visibili (phantom) verranno rimossi dalle tabelle dei collegamenti in altri domini senza aggiornare i metadati della replica dell'attributo member del gruppo.
Quando si esegue un ripristino non autorevole del DIT in un controller di dominio all'interno del dominio dell'utente, l'oggetto utente viene ripristinato insieme a tutte le appartenenze ai gruppi all'interno del dominio, il che garantisce pertanto la coerenza interna del controller di dominio ripristinato. Dopo aver utilizzato l'utilità NTDSUTIL per eseguire il ripristino autorevole dell'utente, l'oggetto utente viene replicato in tutti gli altri controller di dominio all'interno del dominio.
Tuttavia, poiché i metadati della replica dei gruppi correnti nel dominio restano invariati, gli attributi member dei gruppi nel controller di dominio ripristinato non sono coerenti con quelli degli altri controller di dominio. Non essendo inoltre disponibile alcun metodo per eseguire la convergenza tra i controller di dominio in uno stato comune, le appartenenze dell'utente non verranno ripristinate negli altri controller di dominio all'interno del dominio.

Problema: impossibile ripristinare le appartenenze ai gruppi all'interno del dominio
Il ripristino autorevole dell'oggetto utente non consente di ripristinare i gruppi a cui l'utente appartiene. Perché? Perché la relazione di appartenenza viene archiviata e replicata mediante l'attributo member degli oggetti gruppo (collegamenti in avanti), non l'attributo memberOf dell'utente (collegamento a ritroso). Il problema sta nell'individuare le appartenenze ai gruppi precedenti dell'utente e nell'identificare il metodo appropriato per ripristinarle.
Microsoft ha apportato miglioramenti incrementali al processo di ripristino delle appartenenze ai gruppi di un utente. Pertanto, la tecnica utilizzata dipende dalla versione di Active Directory in esecuzione. La sezione riportata di seguito è applicabile principalmente ad Active Directory di Windows 2000.
La determinazione delle appartenenze ai gruppi precedenti di un utente è piuttosto semplice: occorre semplicemente esaminare l'attributo di collegamento a ritroso nel controller di dominio ripristinato, in questo caso l'attributo memberOf dell'oggetto utente. L'attributo memberOf contiene tutte le appartenenze ai gruppi locali e globali all'interno del dominio dell'utente. Per elencare le appartenenze ai gruppi dell'utente ripristinato, è possibile utilizzare lo snap-in MMC Utenti e computer di Active Directory (ADUC) o l'utilità LDIFDE, inclusa in Windows Server.
Nella riga di comando di LDIFDE seguente vengono elencati i gruppi del dominio DRNET di cui Molly Clark è membro, archiviando i risultati nel file output.ldf:
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
Tenere presente che è necessario avviare il controller di dominio in modalità normale per utilizzare gli strumenti LDAP e occorre disattivare la replica in ingresso; in caso contrario i dati ripristinati verranno sovrascritti. Il metodo più semplice per disattivare la replica in ingresso consiste nell'utilizzo del comando REPADMIN:
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
In questo comando <nomedc> rappresenta il nome del controller di dominio in cui si sta eseguendo il ripristino. Al termine, ricordare inoltre di riattivare la replica utilizzando DISABLE_INBOUND_REPL.
Il ripristino di un numero limitato di utenti può essere eseguito con un'attività piuttosto semplice: è sufficiente aggiungere di nuovo l'utente ai gruppi manualmente mediante ADUC. Se si intende ripristinare un numero elevato di utenti, sono disponibili alcuni strumenti in grado di automatizzare parte del processo. L'utilità Microsoft GROUPADD (disponibile nel Servizio Supporto Tecnico Clienti Microsoft) può accettare il file LDIF creato per elencare le appartenenze ai gruppi precedenti dell'utente e, a sua volta, genera un file LDIF che crea nuovamente tali appartenenze. Il comando GROUPADD può essere utilizzato ad esempio per elaborare il file LDIF creato nell'esempio precedente per Molly Clark:
C:\> groupadd /after_restore output.ldf
Questo comando consente di creare un nuovo file LDIF per ciascun dominio che contiene le appartenenze ai gruppi precedenti di Molly Clark con il nome groupadd_<dominio>.ldf (dove <dominio> rappresenta il nome di dominio completo del dominio di cui verranno aggiornati i gruppi). Il file LDIF creato in precedenza può essere importato con il comando seguente:
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
Con Windows Server 2003, Microsoft ha migliorato l'utilità NTDSUTIL in modo da utilizzare i metadati aggiuntivi presenti nell'attributo member per supportare la replica del valore collegato. Se l'oggetto utente ripristinato fosse stato membro di un gruppo qualsiasi all'interno del dominio e l'appartenenza al gruppo dell'utente fosse stata archiviata con i metadati della replica del valore collegato, l'utilità NTDSUTIL avrebbe aumentato il numero di versione del valore corrispondente dell'attributo member, determinando la replica dell'appartenenza ripristinata.
La versione Windows Server 2003 SP1 di NTDSUTIL incorpora le funzioni GROUPADD e prevede la creazione automatica dei file LDIF durante il ripristino autorevole dell'oggetto utente. Nella Figura 5 viene illustrata la nuova versione di NTDSUTIL, mentre nella Figura 6 viene mostrato il contenuto del file LDIF creato automaticamente.
Figure 6 Contenuto del file LDIF creato tramite NTDSUTIL (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
Figura 5 Nuova utilità NTDSUTIL con funzionalità GROUPADD incorporate
Figura 5 Nuova utilità NTDSUTIL con funzionalità GROUPADD incorporate (Fare clic sull'immagine per ridurla)
Figura 5 Nuova utilità NTDSUTIL con funzionalità GROUPADD incorporate
Figura 5 Nuova utilità NTDSUTIL con funzionalità GROUPADD incorporate (Fare clic sull'immagine per ingrandirla)
Se si sta ripristinando un'intera unità organizzativa che contiene numerosi utenti e gruppi, aggiungere di nuovo gli utenti ai relativi gruppi manualmente è un'attività piuttosto noiosa. Un altro metodo per ripristinare le appartenenze ai gruppi ripristinate prevede l'esecuzione del ripristino autorevole dei gruppi stessi.
Il ripristino autorevole dei gruppi comporta tuttavia due problemi principali. Il primo è abbastanza ovvio: se si ripristina un gruppo, l'appartenenza a tale gruppo verrà riportata allo stato in cui si trovava quando è stato effettuato il backup. Ne consegue che tutte le modifiche apportate al gruppo dall'ultimo backup dovranno essere riapplicate al gruppo. Il secondo problema non risulta immediatamente evidente e riguarda il funzionamento del processo di replica di Active Directory. Dopo un ripristino autorevole di utenti e gruppi non è possibile sapere in alcun modo in quale ordine questi verranno replicati. Se un oggetto gruppo viene replicato in controller di dominio prima dell'oggetto utente ripristinato, il controller di dominio di replica rimuoverà automaticamente il riferimento all'utente dal gruppo in quanto l'oggetto utente non esiste ancora in tale controller di dominio. Quando l'oggetto utente viene replicato in seguito, non viene aggiunto al gruppo.
La soluzione più semplice a questo problema consiste nell'eseguire il ripristino autorevole dei gruppi una seconda volta. Dopo aver eseguito il primo ripristino autorevole, eseguire il riavvio in modalità normale e accertarsi che la replica venga eseguita in modo corretto. Eseguire quindi il riavvio in modalità ripristino servizio directory ed eseguire l'utilità NTDSUTIL per effettuare un ripristino autorevole dei gruppi di cui l'utente era membro. Questo garantisce che, quando si esegue il riavvio di nuovo in modalità normale, l'oggetto utente venga replicato prima che venga eseguita la replica degli oggetti gruppo che vi fanno riferimento.

Problema: impossibile ripristinare le appartenenze ai gruppi in altri domini
L'identificazione dei gruppi di cui l'utente era membro è un processo molto più complesso di quanto sia stato descritto in questa sede. L'utente che si sta ripristinando potrebbe essere stato membro dei gruppi universali e locali di dominio in altri domini e le appartenenze a tali gruppi non vengono ripristinate quando si esegue un ripristino non autorevole. Come è possibile pertanto identificare i gruppi a cui l'utente apparteneva in altri domini? La risposta risiede nel catalogo globale. Oltre ai dati del rispettivo dominio, il catalogo globale contiene una copia di sola lettura dei dati degli altri domini della foresta.
Per utilizzare i dati a livello dell'intera foresta di un catalogo globale è necessario eseguire il ripristino non autorevole sul catalogo globale. A tal fine, occorre innanzitutto eseguire il backup del catalogo globale. Quando si esegue l'utilità LDIFDE per identificare le appartenenze ai gruppi dell'utente, è possibile individuare le appartenenze ai gruppi universali dell'utente in altri domini.
Quando si elencano le appartenenze ai gruppi dell'utente che si sta ripristinando, connettersi alla porta del catalogo globale 3268 anziché alla porta predefinita 389 e specificare il dominio radice della foresta come base della ricerca. LDIFDE visualizzerà le appartenenze ai gruppi dell'utente ripristinato, inclusa l'appartenenza ai gruppi universali in tutti i domini della foresta. Di seguito viene illustrato come eseguire questa operazione:
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
Se si esegue GROUPADD o la nuova utilità NTDSUTIL in un catalogo globale, verrà creato un file LDIF per il dominio dell'utente e un file LDIF per ciascun dominio in cui l'utente ripristinato è stato membro di un gruppo universale. Durante l'importazione di questi file vengono ripristinate tutte le appartenenze ai gruppi dell'utente. Questo porta a esaminare il problema successivo.

Problema: ripristino delle appartenenze ai gruppi locali di dominio in altri domini
Esistono tre tipi di gruppi in un ambiente Active Directory di Windows. I gruppi globali possono contenere solo i membri all'interno dello stesso domini ma possono essere utilizzati come membri di gruppi locali di dominio sia nel rispettivo dominio che negli altri domini della foresta. L'attributo member dei gruppi globali non viene visualizzato nel catalogo globale, ma questo non rappresenta un problema in quanto i gruppi globali contengono solo i membri del rispettivo dominio. I gruppi universali possono contenere i membri di qualsiasi dominio e possono essere utilizzati come membri di altri gruppi universali all'interno della foresta e come membri dei gruppi locali di dominio sia all'interno del rispettivo dominio che in altri domini della foresta. L'attributo member dei gruppi universali viene replicato nei cataloghi globali. I gruppi locali di dominio possono contenere i membri di qualsiasi dominio della foresta ma non possono essere utilizzati come membri di gruppi di altri domini. Cosa ancora più importante, l'attributo member dei gruppi locali di dominio, come quello dei gruppi globali, non viene visualizzato nel catalogo globale. Ne consegue che non esiste un metodo semplice per ripristinare appartenenza dell'utente ai gruppi locali di dominio in altri domini.
Prima di Windows Server 2003 SP1, l'unico metodo per ripristinare le appartenenze ai gruppi locali di dominio in domini esterni prevedeva il ripristino di un controller di dominio in ciascun dominio, la ricerca manuale dei dati del dominio per tutti i gruppi locali di dominio che contenevano l'utente ripristinato e infine l'aggiunta dell'utente ai gruppi identificati. In un ambiente di grandi dimensioni con numerosi domini l'implementazione di questo approccio richiede molto tempo.
Da questo punto di vista, la versione Windows Server 2003 SP1 di NTDSUTIL può risultare particolarmente utile. Quando si esegue l'utilità NTDSUTIL in un controller di dominio, l'utilità crea un file di testo che contiene il nome distinto e il GUID degli oggetti utente ripristinati. Per ogni dominio esterno è possibile eseguire il ripristino non autorevole di un singolo controller di dominio, copiare il file di testo nel controller di dominio ed eseguire l'utilità NTDSUTIL per generare un nuovo file LDIF specifico del dominio che consente di aggiungere l'utente ripristinato di nuovo ai gruppi locali di dominio di cui era membro.
A tal fine, in un controller di dominio in ciascun dominio esterno effettuare le operazioni seguenti:
  1. Avviare il controller di dominio nel dominio esterno in modalità ripristino servizi directory.
  2. Utilizzare NTBACKUP per ripristinare una copia del DIT che contiene le appartenenze ai gruppi dell'utente ripristinato.
  3. Copiare il file .txt creato da NTDSUTIL nel controller di dominio corrente.
  4. Aprire una finestra di comando e digitare ntdsutil.
  5. Digitare authoritative restore.
  6. Digitare create LDIF file(s) from <nome file> (dove <nome file> rappresenta il nome del file di testo).
  7. Digitare quit due volte per uscire da ntdsutil.
  8. Riavviare il controller di dominio nella modalità normale di Active Directory.
  9. Digitare ldifde –i –f <nomefile ldif> (dove <nomefile ldif> rappresenta il nome del file LDIF appena creato).
A questo punto, sono state ripristinate tutte le appartenenze ai gruppi dell'utente eliminato.

Procedura dettagliata
Il ripristino degli utenti di Active Directory e delle relative appartenenze ai gruppi, in particolare in un ambiente con più domini, è un processo molto complesso. I passaggi specifici necessari per ripristinare in modo corretto le appartenenze ai gruppi variano in base alla versione di Windows in esecuzione.
Se si esegue Windows 2003 SP1, attenersi alla procedura seguente:
  1. Avviare un processo di garbage collection in modalità ripristino servizi directory ed eseguire u ripristino dello stato di sistema utilizzando un backup che contiene l'utente eliminato.
  2. Utilizzare l'utilità NTDSUTIL per eseguire un ripristino autorevole dell'utente eliminato. NTDSUTIL creerà un file di testo contenente i nomi distinti e i GUID degli oggetti ripristinati e uno o più file LDIF per ripristinare le appartenenze ai gruppi dell'utente.
  3. Utilizzare LDIFDE –i –f <nomefile LDIF> (dove <nomefile LDIF> rappresenta il nome dei file LDIF creati nel passaggio 2) per importare le appartenenze ai gruppi nel dominio corrente e in altri domini.
  4. Riavviare il catalogo globale in modalità normale.
  5. In un controller di dominio all'interno di ciascun dominio esterno eseguire l'avvio in modalità ripristino servizi directory ed eseguire un ripristino dello stato di sistema utilizzando un backup che contiene le appartenenze ai gruppi dell'utente ripristinato.
  6. Eseguire NTDSUTIL utilizzando il comando per la creazione dei file ldif.
  7. Riavviare il controller di dominio in modalità normale.
  8. Utilizzare LDIFDE –i –f <nomefile> (dove <nomefile> rappresenta il nome del file LDIF creato nel passaggio 6) per ripristinare le appartenenze ai gruppi nel dominio esterno.
  9. A questo punto è possibile, se si desidera, forzare la replica con REPADMIN /syncall.
Se si esegue una versione di Windows Server 2003 senza SP1 installato o si esegue Windows 2000, è necessario eseguire alcuni passaggi aggiuntivi. Poiché la versione precedente di NTDSUTIL non prevede la creazione dei file LDIF, utilizzare l'utilità GROUPADD per crearli. Il processo viene illustrato di seguito:
  1. Avviare un catalogo globale in modalità ripristino servizi directory ed eseguire un ripristino dello stato di sistema utilizzando un backup che contiene l'utente eliminato.
  2. Disattivare la scheda NIC o scollegare il cavo per impedire la replica in ingresso.
  3. Riavviare il catalogo globale in modalità normale.
  4. Utilizzare LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf per eseguire il dump dell'appartenenza dell'utente con il nome distinto <dn>.
  5. Utilizzare GROUPADD /after_restore membership.ldf per creare i file LDIF.
  6. Utilizzare LDIFDE –i –f <nomefile> (dove <nomefile LDIF> rappresenta il nome del file LDIF creato da GROUPADD nel passaggio 5) per importare le appartenenze ai gruppi nel dominio corrente e in altri domini.
  7. Riattivare la replica in ingresso utilizzando REPADMIN /options <nomedc> -DISABLE_INBOUND_REPL.
  8. In un controller di dominio in ciascun dominio esterno, eseguire l'avvio in modalità ripristino servizi directory ed eseguire un ripristino dello stato di sistema utilizzando un backup che contiene le appartenenze ai gruppi dell'utente ripristinato.
  9. Riavviare il controller di dominio in modalità normale.
  10. Utilizzare LDIFDE –i –f <nomefile> (dove <nomefile> rappresenta il nome del file LDIF creato da GROUPADD nel passaggio 5) per ripristinare le appartenenze ai gruppi nel dominio esterno.
  11. A questo punto, se si desidera, è possibile forzare la replica REPADMIN /syncall.
L'unica operazione da eseguire a questo punto in un ambiente precedente a Windows Server 2003 SP1 consiste nel ripristinare le appartenenze ai gruppi locali dei domini esterni dell'utente ripristinato. Sono disponibili solo due opzioni: ripristinare manualmente le appartenenze ai gruppi locali di dominio o ripristinare il backup di un controller di dominio ed eseguire un ripristino autorevole dei gruppi locali di dominio.

Riepilogo
Sebbene sia piuttosto semplice eliminare accidentalmente utenti o persino unità organizzative da Active Directory, il ripristino degli utenti eliminati e delle relative appartenenze ai gruppi può essere un processo molto complesso, lungo e tendente all'errore. Per poter essere in grado di eseguire un ripristino di emergenza in modo rapido ed efficace in situazioni di questo tipo, è necessario comprendere il funzionamento dei processi di collegamento di oggetti, replica, eliminazione e ripristino autorevole.
Sarebbe tuttavia assurdo pensare di ottenere risultati ottimali la prima volta che si implementa un piano di ripristino di emergenza nell'ambiente di produzione. Per assicurarsi di disporre della preparazione adeguata per gestire in modo efficace situazioni che richiedono il ripristino di oggetti eliminati, è consigliabile predisporre un piano scritto. Assicurarsi inoltre di è sicuro di testare il piano almeno una o due volte prima di implementarlo su dati reali. Questo comportamento sarà senza dubbio apprezzato dal proprio capo e dal CEO.
Ulteriori risorse
  • Come ripristinare account utente eliminati e relative appartenenze ai gruppi in Active Directory
  • Servizio Supporto Tecnico Clienti Microsoft
  • Guida dettagliata alla gestione di Active Directory

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


 Amministrazione di Windows: Perch&#233; Windows XP Embedded &#232; importante
Amministrazione di Windows Don Jones

Perché Windows XP Embedded è importante
Panoramica:
  • Contenuti di Windows XP Embedded
  • Opzioni hardware speciali
  • Personalizzazione di Windows XP Embedded

Windows XP Embedded è la versione strutturata in componenti di Windows che spesso viene associata ai dispositivi per l'elettronica di consumo, come i decoder o gli elettrodomestici. Ma Windows XP Embedded si adatta altrettanto bene anche nell'infrastruttura informatica di un'organizzazione. Sebbene potrebbe non essere la soluzione migliore
per tutti gli utenti, esistono tuttavia alcuni scenari specifici in cui consente di ridurre le spese generali di amministrazione, di utilizzare hardware più economici e più piccoli, nonché di aumentare la protezione.

Che cos'è Windows XP Embedded?
Windows® XP Embedded è una delle tre versioni a footprint ridotto di Windows, insieme a Windows Embedded CE e a Windows Embedded for Point of Service. Dei sistemi operativi Windows Embedded, soltanto Windows XP Embedded offre la piena funzionalità o almeno il potenziale per la piena funzionalità di un computer client Windows XP Professional. È basato su Windows XP Professional Service Pack 2 (SP2); tuttavia Windows XP Embedded è diverso da un normale Windows XP in relazione al livello estremo di modularità. Windows XP Embedded non dispone di quella che si potrebbe chiamare un'immagine di installazione standard. Viene utilizzato invece un toolkit denominato Windows Embedded Studio per creare un ambiente Windows XP Embedded personalizzato per qualsiasi periferica in fase di installazione e quell'ambiente contiene soltanto le funzionalità di cui la periferica necessita. Ad esempio, se DirectX® o Windows Explorer non sono necessari, semplicemente non vengono installati. Questa modularità significa che ogni immagine Windows XP Embedded creata e distribuita avrà meno componenti variabili, per così dire, e questo significa meno lavoro amministrativo e maggiore protezione, come pure la possibilità di essere eseguite su hardware più economici. Alcune delle opzioni disponibili possono essere viste in Target Designer (un componente di Windows Embedded Studio), come illustrato nella Figura 1.
Figura 1 Scegliere i componenti in Target Designer
Figura 1 Scegliere i componenti in Target Designer (Fare clic sull'immagine per ridurla)
Figura 1 Scegliere i componenti in Target Designer
Figura 1 Scegliere i componenti in Target Designer (Fare clic sull'immagine per ingrandirla)

Un posto in azienda
Un dispositivo basato su Windows XP Embedded è adatto per un numero crescente di scenari utente. Si considerino, ad esempio, le aziende che gestiscono grandi centri per il servizio clienti. In molti casi, i rappresentanti del servizio clienti necessitano soltanto di una o due applicazioni sviluppate internamente e, forse, di un browser Web. Utilizzano solo una parte delle funzionalità del proprio computer, pertanto Windows XP Embedded consente di ridurre il numero di tali funzionalità al minimo necessario. Meno funzionalità significa meno possibilità di errori o meno possibilità di attacchi alla protezione.
Poiché le periferiche Windows XP Embedded hanno funzionalità limitate, possono essere eseguite su hardware meno potenti e spesso meno costosi. Numerosi produttori producono schede madre che utilizzano i processori compatibili Intel a basso consumo. Queste schede madre sono estremamente piccole, consumano poco e spesso non usano neanche una ventola perché non si surriscaldano. Funzionano piuttosto bene per le periferiche integrate a footprint ridotto, in grado di eseguire soltanto un numero limitato di applicazioni.

I "Superpoteri" di Windows XP Embedded
Windows XP Embedded offre alcune opzioni molto interessanti che non sono disponibili nella versione completa di Windows XP. Le funzionalità Enhanced Write Filter (EWF) e Hibernate Once, Resume Many (HORM) possono entrambe semplificare le attività di amministrazione di Windows. EWF è un componente facoltativo che è possibile aggiungere alla distribuzione di Windows XP Embedded rendendo di sola lettura un determinato volume su disco. Qualunque attività di scrittura diretta al disco è deviata su un overlay, che può essere posizionato in un altro disco o anche in memoria. Il sistema operativo stesso controlla la zona di overlay EWF e il relativo volume padre come una sola unità, nel senso che li considera come un normale volume del disco. In realtà però il volume padre non viene modificato effettivamente; le modifiche vengono apportate solo all'overlay EWF. In alcuni casi questo può essere un vantaggio. Si supponga di distribuire un'immagine di Windows XP Embedded in una scheda Compact Flash (CF), (le immagini di Windows XP Embedded possono essere anche solo di 5 MB e spesso occupano circa 200 MB, quindi le schede CF hanno tutto lo spazio necessario e anche di più). La scheda CF può essere inserita in un adattatore e collegata a un connettore IDE della scheda madre, in modo che funga da normale disco rigido. Le schede CF attuali hanno capacità di scrittura limitate (100.000 cicli), pertanto si potrebbe utilizzare EWF affinché il volume CF sia di sola lettura. Si supponga di inserire la sovrapposizione EWF nella RAM: in caso di errori da parte dell'utente, è sufficiente spegnere il computer. La sovrapposizione EWF e tutte le modifiche effettuate al computer vengono perse immediatamente. Al riavvio, si ritorna al punto iniziale memorizzato nella scheda CF. Inoltre, è possibile utilizzare la stessa impostazione per un'immagine su CD o DVD; poiché questo tipo di supporti sono di per sé di sola lettura, EWF cattura tutte le attività di scrittura in un overlay. Anche se l'overlay viene memorizzato in un piccolo disco rigido interno, il volume di avvio originale (su CD o DVD) non viene mai modificato; se è necessario riavviare il computer nella configurazione originale, è sufficiente eliminare l'overlay EWF.
HORM, come lascia intuire il nome, consente di mettere in stato di ibernazione un computer per poi riprendere l'esecuzione dallo stesso punto diverse volte. Il computer si riattiva quasi immediatamente. È sufficiente configurare il computer ed eseguire tutte le applicazioni necessarie, poi sospenderle. Da quel momento in poi, ogni volta che si accende, il computer diventa operativo in pochi secondi.

Creazione di un'immagine di Windows XP Embedded
Microsoft dispone di un programma Embedded Partner cui partecipano le aziende specializzate nell'uso di Windows XP Embedded (elenchi di tali aziende sono disponibili nella home page di Windows XP Embedded all'indirizzo microsoft.com/embedded). Tuttavia, proprio come molte aziende forniscono ai loro produttori di computer immagini predefinite (che contengono applicazioni aziendali e configurazioni specifiche), è possibile che si desideri creare immagini Windows XP Embedded proprie da condividere con un Embedded Partner che fornisce i sistemi a footprint ridotto e completi. È possibile utilizzare Windows Embedded Studio, che si installa in Windows XP Professional, per creare e gestire le immagini di Windows XP Embedded.
Per utilizzare il toolkit, occorre dapprima installare la versione completa di Windows XP Professional sull'hardware che si intende utilizzare per il proprio sistema Windows XP Embedded. Ciò consente di utilizzare tutte le routine di installazione di Windows XP affinché l'hardware funzioni correttamente e installare Windows Embedded Studio. In genere, il risultato è l'installazione di un database che viene utilizzato per gestire le immagini incorporate ma è possibile installare lo stesso database altrove, consentendo di creare un archivio centralizzato. Successivamente, verrà eseguita un'utilità da riga di comando chiamata Tap.exe, che crea un nuovo componente speciale che è possibile utilizzare da Windows XP Embedded. Di norma, i componenti racchiudono alcune funzionalità come i lettori multimediali, un file system o altre applicazioni personalizzate; in questo caso viene creato un componente che contiene i driver delle periferiche hardware necessarie per quel particolare sistema. È necessario poi completare questo passaggio sull'hardware di destinazione in modo che lo strumento possa individuare e includere i driver hardware appropriati.
Nel passaggio successivo, viene eseguito Windows XP Embedded Component Designer e importato il pacchetto di componenti creato dall'utilità Tap.exe. Come illustrato nella Figura 2, Component Designer legge le informazioni dei dispositivi e assembla un componente completo Windows XP Embedded che può diventare la base per una nuova immagine Windows XP Embedded. Ciò semplifica enormemente il processo determinando esattamente quali driver di periferica sono necessari per una determinata piattaforma. Dopo aver creato il componente, utilizzare Component Database Manager per importare il nuovo componente nel database componenti di Windows XP Embedded, un archivio dove vengono memorizzati tutti i componenti noti di Windows XP Embedded. Se il componente è presente nel database è disponibile per l'uso nelle immagini di Windows XP Embedded.
Figura 2 Progettazione componenti
Figura 2 Progettazione componenti (Fare clic sull'immagine per ridurla)
Figura 2 Progettazione componenti
Figura 2 Progettazione componenti (Fare clic sull'immagine per ingrandirla)
Adesso è possibile iniziare a creare una nuova configurazione di destinazione, utilizzando Target Designer di Windows XP Embedded, lo strumento in cui si svolge la maggior parte del lavoro. Come si è visto nella Figura 1 è possibile aggiungere qualsiasi componente necessario per creare la serie di funzioni richieste dalla periferica. Sarà necessario aggiungere anche alcuni componenti principali di Windows, come Esplora risorse (se la periferica richiede una shell grafica), il file system NTFS (o FAT32), NT Loader, il supporto per una lingua, la parte principale dell'interfaccia utente e così via. Per impostazione predefinita sono disponibili più di diecimila componenti.
È anche possibile preconfigurare tutte le impostazione del componente. Ad esempio, il componente base dell'interfaccia utente può essere personalizzato per visualizzare elementi specifici nel menu di avvio di Windows, sul Desktop e in altre posizioni. La personalizzazione delle impostazioni di ogni componente assicura che ogni periferica venga preconfigurata per soddisfare le specifiche esigenze (vedere la Figura 3).
Figura 3 Personalizzare le impostazioni
Figura 3 Personalizzare le impostazioni (Fare clic sull'immagine per ridurla)
Figura 3 Personalizzare le impostazioni
Figura 3 Personalizzare le impostazioni (Fare clic sull'immagine per ingrandirla)
La parte più complicata dell'immagine di Windows XP Embedded è rappresentata dalle dipendenze. Ad esempio, non è possibile aggiungere un componente DirectX all'immagine senza aggiungere diversi componenti che forniscono a Windows le principali funzionalità di gestione grafici. Tenere traccia di tutte le dipendenze può diventare abbastanza difficile, soprattutto per le immagini più grandi e complesse che possono avere letteralmente migliaia di dipendenze. Questo è il compito del Database componenti. È sufficiente premere F5 in Target Designer e scorrere tutti i componenti inseriti, aggiungendo automaticamente tutte le dipendenze richieste dai componenti elencati. Nella Figura 4 viene illustrata l'analisi in corso; si tratta di un passaggio critico ed è ciò che consente a Windows XP di essere così estremamente modulare. Senza questa intelligenza integrata in Target Designer, sarebbe molto difficile creare correttamente immagini che contengano tutte le dipendenze corrette.
Figura 4 Verifica delle dipendenze
Figura 4 Verifica delle dipendenze (Fare clic sull'immagine per ridurla)
Figura 4 Verifica delle dipendenze
Figura 4 Verifica delle dipendenze (Fare clic sull'immagine per ingrandirla)
Una volta aggiunti tutti i componenti e le relative dipendenze, è possibile creare l'immagine di Windows XP Embedded. Le immagini sono semplicemente i file che è necessario copiare nel volume di avvio del dispositivo Windows XP Embedded. Non serve alcuno strumento speciale per distribuire le immagini (anche se il toolset Windows XP Embedded contiene un server di avvio remoto simile nella funzionalità ai Servizi di installazione remota; consente la distribuzione delle immagini di Windows XP Embedded sui nuovi dispositivi). Dopo aver completato questi passaggi, è possibile vedere quanto sia grande l'immagine in realtà. Creando un'immagine semplice con la shell di Esplora risorse e alcune applicazioni, come Blocco note e Paint, si ottiene un'immagine di dimensioni inferiori a 90 megabyte. Certo non è facile trovare molti utenti interessati a una periferica che esegue solo Blocco note e Paint, ma l'esempio illustra quanto piccola può essere un'immagine specifica di un'attività.

Windows XP Embedded rispetto a Windows XP
Windows XP Embedded non è affatto un'opzione ridotta del sistema operativo. Microsoft offre componenti preassemblati che consentono a un computer con Windows XP Embedded di disporre di gran parte delle stesse funzionalità di una versione completa di Windows XP. In questo modo vengono incluse opzioni per installare DirectX 9.0c, Microsoft® .NET Framework, Windows Media® Player 10 e altro. È disponibile anche molta documentazione per sviluppatori che descrive come creare componenti personalizzati, ad esempio una shell personalizzata per sostituire Esplora risorse, consentendo di creare un ambiente su misura per la specifica periferica Embedded.
Tuttavia, Windows XP Embedded non offre ogni singola funzionalità della versione completa di Windows XP Professional. Ad esempio, Protezione file Windows (WFP) non è presente in Windows XP Embedded e neppure alcune delle semplici funzionalità, come Presentazione di Windows XP, le schermate iniziali e le procedure guidate che aiutano un nuovo utente a configurare il proprio computer o Installazione di Windows. Windows XP Embedded non utilizza Attivazione di un prodotto Windows (le immagini di Windows XP Embedded vengono attivate utilizzando un codice "Product Key" di runtime dagli strumenti di Windows Embedded Studio). In particolare, Windows XP Embedded non utilizza affatto Windows Update, sebbene possa utilizzare un server Microsoft Software Update Services nel proprio ambiente. Infine, in Windows XP Embedded manca anche MSN® Explorer, che è contenuto in Windows XP Professional.
Per il futuro, Windows XP Embedded prevede un ricco percorso di sviluppo: Attualmente è disponibile Feature Pack 2007 che aggiunge nuove funzionalità come l'avvio da USB, un miglioramento a EWF che consente di eseguire il commit dei nuovi file sul volume padre senza eseguire il commit dell'intero overlay, il supporto per la compressione NTFS e altro. Questi miglioramenti continuano ad aggiungere flessibilità e opzioni al sistema operativo Windows XP Embedded, portandolo sempre più a un livello paragonabile con le funzionalità impostate in Windows XP Professional.

Embedded
I sistemi Embedded possono richiedere maggiore lavoro per la costruzione rispetto a un sistema Windows XP tradizionale, ma offrono vantaggi significativi in determinati scenari. Sebbene ridotti nelle funzionalità, i sistemi Windows XP Embedded possono supportare hardware più piccoli, meno potenti, più facili da gestire e riparare, con costi ridotti. La riduzione del consumo di energia consente di ridurre anche le bollette e l'emissione di calore, favorendo maggiore flessibilità nella progettazione di aree di lavoro compatte. Oltre agli usi previsti di Windows XP Embedded, come nei dispositivi per l'elettronica di consumo, nei dispositivi medicali, nei punti vendita e in altri luoghi dove forse neanche si immagina che ci possa essere Windows XP Embedded, questo sistema operativo incorporato può sicuramente trovare spazio anche nella tua azienda.

Don Jones è il responsabile progetti e servizi di SAPIEN Technologies e coautore di Windows PowerShell: TFM (SAPIEN Press). Don può essere contattato tramite il suo sito Web all'indirizzo ScriptingAnswers.com.


 Gestione: Pianificare con System Center Capacity Planner
Gestione John Savill

Pianificare con System Center Capacity Planner
Panoramica:
  • Elementi di base di SCCP
  • Creazione di un nuovo modello
  • Definizione dettagliata del modello
  • Simulazione dell'utilizzo effettivo

I componenti di un'infrastruttura oggi sono fondamentali per le attività supportate. Tuttavia, con l'aumento del numero di utenti e la diversificazione delle attività delle aziende, la valutazione esatta delle dimensioni e
del numero di server su cui eseguire i componenti è diventata una sfida ardua. Quando le risorse hardware sono insufficienti, si ottengono tempi di risposta non accettabili per gli utenti finali, mentre una quantità eccessiva di hardware rappresenta uno spreco di budget e comporta attività di gestione aggiuntive. Per questo motivo Microsoft ha creato System Center Capacity Planner (SCCP) 2006.
SCCP consente di immettere informazioni sulla topologia di rete (posizioni, velocità di collegamento, latenza), sul software e l'hardware da utilizzare e sui profili utente (come il numero di messaggi inviati). In SCCP è quindi possibile eseguire delle simulazioni dei diversi livelli di utilizzo e ottenere un dettaglio dell'impiego di hardware e componenti di rete. Questa simulazione aiuta a verificare se la configurazione proposta, se implementata, sarebbe adeguata per i requisiti di servizio richiesti.
Non è necessario eseguire SCCP su un server specifico o eseguire delle verifiche di rete. Si tratta essenzialmente di uno strumento di simulazione che può eseguire scenari di test a fronte di un ambiente modellato. I requisiti di sistema per SCCP sono minimi: Windows® XP con Service Pack 2 (SP2), Windows Server® 2003 o Windows 2000 con SP4, più Microsoft® .NET Framework 2.0. La prossima generazione di SCCP si interfaccerà in modo più stretto con Systems Management Server (SMS) e Microsoft Operations Manager (MOM) e consentirà di automatizzare alcune delle operazioni di raccolta di informazioni, poiché MOM raccoglie già informazioni sull'utilizzo del server mentre SMS gestisce le informazioni di configurazione dell'hardware.
L'installazione di SCCP 2006 è semplice; una procedura di installazione guidata standard che richiede solo l'accettazione del contratto di licenza e la conferma della cartella di installazione. Una volta installato il prodotto, viene aggiunta una voce al menu Tutti i programmi. Quando si avvia SCCP per la prima volta, la schermata iniziale di Microsoft Capacity Planner consente di accedere a tre dei quattro componenti del pianificatore di capacità come illustrato nella Figura 1.
Figura 1 Avvio dello strumento di pianificazione delle capacità
Figura 1 Avvio dello strumento di pianificazione delle capacità (Fare clic sull'immagine per ridurla)
Figura 1 Avvio dello strumento di pianificazione delle capacità
Figura 1 Avvio dello strumento di pianificazione delle capacità (Fare clic sull'immagine per ingrandirla)
Durante la creazione guidata del modello vengono formulate alcune domande sull'ambiente desiderato per la creazione di un modello di architettura del sistema (SAM). Il SAM contiene informazioni dettagliate su posizioni, utenti, rete, modelli di utilizzo e hardware.
L'editor modello consente di eseguire modifiche e impostazioni dettagliate per il SAM creato in precedenza con la procedura guidata o l'editor. Qui è possibile convalidare i modelli, visualizzare l'utilizzo simulato e verificare altri scenari, come carichi aggiuntivi sui server di posta o la presenza di utenti remoti.
Nel pianificatore di capacità sono già disponibili numerosi tipi di hardware predefiniti da utilizzare nei SAM. Tuttavia, se necessario, è possibile impostare configurazioni hardware personalizzate nell'editor.
Quando si seleziona un modello, la funzione di simulazione di Capacity Planner consente di eseguire vari test a fronte del modello selezionato per determinarne l'attuabilità per l'implementazione nel mondo reale.
Per visualizzare i componenti e rilevarne le interazioni, la cosa migliore da fare è provare a utilizzare lo strumento. Si inizierà con la procedura guidata, quindi si eseguirà una simulazione e infine la configurazione dettagliata di un modello di architettura aggiungendo dell'hardware personalizzato. Ai fini dell'esempio si utilizzerà un ambiente Exchange, ma il processo resta simile anche per MOM.

Creazione di un nuovo modello
Prima di eseguire la convalida o scenari di simulazione su un'infrastruttura pianificata o anche solo per provare l'impatto di alcuni scenari sull'infrastruttura esistente, è necessario descrivere l'ambiente in SCCP. Purtroppo, con la versione corrente dello strumento non è possibile eseguire la scansione della rete. È invece necessario immettere i dettagli dell'infrastruttura in termini di posizioni fisiche e tipi di connettività, posizionamento di server, caselle di posta e utenti, oltre ai dettagli sull'utilizzo dell'ambiente da parte degli utenti.
Lo strumento prevede alcune limitazioni, illustrate nel manuale per l'utente. In un modello Exchange, ad esempio, è supportata una sola foresta. Ne consegue che i domini delle foreste esterne non vengono inseriti nel modello e che catalogo globale e cassetta postale risiedono nello stesso sito. È possibile modellare solo 100 siti, di cui un massimo di 10 siti di hub, un massimo di 300 computer server e con il supporto solo di client Outlook ® 2003 (Web o locali). SCCP supporta fino a 49.999 client in posizioni centrali o di hub e fino a 10.000 in posizioni di ramo. Le funzionalità di Exchange come ActiveSync® e le connessioni Outlook Mobile Access non sono supportate, né lo sono le opzioni di connettività legacy come POP e IMAP. Non viene considerato l'utilizzo del sistema per operazioni di backup e ripristino, né le configurazioni in cluster; tuttavia, il pianificatore di capacità è dotato di tutte le opzioni necessarie per simulare l'utilizzo quotidiano tipico della posta elettronica.
Per iniziare la dimostrazione dalla pagina di benvenuto, scegliere l'opzione per la creazione guidata di un nuovo modello e descrivere l'infrastruttura da modellare. Per l'esempio si creerà un'azienda con tre sedi: un ufficio centrale a Dallas e due filiali a Houston e Austin, ciascuno con un certo numero di utenti locali di posta elettronica. Non è necessario configurare un server di posta per ciascuna sede, quindi si immettono le informazioni sul numero e sul tipo di utenti di posta elettronica; SCCP calcolerà in quali posizioni è opportuno inserire server Exchange locali e le sedi da cui gli utenti accederanno al server Exchange in modalità remota.
Dopo aver creato un modello di base dell'infrastruttura dell'organizzazione, la procedura richiede di immettere il numero di sedi centrali e filiali, il tipo di connettività tra le sedi e la percentuale di larghezza di banda che può essere utilizzata per la messaggistica. Durante la procedura guidata si ricorre a un approccio piuttosto ampio; in seguito sarà possibile modificare in modo dettagliato il modello creato dalla procedura guidata e impostare i singoli collegamenti con maggior precisione. Nell'esempio è possibile confermare una sede centrale e due filiali (vedere la Figura 2). Tra le filiali e la sede centrale esistono delle connessioni T1 ed è possibile utilizzare la metà della larghezza di banda per la messaggistica. Non è necessario configurare la velocità della connessione tra le sedi centrali, dato che ne esiste solo una.
Figura 2 Configurazione di topologia WAN e larghezza di banda della connessione
Figura 2 Configurazione di topologia WAN e larghezza di banda della connessione (Fare clic sull'immagine per ridurla)
Figura 2 Configurazione di topologia WAN e larghezza di banda della connessione
Figura 2 Configurazione di topologia WAN e larghezza di banda della connessione (Fare clic sull'immagine per ingrandirla)
Nella finestra successiva della procedura guidata viene richiesto il numero medio di utenti presso le filiali, il client di posta elettronica (Outlook 2003 in modalità cache o Outlook Web Access) e il numero di utenti presso la sede centrale. Anche in questo caso, le informazioni sono da intendersi ad alto livello e sarà possibile definirle con maggior precisione in seguito utilizzando l'editor del modello. In questo caso si imposteranno 200 utenti per ciascuna filiale e 500 per la sede centrale, che utilizzano tutti Outlook in modalità cache.
La procedura guidata prevede tre livelli predefiniti di utilizzo della posta elettronica: Alto, Medio e Basso. Per ciascun livello si presuppongono impostazioni quali dimensioni medie della cassetta postale, numero di messaggi inviati e ricevuti e dimensioni medie dei messaggi di posta elettronica. Se nessuno dei tipi incorporati è adatto ai modelli di utilizzo previsti per la propria organizzazione, è possibile configurare i singoli valori per ciascuna delle quattro caratteristiche di uso indicate.
Il prossimo passaggio consiste nel configurare le preferenze dell'hardware, come illustrato nella Figura 3. SCCP consente di definire fino a tre configurazioni di CPU possibili che vengono quindi utilizzate per modellare l'hardware per i vari ruoli server. La gamma di configurazioni CPU spazia da singolo un processore Pentium III Xeon a 1 GHz fino a una configurazione a quattro processori Xeon MP a 3,66 GHz. In Exchange 2003 sono inclusi alcuni ruoli, ovvero Archivio cassette postali, testa di ponte e front-end, più un ruolo Catalogo globale di Active Directory®. Se l'utilizzo lo consente, è possibile il consolidamento dei ruoli su un numero minore di server. Se non si specifica il consolidamento dei server, verranno configurati server diversi per ciascuno dei ruoli, anche se l'utilizzo non li richiede. È preferibile impostare SCCP in modo che i server vengano consolidati.
Figura 3 Configurazione dei profili hardware per i server
Figura 3 Configurazione dei profili hardware per i server (Fare clic sull'immagine per ridurla)
Figura 3 Configurazione dei profili hardware per i server
Figura 3 Configurazione dei profili hardware per i server (Fare clic sull'immagine per ingrandirla)
Infine, è possibile selezionare il tipo di dischi disponibili in base a interfaccia, dimensioni e velocità. Non è necessario specificare il numero di dischi che verrà invece calcolato dal pianificatore di capacità. È possibile anche che venga specificata una SAN (Storage Area Network) o rete di archiviazione, sebbene non sia ancora possibile creare dei cluster.
Il passaggio successivo della procedura guidata è un riepilogo del modello calcolato, in cui viene specificato il numero di server calcolato come ottimale da SCCP, i ruoli di ciascun server e le configurazioni di processore, memoria e disco. Se si è selezionata una SAN, sono riportate anche le informazioni corrispondenti.
Poiché ai fini dell'esempio si sono selezionate più posizioni, è possibile che vengano visualizzati i server solo per una parte delle posizioni. Questo accade perché SCCP ha ritenuto che non è necessario inserire dei server Exchange locali in alcune posizioni e che le cassette postali vengono servite meglio tramite un server delle cassette postali Exchange remoto, come illustrato nella Figura 4. In questo caso i 400 utenti delle filiali non dispongono di un archivio cassette postali locale, che è stato consolidato nel server di archivio cassette postali di Exchange della sede di Dallas, in cui sono ora specificati 500 utenti.
Figura 4 Un riepilogo della valutazione di pianificazione di capacità iniziale
Figura 4 Un riepilogo della valutazione di pianificazione di capacità iniziale (Fare clic sull'immagine per ridurla)
Figura 4 Un riepilogo della valutazione di pianificazione di capacità iniziale
Figura 4 Un riepilogo della valutazione di pianificazione di capacità iniziale (Fare clic sull'immagine per ingrandirla)
Fino a questo punto è possibile fare clic sui pulsanti Indietro e Avanti nella procedura guidata per modificare le risposte fornite e il riepilogo del modello (è anche possibile tornare a una pagina specifica della procedura guidata utilizzando il riquadro di navigazione sulla sinistra). Se la configurazione è soddisfacente, fare clic sul pulsante Fine della pagina di riepilogo del modello. Si passa alla finestra dell'editor modello, dove è possibile eseguire configurazioni più precise.

Configurazione dettagliata del modello
La creazione guidata è un ottimo strumento per la creazione di un modello di base. Tuttavia, a meno che le varie posizioni non siano del tutto simili, è probabile che sia necessario procedere a delle personalizzazioni in modo da rendere il modello davvero utile come base per il calcolo dell'utilizzo. Spesso ciascuna posizione include un diverso numero di utenti oppure una combinazione dei client di messaggistica Outlook 2003 in modalità cache e Outlook Web Access (OWA). Non è possibile per ottenere questo livello di dettaglio nella creazione guidata del modello, ma per queste configurazioni è possibile utilizzare l'editor modello. Questo strumento si rivela utile anche quando si desidera rilevare l'effetto delle modifiche di alcuni aspetti dell'ambiente, ad esempio l'aggiunta di altre posizioni o altri tipi di utenti.
L'editor modello, illustrato nella Figura 5, consente di salvare e recuperare modelli in file .sam, il formato proprietario dello strumento. È utile, come in tutte le attività lavorative, salvare i file dei modelli prima di eseguire modifiche importanti e utilizzare un nome descrittivo per evitare che dei modelli vadano perduti durante il lavoro. Nel menu File è disponibile una funzione di esportazione che consente di generare report di riepilogo dettagliati in formato Excel® e diagrammi di topologie Visio ® del modello.
Figura 5 Modifica di una configurazione SAM nell'editor modello
Figura 5 Modifica di una configurazione SAM nell'editor modello (Fare clic sull'immagine per ridurla)
Figura 5 Modifica di una configurazione SAM nell'editor modello
Figura 5 Modifica di una configurazione SAM nell'editor modello (Fare clic sull'immagine per ingrandirla)
Il riquadro a sinistra dell'editor modello è un'area di navigazione con delle opzioni utili per visualizzare la topologia globale, la topologia del sito o un riepilogo del modello. La topologia globale mostra il modello di architettura dal punto di vista di un sito con le reti aggiuntive, come Internet. Nella vista Topologia del sito vengono visualizzate delle informazioni su un sito o una rete specifica. Nel riepilogo del modello l'ambiente viene sintetizzato in formato testuale, che è lo stesso formato visualizzato alla fine della creazione guidata del modello.
Qualunque opzione si scelga, i dettagli vengono visualizzati nel riquadro centrale dell'editor modello. Nel riquadro destro, nello spirito della nuova versione di Microsoft Management Console (MMC) distribuita con Windows Server 2003 R2, è disponibile un'area per le "azioni" divisa in due sotto-aree: nella parte superiore sono evidenziate le azioni sensibili al contesto, che cambiano in base alla vista corrente o all'oggetto selezionato, mentre nella parte inferiore sono disponibili le azioni generiche sempre applicabili. Queste ultime azioni consentono di aggiungere un nuovo sito, modificare i profili degli utenti e (la parte più interessante) eseguire una simulazione.
Quando si utilizza il riquadro centrale dell'editor modello, è possibile selezionare tutti gli elementi. Dopo aver scelto un elemento, oltre alle azioni relative all'elemento corrente che cambiano in base all'oggetto selezionato, è possibile visualizzare informazioni più dettagliate sull'oggetto. Se, ad esempio, si fa doppio clic su un sito, si passerà alla vista Topologia del sito con i dettagli degli oggetti inseriti nel modello per il sito. Quindi, in un sito con dei server locali vengono mostrati uno o più server, le reti e gli utenti della posizione. Grazie a questa caratteristica dello strumento, è possibile fare doppio clic sull'oggetto selezionato, visualizzare le proprietà nel dettaglio e modificarle secondo necessità.
Le linee che collegano i siti rappresentano le reti tra le posizioni e possono essere modificate per definire la configurazione esatta della rete. È, ad esempio, possibile specificare la larghezza di banda in uplink e downlink e la percentuale di larghezza di banda disponibile. È inoltre possibile configurare la latenza della connessione, che può essere un attributo molto importante per la stabilità della comunicazione. Altre modifiche comuni prevedono l'aggiunta di altri tipi di utente. In questa istanza si immagini di avere a disposizione un mix di client Outlook Web Access e Outlook 2003 serviti dalla posizione centrale. Dopo aver aperto la sede di Dallas nella relativa vista della topologia del sito, sarà necessario aggiungere un profilo di client con le informazioni sugli utenti con OWA, ovvero il server utilizzato dai client OWA, la rete da cui si connettono gli utenti e la larghezza di banda disponibile, come illustrato nella Figura 6.
Figura 6 Aggiunta e modifica degli elementi di un modello
Figura 6 Aggiunta e modifica degli elementi di un modello (Fare clic sull'immagine per ridurla)
Figura 6 Aggiunta e modifica degli elementi di un modello
Figura 6 Aggiunta e modifica degli elementi di un modello (Fare clic sull'immagine per ingrandirla)
Quando il SAM riflette al meglio l'infrastruttura esistente o progettata, salvare e denominare il file in modo che sia facilmente identificabile come punto di partenza per qualunque modifica futura. A questo punto, è opportuno eseguire una simulazione per ottenere una valutazione delle prestazioni del modello con le impostazioni configurate. In base ai risultati della simulazione è possibile modificare il modello per verificare varie eventualità e scenari, come l'aggiunta di un nuovo sito e di nuovi utenti, l'aggiunta o rimozione di server, l'aggiunta di nuovi utenti nelle posizioni o la modifica del tipo di connessione o di client di posta elettronica. Dopo aver aggiornato il modello con questi nuovi elementi, è possibile eseguire un'altra simulazione e verificare il comportamento della nuova configurazione.

Simulazione dell'utilizzo reale
Per eseguire la simulazione è sufficiente fare clic sull'azione o sul pulsante della barra degli strumenti corrispondente. Viene prima di tutto verificata l'integrità del modello: gli eventuali difetti nel modello vengono visualizzati prima della simulazione. Se, ad esempio, si aggiungono dei client OWA a un modello in cui in precedenza non esistevano client OWA senza configurare alcun server front-end, un messaggio di errore notificherà l'assenza di server front-end. Se non vengono rilevati problemi, verrà visualizzato lo stato durante la simulazione.
Al termine della simulazione, viene generato un report con le informazioni dettagliate sull'utilizzo di tutti i componenti e viene aperta la vista con i risultati della simulazione. Viene inizialmente visualizzata una pagina riepilogativa con i dettagli sui massimi utilizzi di CPU, archiviazione e connessione (i colli di bottiglia più comuni), oltre ai tempi di transazione e latenza più lunghi, che possono influire sull'usabilità del sistema da parte dell'utente finale. È possibile visualizzare i dettagli sull'esatto utilizzo di server, SAN, connessioni locali ed esterne scegliendo i collegamenti nel riquadro sinistro dei risultati della simulazione, come illustrato nella Figura 7.
Figura 7 Riepilogo dei risultati della simulazione per un modello semplice
Figura 7 Riepilogo dei risultati della simulazione per un modello semplice (Fare clic sull'immagine per ridurla)
Figura 7 Riepilogo dei risultati della simulazione per un modello semplice
Figura 7 Riepilogo dei risultati della simulazione per un modello semplice (Fare clic sull'immagine per ingrandirla)
Posizionare il cursore del mouse sui vari elementi grafici, come l'analisi dei colli di bottiglia, per visualizzare il server e l'attributo del server che provoca il collo di bottiglia. Notare le impostazioni di soglia nel riquadro sinistro. Questa categoria consente di impostare una soglia di utilizzo ragionevole per la generazione degli avvisi, una funzionalità molto utile.
I report dettagliati sulla simulazione sono estremamente utili, non solo per indirizzare le decisioni di acquisto hardware, ma anche per visualizzare in anteprima le risorse di rete che saranno utilizzate dalle applicazioni di messaggistica. Per gli utenti che si connettono tramite i collegamenti WAN più lenti, ad esempio, il report costituisce un'indicazione delle prestazioni della connessione. Se le prestazioni sono insufficienti, è possibile scoprire se è possibile aumentare la velocità di connessione tra le posizioni oppure se è necessario aggiungere un server di archivio cassette postali locale con la semplice modifica del modello e la ripetizione della simulazione fino a ottenere i risultati che soddisfano i criteri specifici. Allo stesso modo, se i server utilizzano tutti la CPU al 5%, è possibile ridurre le specifiche dei server. Grazie alla facilità di modifica del modello e ripetizione della simulazione, è possibile sperimentare tutte le diverse opzioni di soluzione. Le precise misurazioni di tutti gli scenari di test consentono di affrontare con maggiori argomentazioni le riunioni su budget e pianificazione.

Riepilogo
Questo articolo è una panoramica su come SCCP consenta di simulare e analizzare la distribuzione di Exchange. SCCP è in grado di garantire lo stesso livello di modellazione e simulazione anche per MOM. È possibile scaricare SCCP come parte di MSDN® di Premium o di Technet Plus. ¦

John Savill è direttore dell'infrastruttura tecnica di Geniant. È un CISSP, un MCSE per protezione e messaggistica sul Windows Server 2003, otto volte MVP e un istruttore di Krav Maga. È inoltre l'autore di Windows Server 2003 Active Directory Design and Implementation pubblicato da Packt Publishing


 Gestione -: Inventari client avanzati con SMS
Gestione - Wes Dobry

Inventari client avanzati con SMS
Panoramica:
  • Utilizzo di Hardware Inventory Agent di SMS 2003
  • Espansione di inventari con i file MIF
  • File MOF dinamici e statici
Scarica il codice per questo articolo: DobrySMSInventory2007_04.exe (152KB)

A ogni amministratore, almeno una volta nella vita, è capitato di imbattersi in una situazione in cui il proprio capo abbia avanzato la richiesta di cercare una serie di informazioni la cui raccolta richiedeva un notevole impegno e lavoro. Immaginiamo tuttavia di trovarci di fronte a un amministratore lungimirante
che abbia già raccolto i dati richiesti. Egli potrebbe pertanto fornire al proprio capo le informazioni richieste in modo istantaneo, evitando inutili tempi di inattività, eliminando la necessità di ore di straordinario ed eventualmente garantendo alla propria società un risparmio non indifferente in termini di denaro. Potrebbe diventare un vero e proprio eroe.
Microsoft® Systems Management Server (SMS) 2003 consente di raccogliere un'estesa quantità di informazioni. Non è tuttavia in grado di raccogliere qualsiasi tipo di informazione. Per impostazione predefinita, SMS 2003 non fornisce ad esempio alcuna informazione sui gruppi locali e i relativi membri o sugli utenti locali e i rispettivi attributi. La mancata disponibilità di queste informazioni può rappresentare un problema nel caso in cui, ad esempio, un tecnico inserisca il gruppo Domain Users o Everyone nel gruppo Administrators locale in ciascun sistema utilizzato. Si supponga inoltre che una società non sia in alcun modo in grado di sapere quali elenchi di esclusione di file e cartelle locali siano inclusi nella soluzione antivirus/antispyware aziendale. Questo potrebbe non sembrare un problema di fondamentale importanza, almeno finché qualcuno nel settore IT non si accorga che gli utenti stanno includendo c:\*.*nell'elenco di esclusione.
Con la giusta combinazione delle conoscenze acquisite in relazione ai linguaggi di script, al servizio Windows® Management Instrumentation (WMI) e a SMS è possibile espandere gli inventari SMS in modo che siano in grado di contenere pressoché qualsiasi tipo di informazione. Questa espansione è resa possibile grazie all'utilizzo dei file MIF (Management Information Format) e MOF (Management Object Format).

Esecuzione di un inventario
Con SMS, le organizzazioni sono in grado di eseguire distribuzioni, personalizzate, monitorare le destinazioni e gestire i sistemi distribuiti. L'espansione degli inventari SMS consente di creare e gestire una destinazione molto più personalizzata. È possibile, ad esempio, applicare criteri di protezione locali aziendali distribuendo i criteri di protezione su sistemi i cui criteri sono stati modificati da un utente. È inoltre possibile disattivare account utente locali non approvati e rimuovere amministratori locali estranei.
Le organizzazioni utilizzano naturalmente SMS per ottenere in modo tempestivo informazioni dettagliate sui sistemi locali. L'espansione degli inventari consente di creare report con informazioni completamente personalizzate di cui non si potrebbe disporre in maniera immediata nel caso in cui si utilizzassero esclusivamente inventari predefiniti. Le informazioni possono essere inoltre molto granulari. Si supponga, ad esempio, di creare un report contenente il numero di sistemi che dispongono di una specifica chiave del Registro di sistema che fa riferimento a una determinata server farm. Questo consentirebbe agli amministratori di stimare in maniera approssimativa il numero di client che fanno riferimento a ciascuna farm in un determinato momento. Analogamente, il team di protezione può verificare quali sistemi in rete eseguono uno specifico processo noto come spyware.
Il valore dei file MIF e MOF deriva dalla capacità di immettere informazioni provenienti da quasi qualsiasi fonte con un minimo di manipolazione.??? Se sono basate su testo, le informazioni possono essere modificate e inserite in WMI con un file MOF o raccolte sotto forma di file MIF e inviate al successivo ciclo di inventario hardware. L'implementazione dell'espansione di un inventario prevede che si abbia una certa familiarità con il linguaggio VBScript o JScript® e che si sappia con esattezza quali informazioni si intende raccogliere. Considerato che è possibile raccogliere praticamente qualsiasi tipo di informazione, le competenze richieste possono spaziare dalla conoscenza generale di WMI alla conoscenza approfondita di SQL. La comprensione di SQL è naturalmente un requisito essenziale, indipendentemente dal tipo di informazione che si intende raccogliere, in quanto potrebbe essere necessario ricorrere a tali conoscenze nel caso in cui si presentasse la necessità di inserire in report i dati raccolti.

Funzionamento degli inventari
SMS contiene due tipi di processi di inventario: hardware e software. Gli inventari software includono solo informazioni sui file, indicando ad esempio la posizione in cui risiedono, le relative versioni, le dimensioni e altri attributi dei file. Tuttavia, il processo dell'inventario software consente anche di raccogliere i file e archiviarli nel server del sito.
L'espansione degli inventari hardware è un'attività piuttosto semplice in quanto gli inventari hardware contengono la più ampia gamma di informazioni relative a un sistema. Le informazioni negli inventari hardware vengono acquisite principalmente da WMI, dal Registro di sistema e dal BIOS di sistema.
Gli inventari hardware vengono raccolti in base a una pianificazione, che viene specificata nelle impostazioni del sito di Hardware Inventory Agent in SMS 2003. È possibile impostare le raccolte in modo che vengano eseguite con una frequenza massima di una volta al minuto o una frequenza minima di una volta dopo diversi mesi. In genere, è consigliabile trovare il giusto equilibrio tra l'esigenza di raccogliere le informazioni desiderate alla massima velocità richiesta dalla gestione e la necessità di evitare un carico eccessivo sulla rete, i server del sito, i punti di gestione o i client.
Quando Hardware Inventory Agent viene installato per la prima volta, viene automaticamente compilato il file sms_def.mof. Questo file contiene tutte le informazioni raccolte inizialmente da SMS. Quando questo file viene compilato, tutti gli spazi dei nomi SMS e le classi associate necessarie per Hardware Inventory Agent vengono creati in WMI. La maggior parte di questi elementi risiede nello spazio dei nomi \\.\root\CIMv2\SMS. Una volta completata l'installazione, Hardware Inventory Agent analizza la maggior parte di queste classi per creare le informazioni che verranno successivamente inviate al punto di gestione ed eventualmente al database del sito.

File MIF
Oltre a estrarre informazioni dalle classi WMI, Hardware Inventory Agent esegue la ricerca dei file MIF nelle cartelle delle raccolte NOIDMIF e IDMIF. Tutti i file MIF che l'agente trova in tali cartelle vengono elaborati nel successivo inventario hardware.
I file MIF forniscono il metodo più semplice per espandere l'inventario hardware SMS. Sono disponibili due tipi di file MIF: NOIDMIF e IDMIF. Questi sono file statici in formato XML che possono contenere praticamente qualsiasi tipo di informazione che un utente potrebbe desiderare di inserire nel database SMS. Possono essere creati con lgi stessi metodi utilizzati per creare normali file di testo. È possibile pertanto creare questi file tramite la maggior parte dei linguaggi di script o manualmente.
In genere, i file MIF vengono utilizzati in situazioni in cui le informazioni non sono contenute nel Registro di sistema o in WMI oppure quando è necessario immettere le informazioni manualmente. Questi file possono essere creati, ad esempio, quando il team di distribuzione dell'hardware rilascia un nuovo sistema. Il tecnico responsabile della distribuzione può accedere a un'applicazione HTML nel sistema e immettere tutte le informazioni sulle risorse da utilizzare per l'aggiornamento di un database di gestione delle risorse. Successivamente, questa applicazione crea in modo dinamico un file NOIDMIF e consente al tecnico di eseguire il download del file nella cartella delle raccolte del file NOIDMIF. Il file NOIDMIF può contenere tutte le informazioni immesse dal tecnico ed è incorporato nel database SMS.
Le differenze tra i file NOIDMIF e IDMIF sono minime. Un file IDMIF contiene un'intestazione univoca che fornisce informazioni sull'architettura e un ID univoco. I file IDMIF possono essere utilizzati per incorporare i dispositivi non di sistema in SMS come entità proprie. È possibile, ad esempio, utilizzare uno script per creare sistemi in SMS che corrispondono in realtà a stampanti e scrivere le informazioni su tali sistemi nel database SMS.
I file NOIDMIF e IDMIF vengono archiviati in percorsi standard, specificati dalle chiavi del Registro di sistema. In genere, vengono archiviati in %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF e ...\IDMIF, partendo dal presupposto che l'agente SMS sia stato installato nel percorso predefinito. Se l'agente è stato installato in un percorso personalizzato, le directory MIF dovrebbero risiedere in %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF e ...\IDMIF. Per eventuali dubbi sui percorsi di tali directory, è possibile trovare i percorsi elencati nelle chiavi del Registro di sistema seguenti:
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
I file MIF hanno sempre lo stesso formato, indipendentemente dalle informazioni raccolte. Se si esamina il file MIF illustrato nella Figura 1, si potrà notare che il file è composto da un singolo componente che contiene più gruppi e un singolo attributo in ciascun gruppo. Sebbene siano necessarie tutte le sezioni del file, non occorre tuttavia disporre di più di un gruppo o voce di attributo. Ciascun gruppo all'interno del file MIF può essere considerato come una riga all'interno dei dati della sezione specificata nell'inventario hardware e ogni attributo all'interno del gruppo può essere considerato come una colonna di tale riga.
Figure 1 LocalAdmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
Il file LocalAdmin.vbs, illustrato nella Figura 2, rappresenta un esempio piuttosto semplice di linguaggio VBScript. Questo file di esempio cerca la directory di NOIDMIF, elimina il file MIF temporaneo, se disponibile, crea il file MIF temporaneo, scrive in modo ricorsivo nel file le informazioni raccolte tramite una semplice query WMI, elimina il file MIF contenuto nella cartella delle raccolte di NOIDMIF e infine sposta il file NOIDMIF temporaneo nella cartella delle raccolte di NOIDMIF.
Figure 2 LocalAdmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
Sebbene i file MIF forniscano un metodo semplice per espandere l'inventario hardware SMS, è consigliabile prendere in considerazione alcuni fattori durante l'utilizzo di questi file. I file MIF vengono elaborati in ogni ciclo di inventario hardware. Tuttavia, poiché questi file vengono creati, raccolti, analizzati e infine inseriti nell'inventario, è possibile che la visualizzazione nell'inventario delle informazioni contenute in un file MIF venga ritardata di un ciclo di inventario hardware. Ne consegue che se una società dispone di cicli di inventario hardware della durata di un giorno, i dati nel database del relativo sito potrebbero risalire a due giorni prima. È pertanto necessario prestare particolare attenzione al momento in cui i programmi progettati per la creazione dei file MIF vengono annunciati e al momento in cui il ciclo di inventario hardware viene eseguito.
Si supponga ad esempio che una società denominata Contoso disponga di cicli di inventario di un giorno che vengono eseguiti a mezzanotte. Lunedì alle ore 13:00 viene eseguito un VBScript, che determina la creazione di un file NOIDMIF contenente l'output di uno scanner rootkit. Questo output viene raccolto a mezzanotte e restituito al punto di gestione. L'amministratore SMS di Contoso esamina tali informazioni il mercoledì sera alle ore 22:00 circa e rileva che le informazioni risalgono a 45 ore prima. Questa situazione si verifica in quanto l'amministratore SMS non ha considerato con attenzione quando annunciare il programma utilizzato per la creazione del file NOIDMIF.

File MOF
I file MOF sono più complessi rispetto ai file MIF. Presentano tuttavia un vantaggio rispetto ai file MIF, in quanto sono in grado di immettere le informazioni direttamente in WMI e diventano parte del processo di raccolta dei dati standard di Hardware Inventory Agent. Pertanto, potrebbe non essere necessario annunciare continuamente un VBscript per recuperare le informazioni necessarie, con un conseguente risparmio di tempo e frustrazione. Il file MOF può essere invece annunciato una sola volta per ogni computer e viene automaticamente compilato.
I file MOF offrono inoltre il vantaggio di rendere disponibili informazioni aggiornate in base al resto dei dati contenuti nell'inventario hardware. Ogni volta che Hardware Inventory Agent esegue il relativo ciclo, viene eseguita una query sulle classi e sui provider descritti nel file MOF e le informazioni vengono restituite in tempi brevissimi. Quando occorre ottenere informazioni in tempi rapidi, è possibile eseguire un pacchetto contenente il file MOF e un VBScript, iniziando un inventario hardware. Il tempo impiegato per acquisire le informazioni necessaire è pari alla durata di un ciclo di criteri di un programma annunciato.
I file MOF vengono classificati in tre categorie: file MOF per una classe e uno spazio dei nomi WMI esistenti, file MOF per una classe aggiuntiva con un provider WMI esistente e file MOF per una classe aggiuntiva che non dispone di un provider WMI.
I file MOF contengono due parti. La prima parte è la sezione relativa alla definizione degli spazi dei nomi. In questa sezione vengono identificate le informazioni del provider WMI. La seconda sezione contiene gli attributi di report di SMS. Questa sezione indica a Hardware Inventory Agent la posizione in cui cercare ed elaborare le informazioni contenute nelle classi WMI sopra citate. Poiché i file MOF gestiscono WMI direttamente, se si intende utilizzare questi file è consigliabile dedicare un po' di tempo alla consultazione del Software Development Kit (SDK) di Microsoft WMI (per ulteriori informazioni, visitare il sito Web all'indirizzo go.microsoft.com/fwlink/?LinkID=83121).
Ciascuna delle classificazioni sopra riportate dei file MOF può essere statica o dinamica. Si dispone, ad esempio, di un file MOF statico se la procedura di creazione della società prevede la creazione di un file MOF contenente informazioni relativi agli utenti responsabili della creazione del sistema, alla versioni build dei server utilizzate, alle versioni build iniziali, alla data di creazione del computer e così via. Poiché non è necessario aggiornare queste informazioni, è possibile inserirle direttamente nel file MOF e compilarle in WMI mediante mofcomp.exe. Successivamente, è necessario espandere l'area in cui Hardware Inventory Agent esegue la ricerca aggiungendo le informazioni relative a gruppi e classi al file sms_def.mof sul server del sito.
Un file MOF dinamico è simile a un file MOF statico, tranne per il fatto che, anziché scrivere le informazioni raccolte direttamente in WMI, i dati vengono raccolti tramite un provider WMI. Un provider WMI è un plug-in che consente a un'applicazione o un servizio di immettere le informazioni direttamente in WMI. Questo provider consente l'accesso dinamico ad altre aree di WMI e del sistema, ad esempio informazioni relative al Registro di sistema, ai percorsi dei file e a Windows Installer.
Per quanto concerne l'utilizzo dei file MOF, il metodo più semplice per migliorare l'inventario hardware consiste nel configurare l'inventario in modo che venga catalogata una quantità di informazioni maggiore rispetto a quella già presente in WMI. Questa operazione può essere eseguita estendendo il file sms_def.mof o attivando classi di report aggiuntive che sono correntemente disattivate. Il file sms_def.mof si trova nella cartella \\siteserver\SMS_<codicesito>\inboxes\clifiles.src\hinv. Tutti i dispositivi all'interno dell'azienda inseriranno il nuovo file sms_def.mof nel successivo ciclo di criteri del computer e inizieranno a raccogliere e a restituire le informazioni.
Il secondo approccio, in termini di difficoltà, prevede l'utilizzo di un provider WMI esistente ma la creazione di una nuova classe. Un esempio di questo approccio è illustrato nella Figura 3. In questo esempio, utilizzando il provider del Registro di sistema incorporato, la classe CU_Desktop viene creata con una proprietà dinamica che esegue una query su HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper nel dispositivo locale. Una volta compilato il file MOF sul client, è necessario aggiungere le informazioni contenute in SMS_Def_Extension.mof (vedere la Figura 4) a sms_def.mof. Il file contiene informazioni relative a se SMS deve restituire informazioni su di esso, al nome del gruppo, all'ID della classe, alla classe che Hardware Inventory Agent deve esaminare in WMI per individuare le informazioni da inserire nel report e, infine, ai valori effettivi.
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
I file MOF sono in grado inoltre di accedere alle informazioni fornite dai provider WMI che non sono incluse per impostazione predefinita nei sistemi. Per utilizzare questi provider, il provider WMI deve essere distribuito e installato prima della compilazione del file MOF sul client e prima dell'estensione del file sms_def.mof.

Conclusione
I file MIF e MOF sono strumenti potenti per raccogliere in modo rapido ed efficace le informazioni desiderate. Questi formati di file forniscono una struttura di base per inserire con facilità le informazioni desiderate nel database SMS senza modificare direttamente le tabelle. È possibile includere in inventari e in report pressoché qualsiasi tipo di informazioni. Ma, cosa più importante, è possibile evitare situazioni problematiche, in quanto gli amministratori possono operare in modo proattivo per raccogliere informazioni di importanza cruciale.
Il funzionamento dei file MIF e MOF non è di immediata comprensione. Sono tuttavia disponibili alcune risorse utili in cui vengono fornite informazioni sulla modalità di utilizzo di questi file. Per iniziare, consultare la Documentazione e l'SDK di WMI, oltre alla Guida operativa di Systems Management Server 2003. Si consiglia di dedicare tutto il tempo necessario alla comprensione di tali concetti in quanto l'utilità delle informazioni acquisite da un inventario SMS esteso può superare di gran lunga quella dei dati in esso inseriti.

Wes Dobry vive a Orlando, un'area della Florida in cui lavora come consulente e amministratore di rete per una grossa azienda che opera nel settore della sanità. È possibile contattarlo all'indirizzo wesdobry@wesdobry.com.


 Gestione: Distribuzione degli aggiornamenti software personalizzati con SMS 2003 R2
Gestione Steve Rachui

Distribuzione degli aggiornamenti software personalizzati con SMS 2003 R2
Panoramica:
  • Nuove funzionalità di gestione degli aggiornamenti in SMS 2003 R2
  • Custom Updates Publishing Tool
  • Inventory Tool for Custom Updates

Se è necessario distribuire aggiornamenti personalizzati per i propri sistemi, ad esempio per un hardware specifico o per applicazioni line-of-business, non è possibile sfruttare il vantaggio di un processo gestito e automatizzato come nel caso degli aggiornamenti Windows. Almeno non lo è stato fino ad ora. Adesso, grazie a Systems Management
Server (SMS) 2003 R2, è possibile utilizzare le stesse funzionalità di gestione degli aggiornamenti per distribuire i propri aggiornamenti personalizzati. SMS 2003 R2 contiene numerose nuove funzionalità, compreso un aggiornamento a Device Management Feature Pack, collegamenti a Operating System Deployment Feature Pack e molte funzionalità che migliorano il monitoraggio della protezione. Il prodotto dispone di uno strumento di analisi per la valutazione della vulnerabilità che è fondamentale per capire le potenziali vulnerabilità del sistema e della rete come ad esempio i punti deboli nella configurazione del sistema operativo, nelle password utente, nelle configurazioni IIS e SQL Server™. Comprende anche un Inventory Tool for Custom Updates (ITCU) e un Custom Updates Publishing Tool (CUPT). Questi due strumenti, su cui si soffermerà questo articolo, consentono la distribuzione di aggiornamenti personalizzati in modo facile ed efficiente.

Custom Updates Publishing Tool
Prima di installare e utilizzare SMS 2003 R2, la gerarchia, compresi i client, deve essere aggiornata a SMS 2003 Service Pack 2 (SP2). Per utilizzare CUPT è necessario passare a Microsoft® Management Console (MMC) 3.0. Non è necessario installare CUPT sul server del sito SMS, ma deve essere installato almeno in Windows® XP e richiede SQL Server 2005 per ospitare il relativo database; se SQL Server 2005 non è ancora disponibile è necessario installare SQL Server Express Edition. CUPT è fondamentale per introdurre e gestire gli aggiornamenti personalizzati nel sistema SMS, inoltre dispone di funzionalità che consentono di verificare i cataloghi creati prima della relativa pubblicazione in SMS.
Gli aggiornamenti personalizzati possono essere di due tipi, ossia aggiornamenti software forniti da terzi e aggiornamenti creati internamente specifici per un particolare ambiente. CUPT è lo strumento da utilizzare per gestire entrambi i tipi di aggiornamenti. È più facile utilizzare gli aggiornamenti personalizzati forniti da terze parti, pertanto inizieremo da qui. Al momento della pubblicazione di questo articolo tre aziende, Adobe, 1e e Citrix, stanno producendo cataloghi di aggiornamento che possono essere utilizzati per eseguire analisi e distribuire le patch appropriate in SMS. Le aziende partecipanti possono essere visualizzate selezionando i cataloghi dei partner con aggiornamenti personalizzati, come illustrato nella Figura 1.
Figura 1 CUPT in azione
Figura 1 CUPT in azione (Fare clic sull'immagine per ridurla)
Figura 1 CUPT in azione
Figura 1 CUPT in azione (Fare clic sull'immagine per ingrandirla)
Per utilizzare gli aggiornamenti forniti dai partner è sufficiente scaricare i cataloghi e aggiungerli a SMS. Come prima cosa scaricare gli aggiornamenti necessari, quindi selezionare l'opzione nel menu Azione per importare gli aggiornamenti. Tramite una procedura guidata verrà richiesta la posizione dei file cab appena scaricati. Al termine dell'operazione, i nuovi aggiornamenti saranno visibili nel CUPT per ulteriori configurazioni e pubblicazioni sul server del sito SMS. Si noti, tuttavia, che ogni aggiornamento necessario deve essere contrassegnato per la pubblicazione. Se un aggiornamento non è contrassegnato, non sarà incluso al momento della richiesta di pubblicazione. È possibile contrassegnare gli aggiornamenti in blocco, come illustrato nella Figura 2. Si noti che per far sì che l'aggiornamento venga pubblicato, è necessario che la colonna sull'estrema destra sia contrassegnata.
Figura 2 Impostazione del contrassegno di pubblicazione
Figura 2 Impostazione del contrassegno di pubblicazione (Fare clic sull'immagine per ridurla)
Figura 2 Impostazione del contrassegno di pubblicazione
Figura 2 Impostazione del contrassegno di pubblicazione (Fare clic sull'immagine per ingrandirla)
Se necessario, è possibile personalizzare ulteriormente ogni aggiornamento scaricato. A tal fine, è sufficiente selezionare l'aggiornamento e scegliere Modifica. Prestare attenzione quando si personalizza un aggiornamento, perché una configurazione impropria può portare a risultati imprevisti e non soddisfacenti.
Dopo aver contrassegnato gli aggiornamenti è possibile pubblicarli. È possibile effettuare la pubblicazione su un file cab esterno per un utilizzo futuro oppure sincronizzando gli aggiornamenti selezionati con il database del sito SMS per un utilizzo immediato. Per la sincronizzazione con il database del sito SMS è necessario fornire le informazioni di configurazione come il nome del server del sito e il percorso di origine del pacchetto (vedere la Figura 3).
Figura 3 Informazioni sulla sincronizzazione
Figura 3 Informazioni sulla sincronizzazione (Fare clic sull'immagine per ridurla)
Figura 3 Informazioni sulla sincronizzazione
Figura 3 Informazioni sulla sincronizzazione (Fare clic sull'immagine per ingrandirla)
È possibile visualizzare questa schermata evidenziando il nodo Aggiornamenti personalizzati e scegliendo Impostazioni dal menu Azione. Una volta fornito il nome server del sito accessibile e il percorso che indica la directory di origine di Inventory Tool for Custom Updates, verranno aggiornati il codice e lo stato del sito.
Con le opzioni di sincronizzazione impostate, CUPT è pronto a eseguire la sincronizzazione con il server del sito SMS. Per eseguire la sincronizzazione, scegliere l'opzione per la pubblicazione degli aggiornamenti dal menu Azione. In questo modo verrà avviata la pubblicazione guidata. Per pubblicare gli aggiornamenti nel database SMS per un utilizzo immediato, verificare che l'opzione di sincronizzazione con il database del sito di Systems Management Server sia selezionata. Fortunatamente, per questi passaggi è previsto un supporto visivo: se le impostazioni di sincronizzazione non sono state configurate l'opzione non è disponibile.
Al termine della procedura guidata, gli aggiornamenti personalizzati saranno disponibili per l'utilizzo nella console di amministrazione di SMS. L'avvio di Distribute Software Updates Wizard consente di utilizzare tutti gli aggiornamenti personalizzati.
Dopo aver analizzato il processo che consente di utilizzare gli aggiornamenti del fornitore per i prodotti di terze parti, cosa accade agli aggiornamenti personalizzati per i software di fornitori se non sono disponibili aggiornamenti preassemblati? Ecco dove CUPT si esprime al meglio. Con CUPT è possibile creare aggiornamenti personalizzati con criteri di assegnazione completi in grado di coprire quasi tutte le situazioni.
La creazione di un aggiornamento personalizzato non è difficile, ma richiede che l'amministratore sappia come aggiornare il software, quali criteri utilizzare per determinare se una patch è applicabile e quali regole di assegnazione utilizzare per individuare l'aggiornamento. Le regole di assegnazione sono definite separatamente dal processo di creazione dell'aggiornamento. È possibile visualizzarle selezionando l'opzione Gestisci regole dal menu Azione.
La creazione di un aggiornamento personalizzato viene avviata selezionando la voce Crea Aggiornamento nel menu Azione che avvia una procedura guidata dove si dovranno fornire i dettagli dell'aggiornamento personalizzato. La descrizione dettagliata della creazione di un aggiornamento personalizzato esula dall'ambito di questo articolo, ma è utile scegliere le proprietà in uno degli aggiornamenti personalizzati importati di terze parti per capire che cosa sia necessario immettere in ciascun campo durante la creazione dell'aggiornamento. Le proprietà di un aggiornamento configurato di terze parti sono illustrate nella Figura 4.
Figura 4 Proprietà di un aggiornamento di terze parti
Figura 4 Proprietà di un aggiornamento di terze parti (Fare clic sull'immagine per ridurla)
Figura 4 Proprietà di un aggiornamento di terze parti
Figura 4 Proprietà di un aggiornamento di terze parti (Fare clic sull'immagine per ingrandirla)
Utilizzando il processo di creazione di aggiornamenti personalizzati, è possibile non solo eseguire semplici aggiornamenti, ma anche configurare il software da distribuire ai sistemi client. Sebbene funzioni, non è un approccio consigliato né l'utilizzo previsto di CUPT.

Inventory Tool for Custom Updates
ITCU è un nuovo strumento inventario che viene utilizzato con i cataloghi di aggiornamenti personalizzati. Analogamente agli strumenti di analisi che lo hanno preceduto, ITCU crea raccolte, pacchetti e annunci personalizzati che vengono utilizzati per distribuire gli strumenti di analisi ai client SMS in azienda. Proprio come con gli strumenti di analisi precedenti, ITCU consente di recuperare il catalogo, in questo caso il catalogo degli aggiornamenti personalizzati, da un punto di distribuzione SMS accessibile, di eseguire l'analisi in base ai dati del catalogo, di inserire i risultati di quell'analisi in Strumentazione gestione Windows (WMI) e di riportare i risultati tramite l'inventario hardware. La differenza principale nel processo di analisi è rappresentata dal catalogo utilizzato.
L'introduzione di SMS 2003 R2 aggiunge uno strumento utile all'arsenale di protezione SMS esistente. Mai prima d'ora gli amministratori sono stati in grado di trarre vantaggio dall'infrastruttura SMS esistente per l'applicazione di patch di applicazioni personalizzate e di terze parti. SMS R2 è una funzionalità accolta con grande entusiasmo dall'amministratore che gestisce le patch.
A questo punto, si dispone di due strumenti per la gestione degli aggiornamenti software da fonti diverse da Microsoft. La comodità e la facilità di gestione fornite da CUPT e ITCU garantiscono che gli aggiornamenti personalizzati funzionino correttamente come quelli di Windows Update già in uso.
Risorsa di gestione degli aggiornamenti
  • TechNet: gestione degli aggiornamenti
  • Webcast: IT's Showtime - SMS 2003 R2
  • Dieci principi di Microsoft Patch Management

Steve Rachui è Manageability Support Escalation Engineer nel gruppo di servizi di supporto per i prodotti Microsoft. Ha supportato SMS sin dalla versione 1.2. È possibile contattarlo all'indirizzo steverac@microsoft.com.


 Dal redattore: Potremmo sbagliarci...
Dal redattore
Potremmo sbagliarci...

UNA DELLE PRINCIPALI DIFFERENZE tra la stampa e il Web è che la parola stampata rimane per sempre. Quando si inseriscono informazioni sul Web e, successivamente, si desidera modificarle, è sufficiente accedervi e apportare tutte le modifiche necessarie. Fin qui, niente di nuovo.
La stampa è, naturalmente, qualcosa di diverso. Quando si manda qualcosa in stampa non è possibile tornare indietro. Escono più di centomila copie e tutte le informazioni contenute nelle pagine resteranno nella libreria per sempre (o fino al prossimo trasloco). Inoltre, la stampa fornisce una progressione naturale di mese in mese, infatti la pubblicazione più recente contiene le notizie e gli articoli più aggiornati.
Oggigiorno, però, la rivista viene resa disponibile anche in rete dopo essere stata pubblicata e ciò crea un nuovo problema. Dal punto di vista di un utente che effettua una ricerca in rete, tutto il contenuto che si trova nel nostro sito Web è disponibile contemporaneamente. È difficile capire se si sta consultando la guida più aggiornata.
Per risolvere il problema, pochi anni fa è stato formulato un criterio di correzioni che migliora in modo univoco il prodotto stampato grazie alla capacità di raggiungere i lettori in linea. Nella pagina delle correzioni di TechNet Magazine, sarà possibile visualizzare la descrizione completa di tutte le modifiche apportate agli articoli successivamente alla pubblicazione. Segnaliamo uno dei cinque motivi per aggiornare un articolo: tecnico, editoriale, nuove informazioni, obsoleto e protezione.
Ad esempio, nell'articolo "Tecniche per semplificare la creazione di immagini desktop", pubblicato a maggio del 2006, veniva menzionato uno strumento chiamato CNIC non ancora disponibile. Dopo aver reso disponibile CNIC, viene aggiunto un aggiornamento alla pagina delle correzioni e un aggiornamento del redattore all'articolo pubblicato in linea. Selezionando il collegamento all'aggiornamento del redattore si accede direttamente alle nuove informazioni.
Come si può osservare, sebbene ogni pubblicazione di TechNet Magazine venga sostituita da una nuova un ogni mese, il criterio di correzione assicura che gli articoli siano sempre utili nel tempo. -JOSHUA TRUPIN

Si ringraziano i seguenti esperti tecnici di Microsoft: Luis Botero, Derek Del Conte, John Doyle, David Feldman, Scott Hinsley, Jesper Johansson, Brian Mohr, Michael Murgolo, John Orefice, Mark Russinovich, Matt Steele, Fergus Stewart, Jason Stolarczyk, Jim Truher e Alan von Weltin.


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

Sincronizzazione di file e directory
Allway Sync
allwaysync.com

Indipendentemente dal tipo di lavoro IT che svolgi, è molto probabile che trascorra la maggior parte del tempo a spostare file e directory da un posto all'altro, ad esempio da un computer fisso a una chiave USB o da server a un altro attraverso la rete. Spesso è importante mantenere sincronizzate queste directory per garantire che non si creino duplicati inutili e che si lavori con la versione più recente dei file. A volte può essere necessario sincronizzare file e directory su molti computer, come quando si distribuiscono file statici XML e HTML a tutto un gruppo di server Web. Allway Sync di Usov Lab è uno strumento utile per gestire questi tipi di attività.
Allway Sync dà realmente la possibilità di eseguire la sincronizzazione in n direzioni, dalla replica di file e directory in una sola direzione a opzioni multidirectory e bidirezionali. L'applicazione non consente solo di mantenere sincronizzate le risorse locali e di rete, ma supporta anche la sincronizzazione automatica con dispositivi rimovibili, come chiavi USB e unità disco ottiche riscrivibili. È possibile impostare Allway Sync in modo che venga avviato automaticamente quando il dispositivo viene connesso al computer.
Altre opzioni di avvio automatico per la sincronizzazione comprendono l'avvio quando vengono rilevate modifiche file, quando ci si connette o disconnette, quando viene avviato Allway Sync e a specifici intervalli di tempo. Tramite l'interfaccia grafica utente dell'applicazione, è possibile perfino collegare la sincronizzazione ad attività programmate.
Sincronizzazione di file e cartelle con Allway Sync
Sincronizzazione di file e cartelle con Allway Sync (Fare clic sull'immagine per ridurla)
Sincronizzazione di file e cartelle con Allway Sync
Sincronizzazione di file e cartelle con Allway Sync (Fare clic sull'immagine per ingrandirla)
Tutte le modifiche e le eliminazioni vengono riportate nel database locale dell'applicazione e Allway Sync offre molte opzioni per la gestione delle versioni dei file modificati e l'eliminazione dei file in conflitto, inclusa la rimozione permanente degli elementi, lo spostamento nel cestino o lo spostamento in una determinata cartella.
Per ogni processo, è possibile specificare diversi filtri di inclusione o esclusione per ottenere i file richiesti e ignorare quelli che non sono necessari. È possibile personalizzare le azioni che Allway Sync deve eseguire quando rileva avvisi o errori e configurare un'azione diversa per ogni tipo di avviso o errore. Ad esempio, è possibile scegliere di riprovare in automatico una copia in caso di errore ed è possibile configurare non solo il numero dei tentativi automatici ma anche l'intervallo di tempo tra i tentativi per adeguarsi a qualsiasi latenza di rete o problema di connettività a breve termine.
È possibile configurare il livello di dettaglio della funzionalità di registrazione dell'applicazione per garantire che si riceva il numero massimo di informazioni sui processi. Le impostazioni dell'applicazione possono essere importate ed esportate in formato XML, pertanto è facile tenerle in una copia di backup o trasferirle su un altro computer. E, a titolo di curiosità, l'applicazione offre inoltre una finestra di statistiche semplice da utilizzare (accessibile tramite il menu Help). Questo utile strumento consente di sincronizzare i file in un istante ed è semplicissimo da avviare.
Prezzo: Gratis per uso personale. 29,99 Dollari USA per uso commerciale.

Mappatura e monitoraggio della rete
LANState Pro
10-strike.com/lanstate

Un accesso veloce allo stato e alla disponibilità delle risorse di rete è fondamentale per un ambiente operativo IT proattivo. Quando si verifica un problema, devi saperlo prima di chiunque altro. L'utile mapper e monitor LANState di 10-Strike Software può essere utile per una visualizzazione rapida e per le capacità di gestione della LAN per le reti che si basano su Windows®.
Quando si avvia l'applicazione per monitorare la propria rete, è possibile selezionare Network Mapping Wizard (Mappatura guidata della rete), che consente di eseguire una scansione delle Risorse di rete o di un intervallo di indirizzi IP per gli host applicabili. Se si preferisce, è possibile aggiungere i propri host manualmente. Una volta creata la mappa della rete, LANState inizia automaticamente i controlli di stato che sono stati configurati, ad esempio il controllo sulla porta TCP o il controllo ping ICMP. Gli host attivi presentano una codifica a colori mentre gli host bloccati vengono visualizzati in grigio. In seguito sarà possibile sistemare la propria mappa in gruppi logici basati sulla propria configurazione e modificare qualsiasi elemento visivo così come aggiungere descrizioni e simili.
Creazione di gruppi di rete logici con LANState Pro
Creazione di gruppi di rete logici con LANState Pro (Fare clic sull'immagine per ridurla)
Creazione di gruppi di rete logici con LANState Pro
Creazione di gruppi di rete logici con LANState Pro (Fare clic sull'immagine per ingrandirla)
Gli strumenti di disegno e modifica sono un po' primitivi, ma una volta completata la mappa, è possibile salvarla in un file e non ci sarà bisogno di crearla di nuovo. Oltre ai controlli sulla porta TCP e sul ping ICMP, è possibile configurare LANState Pro in modo che controlli l'esistenza di una cartella o di un file, la dimensione di un file o lo spazio su disco disponibile su un host remoto con un preciso intervallo e timeout configurabile. Se si fa clic con il pulsante destro del mouse su un host viene visualizzato un menu di scelta rapida che consente di raccogliere ulteriori informazioni di sistema dall'host remoto, eseguire un trace route, inviare un ping, eseguire un controllo predefinito o inviare un messaggio di rete.
La visualizzazione delle informazioni di sistema visualizza ogni cosa, a partire dagli indirizzi MAC di NIC e indirizzi IP associati alle condivisioni di rete, servizi e account locali. La maggior parte delle informazioni a livello di sistema operativo richiede le autorizzazioni corrette e le porte aperte sul sistema remoto, ma è possibile ottenere anche un po' di dati utili dalle chiamate RPC. E, se si dispone di queste autorizzazioni, è possibile anche inviare segnali di avvio e arresto remoti agli host remoti.
Prezzo: 249,95 Dollari USA per licenza di un singolo utente.

Scripting da riga di comando
Recensioni
www.syngress.com

Le procedure guidate interattive e le interfacce utente grafiche di configurazione possono davvero semplificare le attività complesse. Ma quando si è un professionista IT, queste interfacce possono rallentare le operazioni e spesso non offrono abbastanza granularità o controllo per l'attività da eseguire. Fortunatamente, questo livello di controllo è quasi sempre raggiungibile tramite la CLI (Interfaccia della riga di comando). Se si è informati sugli strumenti inclusi in Windows e si impara a personalizzare il prompt dei comandi per semplificare le attività di amministrazione, si risparmia tempo, si migliora l'efficienza e si fornisce un controllo più preciso. Il libro Come ingannare l'amministratore di Windows utilizzando gli script da linea di comando (Syngress Publishing, 2006) di Pawan K. Bhardwaj può fornire utili suggerimenti per destreggiarsi con le utilità CLI e del sistema operativo.
Inoltre fornisce istruzioni per personalizzare la shell di comando utilizzando file batch per l'automazione e l'elaborazione dei batch e la gestione CLI di operazioni pianificate. Una volta assimilati i contenuti di queste sezioni, si passa alle utilità incluse nel sistema operativo di Windows che consentono di gestire dischi, file e directory. Inoltre viene fornita una panoramica dei comandi dei Servizi directory, come DSQuery e DSMod, che, in combinazione con le capacità di elaborazione batch acquisite nei precedenti capitoli, può consentire di risparmiare molto tempo per l'amministrazione delle strutture della directory.
Vengono descritti i comandi di rete di Windows, da Netstat a Pathping, e viene fornita una panoramica degli strumenti di connessione remota come TFTP, RSH e RCP. Inoltre, combinando questi strumenti con le abilità acquisite nella prima sezione del libro sulle attività automatizzate e pianificate, sarà finalmente possibile aumentare la propria produttività. Tutto sommato, nonostante non sia un riferimento completo per le utilità di Windows, il libro di Bhardwaj è un'utile integrazione ai volumi di riferimento.
Prezzo: 39,95 Dollari USA con acquisto diretto.

Test di affidabilità dell'hardware
BurnInTest
passmark.com/products/bit.htm

Se sei coinvolto nella produzione di PC personalizzati, nell'aggiornamento dei componenti hardware per il proprio portafoglio di client o solo nella creazione di una nuova rig del desktop per un amministratore con privilegi avanzati, è fondamentale garantire che i nuovi componenti funzionino correttamente prima di consegnarli agli utenti. BurnInTest di PassMark Software esegue un certo numero di test di stress sui componenti specificati per garantire che non diano problemi dopo la consegna.
Come per tutti i test software inclusi, l'applicazione tenta di utilizzare l'hardware, esercitando pressione sui componenti selezionati del sistema in quanto simula un lungo ciclo di attività in un breve intervallo di tempo. L'idea è scoprire qualsiasi errore nascosto prima che un sistema o dispositivo venga messo in funzione. Il test BurnIn consente di testare qualsiasi componente, dalla CPU e schede grafiche ai dischi rigidi e masterizzatori CD.
L'applicazione è molto facile da utilizzare e configurare e consente di modificare il ciclo di lavoro e le preferenze per ogni test del componente in una particolare configurazione. Una volta impostata la configurazione del test, è possibile salvare le proprie preferenze per un utilizzo futuro, velocizzando la successiva iterazione della procedura di test che potrebbe verificarsi nel giro di pochi mesi.
Ogni test ha un ciclo di lavoro configurabile, così da poter impostare un valore di carico da 1 a 100 per ogni componente che viene testato. Ad esempio, è possibile testare le operazioni matematiche della CPU con un carico del 75 per cento mentre si testa contemporaneamente un carico del 90 per cento sulla memoria di sistema. È possibile anche indicare a BurnInTest di fermarsi dopo un certo numero di minuti o cicli operativi.
L'applicazione consente di testare fino a 20 dischi rigidi, unità floppy e/o unità ottiche simultaneamente, così da poter testare il batch delle unità prima di immetterle nell'ambiente client. Questa può essere una funzionalità che consente di risparmiare molto tempo quando si aggiorna un componente di sistema dato che è possibile testare ogni nuovo componente subito senza dover testare i sistemi singolarmente. Mi piace l'idea che un programma offra un controllo INTELLIGENTE dei parametri.
La Professional Edition supporta numerosi test di loopback per porte USB 2.0 parallele e seriali. I dispositivi di loopback hardware sono disponibili per l'acquisto presso PassMark. Questa versione di BurnInTest può essere eseguita da CD o dall'unità della chiave USB, che insieme alla credibilità dei test eseguiti riduce l'impatto dell'applicazione sul sistema testato.
Prezzo: 49 Dollari USA per la Professional Edition; 24 Dollari USA per la Standard Edition.

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


 SQL: domande &amp; risposte: Nuova creazione di indici, lunghezza della coda del disco e altro
SQL: domande & risposte
Nuova creazione di indici, lunghezza della coda del disco e altro
A cura di Nancy Michell

D Come vengono ricreati gli indici di SQL Server? Mi serve sapere perché DBCC DBREINDEX utilizza tutto lo spazio sul disco e perché lo spazio non viene liberato se il comando ha esito negativo. La dimensione del database è di 90 GB e la tabella più grande è di 70 GB.
Quando eseguo DBCC DBREINDEX, lasciando libero il 10 percento dello spazio, viene utilizzato tutto lo spazio disponibile sul disco e il comando ha esito negativo. Mentre inizialmente il file di database ha una dimensione di 90 GB, quando il comando DBCC ha esito negativo, la dimensione del file di database aumenta a 160 GB e i 70 GB aggiuntivi non vengono mai liberati. È quindi necessario ridurre manualmente le dimensioni del database in più riprese per liberare questo spazio.
Quando il comando ha esito positivo, anche la dimensione del file di database è di 160 GB, ma lo spazio viene automaticamente liberato poche ore dopo la compattazione automatica. È corretto eseguire una deframmentazione invece di DBREINDEX per utilizzare meno spazio? Non sono presenti indici di cluster e utilizzo la modalità di ripristino semplice.
R Al livello più semplice, gli indici vengono ricreati generando una nuova copia di un indice che viene poi eliminata. Ciò significa che per un breve periodo di tempo esistono essenzialmente due copie di uno stesso indice. La creazione del nuovo indice potrebbe richiedere lo stesso spazio del file di database quanto quello dell'indice originale e se la nuova creazione richiede un'operazione di ordinamento è necessario ulteriore spazio, pari al 20 percento della dimensione dell'indice.
Nel peggiore dei casi, quindi, la ricostruzione di un indice richiede circa 1,2 volte lo spazio del vecchio indice. Se il file di database non dispone di spazio sufficiente, il file aumenterà di dimensione man mano che l'operazione procede. Se la funzionalità di aumento automatico di dimensione non è abilitata, oppure se non c'è spazio sufficiente sul volume del disco, è possibile che non sia disponibile spazio libero sufficiente e che l'operazione di ricostruzione non riesca.
A prescindere dalla riuscita, al termine dell'operazione di ricostruzione lo spazio aggiuntivo allocato al file di database non viene liberato. Si prevede che lo spazio sarà utilizzato per le normali operazioni del database.
L'esecuzione di una compattazione (manuale o automatica) genererà quasi sicuramente una frammentazione dell'indice a causa della modalità con cui funziona l'algoritmo. Per ulteriori dettagli, vedere Motore di archiviazione di SQL Server. La compattazione automatica può essere particolarmente dannosa per le prestazioni se il database ha bisogno di spazio libero per le normali operazioni, perché si potrebbe entrare in un circolo vizioso che vede l'alternarsi delle operazioni di aumento automatico di dimensioni-compattazione-aumento automatico di dimensioni-compattazione potenzialmente devastante per la frammentazione e le prestazioni.
L'utilizzo di DBCC INDEXDEFRAG (o ALTER INDEX ... REORGANIZE in SQL Server™ 2005) consente di utilizzare pochissimo spazio aggiuntivo del file di database, ma può richiedere molto più tempo e generare molte più registrazioni di transazioni rispetto alla ricostruzione di un indice. DBCC INDEXDEFRAG viene sempre registrato completamente, indipendentemente dalla modalità di ripristino in uso, mentre nella modalità di ripristino semplice la ricostruzione di un indice sarà con registrazione minima delle transazioni di massa. Esistono diversi vantaggi e svantaggi per ognuna delle soluzioni e sono descritte con maggiori dettagli nel white paper Procedure consigliate per la deframmentazione dell'indice di SQL Server.
Prima di decidere come correggere la frammentazione occorre dapprima decidere se davvero è necessario farlo. A seconda del tipo di operazioni per cui generalmente si utilizza l'indice, la frammentazione può non avere effetti sulle prestazioni, pertanto correggerla sarebbe uno spreco di risorse. Il white paper è molto dettagliato.
In conclusione: assicurarsi di aver scelto il metodo più appropriato per la rimozione della frammentazione per il proprio ambiente e che tale operazione supporti le prestazioni delle query.

D Ho configurato correttamente il mirroring del database tra due istanze SQL Server 2005. L'applicazione si connette a SQL Server utilizzando un account di accesso di SQL Server ed è realizzata utilizzando ADO e SQL Native Client. La stringa e le impostazioni di connessione specificano le informazioni corrette, compreso il partner di failover appropriato. Gli stessi account di accesso esistenti sul server principale sono stati creati anche sul server mirror. Quando si verifica un errore del database, il server mirror assume il ruolo principale e tutto sembra funzionare correttamente sull'istanza di SQL Server. È anche possibile collegarsi al server mirror utilizzando un account di accesso di Windows®. Tuttavia, la riconnessione dell'applicazione non avviene correttamente e segnala il seguente errore:
Cannot open database "<db name>" requested by the login. The login failed.
Sembra che l'account di accesso non sia associato a un utente nel nuovo database principale (in origine, il mirror). Dopo aver eseguito sp_change_users_login per sincronizzare gli utenti e gli account di accesso per il database, viene visualizzato un messaggio che indica che sono stati corretti più utenti isolati (orfani). In seguito, l'applicazione si ricollega correttamente al nuovo server principale. A ogni tentativo di failover viene rilevato lo stesso comportamento, ossia la perdita dell'associazione tra utente e account di accesso.
Esiste un modo per configurare le impostazioni di mirroring in modo da evitare questo problema?
R Sì. Il problema è dovuto al fatto che gli identificatori di protezione (SID) per gli account di accesso di SQL Server su ogni server non corrispondono, anche se i nomi per gli account di accesso sono gli stessi. Questo non è un problema per gli account di accesso Windows/utente/gruppo dominio perché i SID di questi account di accesso vengono creati in base al SID di dominio per il singolo utente/gruppo e saranno quindi gli stessi per lo stesso utente/gruppo, e non dipende dall'SQL Server al quale viene aggiunto quell'utente/gruppo.
Per eliminare la necessità della sincronizzazione lsp_change_users_login è necessario creare gli account di accesso di SQL Server sul server mirror non solo con lo stesso nome, ma anche con lo stesso SID del server principale. A tal fine, si utilizza la specifica SID nell'istruzione CREATE LOGIN durante la creazione di account di accesso sul server mirror, come indicato di seguito:
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
È possibile ripristinare il SID per ogni account di accesso dal server principale tramite una query su una vista del catalogo sys.sql_logins. Un esempio di query che genererà un'istruzione CREATE LOGIN effettiva per ogni account di accesso SQL Server/Windows su un determinato server viene illustrato nella Figura 1.
Figure 1 Generare un'istruzione CREATE LOGIN (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

D Quale dovrebbe essere la lunghezza media della coda del disco? Ad esempio, con 20 assi fisici separati dell'architettura Storage Area Network (SAN) con configurazione RAID 01, come si calcola la lunghezza media della coda del disco? La media della lunghezza della coda del disco è 20 o 2?
R Prima di sprecare tempo per la lunghezza media della coda del disco in un ambiente SAN, è bene considerare la latenza del disco. La risposta, in realtà, dipende da ciò che si desidera scoprire. Tra breve vedremo il perché.
La spiegazione di questo contatore (da Perfmon) è la seguente: "La lunghezza media della coda del disco è il numero medio di richieste di lettura e scrittura che sono state accodate per il disco scelto durante l'intervallo di campionamento". Si tratta di un contatore disco fisico o logico, pertanto il numero che si ottiene dipende dalla modalità con cui l'archiviazione sottostante viene presentata al sistema operativo.
Si prenda in considerazione il caso descritto. La presenza di 20 assi in una configurazione RAID 01 significa che vengono effettuati lo striping e il mirroring (oppure il mirroring e lo striping, a seconda di come viene letto 01 o 10). L'aspetto più importante della matrice di archiviazione è che sono presenti 10 assi in un set di striping.
Mancano però delle informazioni fondamentali, ossia la dimensione di striping, la dimensione delle scritture e il tipo di I/O che si sta inviando (lettura, scrittura, sequenziale o casuale).
Trascurando per il momento le informazioni mancanti, se la lunghezza media della coda del disco indica 10, significa che il sistema operativo ha accodato 10 I/O alla matrice del disco. In teoria, potrebbe esistere un I/O per ciascuno dei 10 set di mirror nello striping o 10 I/O tutti sullo stesso disco. Non c'è modo di sapere qual è la situazione.
Qui entrano in gioco le informazioni mancanti. Si supponga che la dimensione di striping sia di 64 KB, la dimensione di scrittura di 8 K e che si desideri eseguire un unico blocco di scritture sequenziali. Questo è uno scenario tipico per l'attività di archiviazione di SQL Server. In questo caso, ci sono molte probabilità che otto dei 10 I/O vadano sul primo disco e i due I/O rimanenti sul disco successivo. Quindi se si tenta di individuare la lunghezza della coda del disco per ciascun disco in questo scenario, il risultato è 8 per il primo disco, 2 per il secondo disco e 0 per i restanti otto dischi della matrice.
Si modifichi ora lo scenario con una dimensione teorica di striping di 8 KB, con blocchi di scrittura di 64 KB e una lunghezza della coda del disco pari a 10. In questo caso ogni blocco da 64 KB viene suddiviso su 8 dischi, quindi un I/O è scritto su 8 dischi e i 10 I/O accodati vengono distribuiti su 80 scritture su disco su tutti i 10 dischi della matrice. Se si tenta di calcolare la lunghezza della coda del disco per ogni disco nella matrice, il risultato è 8 per ogni disco nella matrice.
Ma siamo realistici e aggiungiamo un altro livello di incertezza allo scenario. Nella maggior parte dei casi, l'unità di archiviazione SAN si connette al server utilizzando uno o più HBA nel server, diverse fibre ottiche per collegare HBA a SAN, diverse porte sul front-end della SAN e probabilmente qualche tipo di modulo switch fiber nell'infrastruttura tra il server e la SAN. Successivamente, passiamo all'architettura interna dei bus nella SAN e alla modalità con cui i dischi vengono connessi alle porte anteriori della SAN.
Qualsiasi accodamento segnalato in Perfmon può essere un sintomo di elevata latenza o accodamento in uno qualunque di questi punti tra la posizione in cui il sistema operativo misura la lunghezza della coda del disco e la superficie dei dischi. Ecco perché si dovrebbe prendere in considerazione la latenza e basare le decisioni su quel contatore piuttosto che sulla lunghezza media della coda del disco.

D Utilizzando la replica transazionale e sapendo che molte righe sono state modificate manualmente nella tabella del sottoscrittore è normale riscontrare degli errori quando il server di pubblicazione tenta di aggiornare una riga che non esiste più nel sottoscrittore.
Vorrei sapere se esiste un modo, attraverso la replica, per reinizializzare la tabella dal server di pubblicazione invece di applicare nuovamente uno snapshot completo. La funzione tablediff sembra adatta allo scopo ma è necessario capire come interagisce con la replica.
Ad esempio, tablediff realizza uno snapshot della tabella del server di pubblicazione e lo confronta con l'equivalente della sottoscrizione? È necessario interrompere la replica per utilizzare l'utilità tablediff e garantire l'uniformità dei dati? Che altro è necessario sapere?
R Per prima cosa, tablediff non individua uno snapshot della tabella del server di pubblicazione o del sottoscrittore. Se si considera lo scenario descritto, esistono alcune opzioni da prendere in considerazione.
La prima è quella che consente di arrestare temporaneamente la replica ed eseguire l'utilità. Se si vuole evitare che gli utenti possano modificare i dati è possibile utilizzare i parametri -sourcelocked e -destinationlocked, che creano un blocco esclusivo su entrambe le tabelle mentre l'utilità è in esecuzione. Se questa soluzione non è percorribile, un'altra opzione consiste nel prendere in considerazione i parametri -rc e -ri lasciando la replica in esecuzione. In questo caso, tablediff viene eseguita una volta, successivamente viene eseguita ogni volta che si rilevano errori, eliminando così gli errori dovuti ai ritardi di propagazione della replica. È necessario ricordare, tuttavia, che con questa opzione, in base al ritardo di replica, non è detto che vengano individuate necessariamente tutte le righe modificate nel sottoscrittore.

Si ringraziano i seguenti professionisti IT di Microsoft per la propria esperienza tecnica: Sunil Agarwal, Chad Boyd, David Browne, Gilles Comeau, Emmanuel Dreux, Amanda Foote, Matt Hollingsworth, Paul Mestemaker, Uttam Parui, Paul Randal, Dennis Tighe e Steven Wort.


 Utilit&#224; in primo piano: Autoruns
Utilità in primo piano
Autoruns
Lance Whitney
Scarica il codice per questo articolo: Autoruns (490KB)

Il tipico PC con Windows® carica una matrice di elementi all'avvio, compresi file, driver, attività e servizi. A un certo punto, è molto probabile che sia necessario visualizzare e forse disattivare alcuni elementi di avvio, per risolvere i conflitti all'avvio, per individuare malware nella sequenza di avvio automatico, per ridurre il tempo di avvio di Windows o per liberare le risorse di memoria e di sistema.
L'Utilità Configurazione di sistema (msconfig.exe) consente di visualizzare e disattivare diversi file e servizi di avvio, ma ne esistono molti che non vengono visualizzati: barre degli strumenti, oggetti browser helper, estensioni shell di Windows Explorer. Inoltre, msconfig non condivide molti dettagli relativi a questi elementi. Per una migliore visualizzazione e gestione di tutte le applicazioni che partono all'avvio, fare riferimento a Autoruns di Sysinternals.
Autoruns, scritto da Mark Russinovich e Bryce Cogswell, è un'utilità gratuita che svela ogni elemento di avvio, conosciuto anche come un'immagine, su un PC basato su Windows. È possibile visualizzare tutte le immagini memorizzate nelle cartelle di avvio, nel Registro di sistema e nelle altre aree dove è probabile che si nascondano (vedere la Figura 1).
Figura 1 Visualizzazione degli elementi di avvio con Autoruns
Figura 1 Visualizzazione degli elementi di avvio con Autoruns (Fare clic sull'immagine per ridurla)
Figura 1 Visualizzazione degli elementi di avvio con Autoruns
Figura 1 Visualizzazione degli elementi di avvio con Autoruns (Fare clic sull'immagine per ingrandirla)
Autoruns illustra il nome e la posizione di ogni immagine. Per i file, visualizza il percorso di directory; per le voci del Registro di sistema, si ottiene la chiave esatta. Autoruns fornisce anche il nome dell'autore e una breve descrizione in base ai dati versione dell'elemento. Facendo doppio clic su una voce si giunge alla directory o alla chiave del Registro di sistema; se si fa clic con il tasto destro del mouse si apre un menu popup con più opzioni, compreso un comando Properties che visualizza la finestra standard delle proprietà del file con le informazioni complete sulla versione. L'opzione "Include Empty Locations" (Includi posizioni vuote) illustra tutte le aree di avvio del computer a prescindere se esistono o meno delle voci. È anche possibile selezionare altri account utente sul computer per visualizzare i relativi ambienti di avvio.
È possibile verificare la firma digitale di una voce attraverso il comando Verifica che sottopone a query i siti Web con gli elenchi di revoche di certificati (CLR) per determinare se un'immagine è firmata digitalmente e se è valida. Un'altra opzione "Hide Signed Microsoft Entries" (Nascondi le voci firmate da Microsoft) esclude le voci già firmate da Microsoft consentendo di concentrarsi sulle immagini di terze parti.
L'elenco completo degli elementi di avvio può essere esportato in un file di testo; questa operazione è utile se si desidera disattivare tutti gli elementi, inoltre è necessario uno snapshot dell'ambiente di avvio prima di modificarlo. Successivamente, è possibile confrontare il file di testo esportato con la configurazione di avvio modificata per visualizzare le modifiche.
Di seguito sono elencate alcune delle categorie di avvio trattate da Autoruns:
Logon (Accesso) include l'utente e tutte le cartelle di avvio dell'utente e le chiavi di avvio che si trovano nel Registro di sistema.
Explorer (Esplora risorse) contiene un elenco di estensioni shell, barre degli strumenti ed esecuzioni di installazione di Esplora risorse.
Internet Explorer include gli oggetti di browser helper e le barre degli strumenti e le estensioni di Internet Explorer®.
LSA Providers (Provider LSA) contiene l'autenticazione dell'autorità di protezione locale, la notifica e i pacchetti di protezione.
In Autoruns è possibile cancellare definitivamente un elemento di avvio o disattivarlo. Un'opzione di ricerca in rete consente di trovare gli elementi che è possibile disattivare senza rischi. Quest'opzione esegue una ricerca in Internet per le pagine Web che descrivono un elemento o la relativa categoria e consiglia se rimuoverlo all'avvio. Quando si disabilita un elemento, Autoruns lo sposta in una posizione di backup nel Registro di sistema o sul disco rigido.
Autoruns funziona con tutte le versioni di Windows comprese Windows XP 64-bit Edition e Windows Server® 2003 64-bit Edition. È disponibile una copia all'indirizzo microsoft.com/technet/technetmag/code07.aspx.

Lance Whitney è un consulente IT, insegnante e redattore tecnico. Ha trascorso molte ore a modificare le workstation e i server di Windows. Era un giornalista, ma circa 15 anni fa ha fatto un salto nel buio lanciandosi nel mondo dell'IT.


 The Cable Guy: Impostazioni dei Criteri di gruppo wireless per Windows Vista
The Cable Guy
Impostazioni dei Criteri di gruppo wireless per Windows Vista
Joseph Davies
In questo articolo sono fornite le informazioni sulle versioni non definitive di Windows Server "Longhorn" che sono soggette a modifiche.

Il lavoro di un amministratore potrebbe essere semplificato se si potessero centralizzare la configurazione e la distribuzione delle impostazioni di rete wireless a tutti i computer della rete Active Directory. Fortunatamente, Windows supporta una speciale estensione dei Criteri di gruppo per la configurazione del computer che consente di farlo. Si
chiama estensione dei criteri di rete wireless (IEEE 802.11), è supportata dai computer in cui viene eseguito Windows Vista™, Windows® XP, Windows Server® 2003 e la versione successiva di Windows Server, chiamata "Longhorn".
Ecco come funziona. Quando si accede al dominio o all'avvio (e in seguito a intervalli regolari), questi sistemi operativi scaricano automaticamente le impostazioni wireless in questa estensione dei Criteri di gruppo e le applicano. È possibile configurare i criteri wireless per un oggetto Criteri di gruppo basato sul dominio dal nodo seguente nello snap-in Editor oggetti Criteri di gruppo: Configurazione computer | Impostazioni Windows | Impostazioni di protezione | Criteri rete wireless (IEEE 802.11).
Nella Figura 1 viene illustrata la posizione del nodo Criteri rete wireless (IEEE 802.11) per un dominio Windows Server "Longhorn" o per un dominio Windows Server 2003 al quale è stato esteso lo schema con i file di estensione dello schema 802.11Schema.ldf e 802.3Schema.ldf (descritti in microsoft.com/technet/network/wifi/vista_ad_ext.mspx).
Figura 1 Nodo Criteri rete wireless (IEEE 802.11)
Figura 1 Nodo Criteri rete wireless (IEEE 802.11) (Fare clic sull'immagine per ridurla)
Figura 1 Nodo Criteri rete wireless (IEEE 802.11)
Figura 1 Nodo Criteri rete wireless (IEEE 802.11) (Fare clic sull'immagine per ingrandirla)
Per impostazione predefinita, non ci sono Criteri rete wireless (IEEE 802.11). Per creare un nuovo criterio, fare clic con il pulsante destro del mouse su Criteri reti wireless (IEEE 802.11) nella struttura della console e scegliere Crea un nuovo criterio di Windows XP o Crea un nuovo criterio di Windows Vista. Per ogni tipo di criterio, è possibile creare solo un singolo criterio ma è probabile che ognuno contenga delle impostazioni per le reti wireless multiple.
Per i criteri di Windows XP, le impostazioni sono molto simili a quelle descritte nell'articolo di luglio 2003. Tuttavia, esistono nuove opzioni per le reti wireless non broadcast, metodi di autenticazione Wi-Fi Protected Access 2 (WPA2) e impostazioni di roaming veloce per l'autenticazione WPA2. Per supportare queste nuove impostazioni, sui computer in cui viene eseguito Windows XP Service Pack 2 (SP2) è necessario installare l'aggiornamento del client wireless per Windows XP SP2 disponibile all'indirizzo support.microsoft.com/kb/917021.
Il criterio wireless di Windows Vista contiene impostazioni di criteri per i client wireless specifiche per Windows Vista e Windows Server "Longhorn". Se vengono configurati entrambi i tipi di criteri wireless, i client wireless di Windows XP utilizzeranno solo le proprie impostazioni dei criteri e i client wireless di Windows Vista utilizzeranno solo le proprie impostazioni dei criteri. Se non esistono impostazioni dei criteri di Windows Vista, i client wireless di Windows Vista utilizzeranno le impostazioni di Windows XP. In quest'articolo vengono descritte le possibili impostazioni di configurazione con i criteri wireless di Windows Vista.
Nella scheda Generale di un criterio di rete wireless di Windows Vista è possibile configurare un nome e una descrizione per i criteri, specificare se il servizio configurazione automatica WLAN è attivato e configurare l'elenco di profili di rete wireless e le relative impostazioni nell'ordine preferito (vedere la Figura 2). È anche possibile esportare un profilo in forma di file XML scegliendo il profilo e facendo clic su Esporta. Per importare un file XML come profilo wireless, scegliere Importa e specificare la posizione del file.
Figura 2 Proprietà dei criteri di rete wireless
Figura 2 Proprietà dei criteri di rete wireless (Fare clic sull'immagine per ridurla)
Figura 2 Proprietà dei criteri di rete wireless
Figura 2 Proprietà dei criteri di rete wireless (Fare clic sull'immagine per ingrandirla)
Nella Figura 3 viene illustrata la scheda delle autorizzazioni di rete per un criterio di rete wireless di Windows Vista con le impostazioni predefinite. Questa scheda è una novità per Windows Vista e consente di specificare le reti wireless per nome e consentire o negare l'accesso ad esse. Ad esempio, è possibile creare un elenco Consenti che contiene i nomi della rete wireless, anche noti come Identificatori dei set di servizi (SSID), al quale un client wireless di Windows Vista può connettersi. Ciò è utile per gli amministratori di rete che desiderano connettere un computer portatile di un'organizzazione a un set specifico di reti wireless, inclusa la rete wireless e i provider di servizi Internet wireless dell'organizzazione stessa.
Figura 3 Scheda Autorizzazioni reti
Figura 3 Scheda Autorizzazioni reti (Fare clic sull'immagine per ridurla)
Figura 3 Scheda Autorizzazioni reti
Figura 3 Scheda Autorizzazioni reti (Fare clic sull'immagine per ingrandirla)
In un elenco di reti wireless non consentite è possibile specificare i nomi dei set di reti wireless alle quali il client wireless non può connettersi. Questo è utile per evitare che i computer portatili si connettano alle altre reti wireless che si trovano nella portata dei computer, ad esempio, quando un'organizzazione occupa un piano di un edificio ed esistono altre reti wireless di altre organizzazioni su piani adiacenti. L'elenco Non consentire consente anche di evitare che i computer portatili si connettano alle reti wireless non protette conosciute. Per creare l'elenco o specificare le reti wireless individuali per concedere o negare l'accesso, fare clic su Aggiungi per aggiungere una rete wireless per nome e specificare se l'accesso è consentito o negato.
Nella scheda Autorizzazioni reti, esistono anche impostazioni per evitare le connessioni a reti wireless ad hoc o in modalità infrastruttura. È anche possibile consentire agli utenti di visualizzare le reti wireless che sono state configurate con accesso negato e di creare un profilo per tutti gli utenti. È possibile utilizzare un profilo per tutti gli utenti per consentire a qualsiasi utente di connettersi a una rete wireless specifica con un account sul computer. Se questa impostazione è disattivata, soltanto gli utenti nel gruppo di amministratori di rete o nel gruppo di operatori di rete possono creare profili per tutti gli utenti wireless sul computer.

Proprietà del profilo di rete wireless
Per gestire un profilo di rete wireless dalla scheda Generale del criterio wireless di Windows Vista, scegliere un profilo esistente e fare clic su Modifica o Aggiungi e quindi specificare se il nuovo profilo wireless è per una rete wireless ad hoc o in modalità infrastruttura.
Per creare un nuovo profilo wireless, iniziare dalla scheda Connessione dando un nome al profilo e creando un elenco di nomi della rete wireless al quale viene applicato (vedere la Figura 4). È possibile aggiungere nuovi nomi digitando il nome in Nome(i) rete (SSID) e scegliendo Aggiungi. È anche possibile specificare se il client wireless che utilizza questo profilo tenterà automaticamente di connettersi alle reti wireless denominate nel profilo quando si trova nell'intervallo (secondo l'ordine di preferenza dell'elenco di profili wireless sulla scheda Generale per i criteri di Windows Vista). Inoltre, è possibile indicare se disconnettersi automaticamente da questa rete wireless nel caso in cui una rete wireless preferita si trovi nella portata e indicare che le reti wireless in questo profilo sono reti non broadcast (anche conosciute come reti nascoste).
Figura 4 Scheda Connessione
Figura 4 Scheda Connessione (Fare clic sull'immagine per ridurla)
Figura 4 Scheda Connessione
Figura 4 Scheda Connessione (Fare clic sull'immagine per ingrandirla)
Nella scheda Protezione, illustrata nella Figura 5, è possibile configurare i metodi di autenticazione e crittografia per le reti wireless nel profilo. La scelta dei metodi di crittografia dipende dalla scelta del metodo di autenticazione. Queste scelte sono elencate nella Figura 6.
Figure 6 Metodi di protezione (Close Figure 6)

Metodi di autenticazione
Aperta
Condivisa
Wi-Fi Protected Access (WPA)-Personal
WPA-Enterprise
WPA2-Personal
WPA2-Enterprise
Aperta con 802.1X
Metodi di crittografia
Wired Equivalent Privacy (WEP)
Protocollo TKIP (Temporal Key Integrity Protocol)
AES (Advanced Encryption Standard)
Figura 5 Scheda Protezione
Figura 5 Scheda Protezione (Fare clic sull'immagine per ridurla)
Figura 5 Scheda Protezione
Figura 5 Scheda Protezione (Fare clic sull'immagine per ingrandirla)
Se si decide di scegliere WPA-Enterprise, WPA2-Enterprise o Aperta con 802.1X come metodo di autenticazione, è possibile anche configurare il metodo di autenticazione di rete (il tipo Extensible Authentication Protocol [EAP]), la modalità di autenticazione (riautenticazione dell'utente, autenticazione del computer, autenticazione dell'utente o autenticazione dell'ospite), il numero di tentativi di autenticazione non riusciti prima che l'autenticazione venga abbandonata e decidere se nascondere le informazioni sull'utente per le connessioni successive. Quest'ultima impostazione specifica che quando l'utente si disconnette, i dati credenziali dell'utente vengono rimossi dal Registro di sistema. In questo modo, quando l'utente successivo si connette, gli saranno richieste le credenziali (nome utente e password).
Per configurare le impostazioni di protezione avanzate per i metodi di autenticazione WPA-Enterprise, WPA2-Enterprise o Aperta con 802.1X scegliere Avanzate. Nella Figura7 viene illustrata la finestra di dialogo Impostazioni di protezione avanzate.
Figura 7 Finestra di dialogo Impostazioni di protezione avanzate
Figura 7 Finestra di dialogo Impostazioni di protezione avanzate (Fare clic sull'immagine per ridurla)
Figura 7 Finestra di dialogo Impostazioni di protezione avanzate
Figura 7 Finestra di dialogo Impostazioni di protezione avanzate (Fare clic sull'immagine per ingrandirla)
Nella sezione IEEE 802.1X è possibile specificare il numero di EAP successivi sui messaggi LAN (EAPOL)-Start che vengono inviati quando non esiste risposta ai messaggi di EPAOL-Start e l'intervallo di tempo tra la ritrasmissione dei messaggi EAPOL-Start quando non vengono ricevute risposte al messaggio EAPOL-Start precedentemente inviato. È possibile impostare anche il periodo per il quale il client di autenticazione non eseguirà alcuna attività di autenticazione 802.1X dopo aver ricevuto un'indicazione di autenticazione non riuscita da parte dell'autenticatore e l'intervallo che il client di autenticazione attenderà prima di ritrasmettere qualsiasi richiesta 802.1X dopo che l'autenticazione end-to-end 802.1X è stata iniziata.
Il Single Sign-On (SSO) consente di configurare quando si verifica l'autenticazione 802.1X relativa all'accesso utente e di integrare l'accesso dell'utente e le credenziali di autenticazione 802.1X sul server di accesso di Windows. Nella sezione relativa all'SSO, esistono alcune impostazioni per eseguire l'autenticazione wireless subito prima o dopo il processo di accesso utente e per specificare il numero di secondi di ritardo per la connettività prima che il processo inizi. È possibile indicare anche se richiedere all'utente i campi di input aggiuntivi se il metodo di autenticazione richiede all'utente di digitare le credenziali aggiuntive e per quanto tempo visualizzare quei campi e se le reti wireless per questo profilo utilizzano una LAN virtuale diversa (VLAN) per l'autenticazione del computer o dell'utente.
Nella sezione Roaming veloce, è possibile configurare le opzioni di preautenticazione e memorizzazione nella cache PMK (Pairwise Master Key). La sezione Roaming veloce viene visualizzata soltanto quando si seleziona WPA2-Enterprise come metodo di autenticazione. Con la memorizzazione nella cache PMK, i client wireless e i punti di accesso wireless (AP) memorizzano nella cache i risultati dell'autenticazione 802.1X. Quindi, l'accesso è molto più veloce quando un client wireless ritorna a un AP wireless che il client ha già autenticato. È possibile configurare un tempo massimo durante il quale una voce viene conservata nella cache PMK e il numero massimo di voci. Con la preautenticazione, un client wireless è in grado di eseguire un'autenticazione 802.1X con altri AP wireless nel proprio intervallo mentre è ancora connesso all'attuale AP wireless. Se il client wireless ritorna a un AP wireless con il quale è stato preautenticato, il tempo di accesso viene diminuito considerevolmente. È possibile configurare il numero massimo di tentativi di preautenticazione con un AP wireless.
Per ulteriori informazioni sul supporto wireless in Windows, vedere microsoft.com/wifi. Per ulteriori informazioni sui Criteri di gruppo di Windows, vedere le risorse all'indirizzo microsoft.com/gp.

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


 Windows PowerShell: Filtraggio e formattazione dei dati
Windows PowerShell
Filtraggio e formattazione dei dati
Autore: Don Jones

Per qualsiasi problema Windows PowerShell può restituire una grande quantità di informazioni utili, senza richiedere grande intervento da parte dell'utente. Ad esempio, consideriamo il semplice cmdlet Get-WMIObject che può essere utilizzato per restituire un elenco di servizi sul computer locale. La visualizzazione predefinita che elenca lo stato, il nome e la modalità di avvio dei
servizi in esecuzione è essenzialmente una visualizzazione della riga di comando della console dei servizi. Windows PowerShell™ consente di ottenere questa visualizzazione molto più facilmente.
Ma per i servizi sono disponibili molte informazioni più utili di quelle illustrate nella visualizzazione predefinita. Provare a eseguire questo comando:
$s = get-wmiobject win32_service
$s[0] | gm
La prima riga del comando restituisce una raccolta di tutti i servizi o, nello specifico, di tutte le istanze della classe Win32_Service da Windows® Management Instrumentation (WMI), e li memorizza nella variabile $s. Nella seconda riga si trova il primo servizio di tale raccolta (con il numero zero, indicato nelle parentesi quadre) e lo invia al cmdlet Get-Member che ho abbreviato utilizzando il relativo alias, gm. L'output risultante illustra tutte le proprietà e i metodi disponibili per quel tipo di dati. Ho deciso di utilizzare la classe Win32_Service in WMI invece del cmdlet Get-Service incorporato in Windows PowerShell perché WMI espone maggiori informazioni di quelle fornite dall'oggetto ServiceController di Microsoft® .NET, compresa la proprietà StartName. Tale proprietà mi fornisce il nome dell'account utente per il quale il servizio è in esecuzione. È possibile controllare il nome di una singola istanza, come la prima, nel modo seguente:
PS C:\> $s[0].StartName
LocalSystem
Occorre tenere presente che fare riferimento ai servizi in base al relativo numero ordinale all’interno della raccolta non è molto utile poiché i servizi non sono disposti con un particolare ordine. Sono infatti elencati di solito alfabeticamente, ma non sempre. Dal punto di vista della gestione, è probabilmente più interessante un elenco di tutti i servizi e l'account utilizzato per registrarsi. Questo sarebbe utile per un controllo della conformità. Dunque torniamo indietro un secondo e guardiamo quanto fornisce WMI per impostazione predefinita. Utilizzerò l’alias più breve di Get-WMIObject, gwmi (vedere la Figura 1).
Figure 1 Utilizzo di Gwmi (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
Questo è ovviamente solo un esempio, ma è possibile osservare che l'output non è realmente innovativo per un report gestionale. Ciò che voglio sapere è il nome del servizio e StartName, che è l'account per il quale viene eseguito il servizio. Voglio recuperare anche il report in un formato più leggibile rispetto a questo elenco, un po’ difficile da osservare. Ecco dove entrano in ballo i formidabili cmdlet di formattazione e filtraggio dei dati di Windows PowerShell.

Come ottenere i dati necessari
Inizio filtrando i dati provenienti da Get-WMIObject in modo che le proprietà che mi interessano siano visualizzate. Il modo migliore per farlo è di utilizzare il cmdlet di Windows PowerShell Select-Object o il relativo alias semplice, select. Select è progettato per accettare una raccolta di oggetti, come la raccolta restituita da Get-WMIObject, e per visualizzare solo le proprietà desiderate di tali oggetti. Questo significa che posso inviare l'output di gwmi per selezionare e specificare le due proprietà che mi interessano. Nella Figura 2 vengono illustrati i risultati che comprendono le proprietà Name e StartName formattate come una tabella.
Figura 2 Visualizzazione in una tabella delle sole proprietà Name e StartName
Figura 2 Visualizzazione in una tabella delle sole proprietà Name e StartName (Fare clic sull'immagine per ridurla)
Figura 2 Visualizzazione in una tabella delle sole proprietà Name e StartName
Figura 2 Visualizzazione in una tabella delle sole proprietà Name e StartName (Fare clic sull'immagine per ingrandirla)
Se lo producessi per un controllo di conformità, questo report conterrebbe in realtà troppe informazioni. Alcuni dei servizi sono disattivati, quindi molto probabilmente non importerebbe a nessuno leggere nell'output quale account verrebbe utilizzato dai servizi disattivati. Quindi applico un filtro che esclude tutti i servizi aventi un tipo di avvio Disabled, cioè la proprietà StartMode della classe Win32_Service.
Windows PowerShell esegue il filtraggio degli oggetti utilizzando il cmdlet Where-Object o il relativo alias più breve, where. Il cmdlet where accetta una raccolta di oggetti di input ed esegue su ciascun oggetto uno scriptblock per determinare se ogni oggetto sarà presente nell’output di cmdlet in base a un set di criteri definiti. Ogni oggetto che risponde a tali criteri produce il valore True per il confronto e viene inserito nell'output. Gli oggetti che producono un valore False non vengono inseriti.
In tal modo, ho stabilito che mi interessano soltanto gli oggetti la cui proprietà StartMode è uguale a Disable. In Windows PowerShell, questa valutazione appare nel modo seguente:
$object.StartMode –eq “Disabled”
Naturalmente, $object è solo un esempio. In realtà non sto scrivendo uno script e quindi non dispongo di una variabile denominata $object. All’interno di uno scriptblock utilizzato da where, tuttavia, utilizzo una speciale variabile denominata $_ che rappresenta l'oggetto in corso di valutazione da parte del cmdlet. Dunque, il mio scriptblock di where potrebbe somigliare al seguente:
$_.StartMode –eq “Disabled”
Posso testarlo abbastanza facilmente:
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
Certo, in questo test veloce, l'output viene nuovamente visualizzato con lo stile di elenco predefinito. E, per ridurre lo spazio utilizzato, ho incluso soltanto un servizio. Ma si noterà che questo output è al contrario: ho incluso i servizi disattivati invece di escluderli. Ecco perché ho ottenuto il mio scriptblock al contrario: Devo includere tutti i servizi quando StartMode non è uguale a Disable, come illustrato da questo esempio modificato:
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
Ora va meglio! Adesso che l'output contiene soltanto i servizi che mi interessano realmente, posso inviare ancora una volta l'output scelto e specificare le proprietà che desidero:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
Questa operazione di invio dati da un cmdlet a un altro e a un altro ancora spiega realmente le funzionalità di Windows PowerShell. Non ho scritto ancora uno script, tuttavia per ora sono riuscito a filtrare un grande set di dati per ottenere proprio l'output che cerco.

Il look "giusto"
Si noti che l'output di select è ancora un insieme di oggetti. Quando recupero una tabella ben formattata utilizzando Windows PowerShell, PowerShell.exe esegue effettivamente il rendering di quegli oggetti. In altre parole, poiché non posso vedere gli oggetti, Windows PowerShell ne esegue il rendering restituendoli come testo. In questo caso, esegue il rendering degli oggetti restituendoli come tabella, con una colonna per ogni proprietà, come illustrato nella Figura 2.
Questo può essere sufficiente per i miei scopi di controllo. D'altra parte, potrebbe non essere del tutto vero. Ognuno ha esigenze differenti e Windows PowerShell non presume di sapere quali sono. Fornisce invece gli strumenti per formattare l'output in qualsiasi modo per adattarlo meglio alle esigenze dell’utente. Quattro cmdlet incorporati, Format-List, Format-Custom, Format-Table e Format-Wide, sono progettati per accettare una raccolta di oggetti (come la raccolta restituita da select) e formattare quegli oggetti in vari modi. Format-Table è in sostanza ciò che Windows PowerShell utilizza già per formattare l'output del mio cmdlet di select. Per un approccio diverso, utilizziamo Format-List:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
Il risultato si presenta più o meno come in questo esempio:
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
Il cmdlet Format-Wide è progettato per produrre un elenco a più colonne, per impostazione predefinita, della prima proprietà da ogni oggetto. Prendiamo questa riga, ad esempio:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
Questa produce un elenco di nomi di servizi che non mi interessano. L'output non contiene StartName (vedere la Figura 3), che è un'informazione necessaria per il mio report di controllo.
Figura 3 L'output visualizzato utilizzando il cmdlet Format-Wide omette una informazione chiave: StartName
Figura 3 L'output visualizzato utilizzando il cmdlet Format-Wide omette una informazione chiave: StartName (Fare clic sull'immagine per ridurla)
Figura 3 L'output visualizzato utilizzando il cmdlet Format-Wide omette una informazione chiave: StartName
Figura 3 L'output visualizzato utilizzando il cmdlet Format-Wide omette una informazione chiave: StartName (Fare clic sull'immagine per ingrandirla)
Poiché mi sto occupando soltanto di due proprietà, è probabile che Format-Table e Format-List siano accettabili. Ma è improbabile che un revisore accetti di guardare queste informazioni sullo schermo. Preferirebbe probabilmente un file di tipo diverso.

Esportazione dati
Mettiamoci nei panni di un revisore: come preferirebbe visualizzare i dati? Potrebbe essere sufficiente esportare l'elenco di servizi e dei nomi di accesso in un file CSV (Comma-Separated Values), poiché il file può essere poi facilmente aperto in Microsoft Excel®. Per creare un file CSV, inviare semplicemente il proprio output al cmdlet di Windows PowerShell Export-CSV:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
Naturalmente oggi CSV sembra un po’ sorpassato. Forse i revisori preferirebbero che i dati fossero visualizzati come pagina Web su un server Intranet. A tal fine, è possibile iniziare convertendo l'output in HTML, utilizzando il cmdlet ConvertTo-HTML:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
L’HTML non elaborato è difficile da visualizzare, dunque sarà necessario scrivere l'output in un file:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
Il risultato, come illustrato nella Figura 4, è una pagina HTML ben formattata che è possibile inviare su qualsiasi server Web senza ulteriori modifiche.
Figura 4 Output visualizzato come pagina HTML ben formattata
Figura 4 Output visualizzato come pagina HTML ben formattata (Fare clic sull'immagine per ridurla)
Figura 4 Output visualizzato come pagina HTML ben formattata
Figura 4 Output visualizzato come pagina HTML ben formattata (Fare clic sull'immagine per ingrandirla)

Semplici fatti (fondamentali)
Windows PowerShell fornisce un rapido accesso a una vasta gamma di dati gestionali. Nello stato non elaborato, tuttavia, questi dati non sono sempre utili.
Filtrando i dati (utilizzando where), scegliendo le proprietà desiderate dell'oggetto (utilizzando select) e applicando un'opzione di formattazione appropriata (come Format-Table o Format-List) è possibile convertire rapidamente e facilmente questi dati in utili informazioni. In seguito, esportando i dati in formato file, che può essere condiviso facilmente, è possibile elaborare queste informazioni nel proprio desktop e comunicare informazioni utili ad altre persone della propria organizzazione

Autore: Don Jones Don Jones è il direttore progetti e servizi di SAPIEN Technologies e coautore di Windows PowerShell: TFM (SAPIEN Press). Contatta Don nel suo sito Web all'indirizzo www.ScriptingAnswers.com.


 Hey, Scripting Guy!: Gestire in modo semplice utenti e gruppi locali
Hey, Scripting Guy!
Gestire in modo semplice utenti e gruppi locali
Gli Scripting Guys di Microsoft
Scarica il codice per questo articolo: HeyScriptingGuy2007_04.exe (151KB)

Come è possibile gestire i descrittori di protezione in file e cartelle?

Che ci si creda o no, ci fu un tempo, molto lontano naturalmente, in cui gli Scripting Guys non erano così intelligenti. È difficile crederlo, ma... cosa intendete con "Non è difficile da credere"? E cosa vuol dire "Non è possibile che sia stato tanto tempo fa"? Forse è meglio che vi chiariamo le idee. Ovviamente, avete visto uno degli autori degli Scripting Guys mentre tentava di collegare il nuovo televisore qualche giorno fa.
Questo particolare Scripting Guy tuttavia direbbe in sua difesa che collegare un nuovo televisore non è scienza missilistica, è in realtà molto più complicato della scienza missilistica. Il semplice collegamento del televisore richiede l'utilizzo di tre cavi video e una coppia di cavi audio; per di più, occorre collegare un videoregistratore, un lettore DVD e un Xbox®, per non parlare dell'impostazione del controllo remoto "universale" in modo che il televisore sia in grado di riconoscere tutti questi dispositivi. In confronto a tutto questo, lanciare un satellite in orbita intorno a Marte è una passeggiata.
Sebbene tra mille difficoltà, lo Scripting Guy è riuscito alla fine a effettuare tutti questi collegamenti in modo corretto. Almeno così pensava, fino a quando non ha acceso tutti i dispositivi. Cosa è successo? Assolutamente nulla. Senza perdersi d'animo, ha controllato per tre volte ciascun collegamento. Ha consultato nuovamente tutti i manuali dell'utente e si è persino connesso a Internet nel tentativo di trovare qualche informazione utile. Nulla. Stava quasi per sacrificare il lettore MP3 al Dio dell'elettronica quando ha notato che non aveva eseguito un passaggio chiave: collegare il cavo uscente dalla cassetta di derivazione alla presa da parete.
Nota: si potrebbe pensare che le difficoltà che hanno messo a dura prova lo Scripting Guy durante l'esecuzione di questi collegamenti sia da attribuire all'eccessivo numero di dispositivi da collegare. Lo Scripting Guy sarebbe senza dubbio d'accordo con questa spiegazione. Tuttavia, ogni volta che la sua famiglia indice una votazione per decidere se sia necessario acquistare altri dispositivi, il povero Scripting Guy perde sempre per 2 a 0. In realtà il punteggio finale dovrebbe essere di 2 a 1 ma è sempre 2 a 0. Per qualche motivo, il voto dello Scripting Papà sembra non contare molto nelle elezioni familiari e non esistono "paper trail" a cui appellarsi.
Anticipo la risposta alla vostra prossima domanda e vi confermo che, ebbene sì, ci ha provato. Ma finora le Nazioni Unite non hanno accettato di inviare i monitor per le elezioni alla Scripting Casa.
A pensarci bene, tuttavia, non è tanto lontano il tempo in cui gli Scripting Guys e, in particolare lo Scripting Guy con il nuovo televisore, erano tanto stupidi quanto ingenui. Ad esempio, viene in mente il periodo della fase di pianificazione della progettazione della Microsoft® Windows® 2000 Scripting Guide e, quando giunse il momento di scrivere i capitoli del libro, sollecitarono l'aiuto di numerosi ...esperti. Uno dei capitoli che non ha avuto gran successo riguardava la gestione degli utenti e dei gruppi locali. "Gestione di utenti e gruppi locali?!?" dissero gli esperti. "Perché prendere in considerazione una tematica di questo tipo? A chi può interessare la gestione di utenti e gruppi locali?"
Tuttavia, con nostro sommo dispiacere, nel corso degli annoi abbiamo scoperto che tutti (a eccezione dei nostri "esperti" interni) sono interessati alla gestione di utenti e gruppi locali. Ogni settimana riceviamo tonnellate di messaggi di posta elettronica in cui vengono richieste informazioni su come eseguire operazioni quali l'aggiunta di un utente a un gruppo locale, l'eliminazione di un utente da un gruppo locale o la modifica della password di amministratore locale su un computer.
Per fortuna, nello Script Center Script Repository sono disponibili alcuni script di esempio in cui viene illustrato come eseguire queste attività, ma la maggior parte di questi script può essere utilizzata su un solo computer per volta. Questa soluzione non risponde tuttavia alle esigenze di gran parte degli utenti, che desiderano sapere come eseguire queste attività su più computer e come eseguirle tutte contemporaneamente. Modificare la password di amministratore locale su un singolo computer? Scripting Guys, relazionatevi con il mondo reale. A noi interessa eseguire tutte queste attività su tutti i nostri computer o su tutti i computer in un'unità organizzativa o su tutti i nostri server di posta o ... insomma, ci siamo capiti.
Se si considera che la Scripting Guide è stata pubblicata nel 2003, questo significa che per quasi quattro anni siamo stati inondati da questi messaggi di posta elettronica di questo tipo. Uno degli Scripting Guys ha di recente commentato: "Alcuni lettori desiderano sapere in che modo leggere i nomi dei computer da un foglio di calcolo di Microsoft Excel® e modificare la password di amministratore locale su ciascun computer". "Come poter soddisfare queste richieste?"
È vero, ci abbiamo impiegato quattro anni, ma alla fine abbiamo capito come risolvere il problema. Nella Figura 1 viene illustrato esattamente come eseguire questo tipo di operazioni.
Figure 1 Alla fine lo abbiamo capito. (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
Nota: come potete notare, abbiamo impiegato quattro anni a scrivere questo script non perché fosse particolarmente complesso ma perché questo è in genere il tempo impiegato per la scrittura di qualsiasi tipo di script. Ecco perché è opportuno non mancare alle feste di capodanno annuali organizzate dagli Scripting Guys; dopo tutto, non si può mai sapere quando, o se, capiterà il successivo evento annuale.
Di seguito viene illustrato uno script che consente di leggere i nomi dei computer da un foglio di calcolo e di modificare la password di amministratore locale su ciascuno di questi computer. L'esecuzione di questa attività presuppone che si disponga di un foglio di calcolo molto semplice, simile a quello illustrato nella Figura 2. In caso contrario, crearne uno subito.
Figura 2 Elenco obbligatorio di computer
Figura 2 Elenco obbligatorio di computer (Fare clic sull'immagine per ridurla)
Figura 2 Elenco obbligatorio di computer
Figura 2 Elenco obbligatorio di computer (Fare clic sull'immagine per ingrandirla)
Come potete notare, non c'è nulla di speciale in questo script. Nella colonna 1 (colonna A), sono elencati i nomi di tutti i computer per i quali è necessario modificare la password. Nella colonna 2 (colonna B) si tiene semplicemente traccia della data e dell'ora dell'ultima modifica apportata alla password di amministratore locale. Questo consente agli utenti di verificare con facilità se le password di amministratore sono tutte sincronizzate.
Lo script inizia con l'istruzione On Error Resume Next. In genere, non ci preoccupiamo di includere la gestione degli errori nei nostri script. La ragione di questo non deve essere addebitata al fatto che siamo contrari alla gestione degli errori, ma perché cerchiamo sempre di mantenere i nostri script il più brevi e semplici possibile. In questo caso, tuttavia, l'istruzione On Error Resume Next riveste un'importanza fondamentale. Dopo tutto, lo scopo di questo script è tentare di stabilire una connessione a numerosi computer. Cosa succede se uno di questi computer viene spento? Grazie alla gestione degli errori, non accadrà nulla. In realtà, un errore si verifica, ma lo script sarà in grado di eliminarlo automaticamente e procedere. Senza la gestione degli errori, ci si troverà in una situazione molto simile a quella a cui ha dovuto far fronte lo Scripting Guy quando ha acceso il nuovo televisore per la prima volta: non è successo nulla.
Successivamente, utilizziamo il seguente blocco di codice per creare un'istanza dell'oggetto Excel.Application, rendiamo visibile su schermo l'istanza di Excel e apriamo il foglio di calcolo C:\Scripts\Test.xls:
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
Infine, ma non meno importante, assegniamo il valore 2 a una variabile contatore denominata i. Questa variabile verrà utilizzata per tenere traccia della riga corrente nel foglio di calcolo.
Nota: perché alla variabile i viene assegnato il valore 2? È facile: se si esamina con attenzione il foglio di calcolo, si potrà notare che i dati iniziano in realtà nella riga 2. La riga 1 è semplicemente una riga di intestazione.
Visto? Potremmo non essere in grado di collegare cavi YPbPr1, ma in compenso nessuno può negare che di script qualcosa ne sappiamo.
A volte, almeno.
A questo punto, siamo pronti per metterci al lavoro. Prima di tutto, impostiamo un ciclo Do Until che viene eseguito fino a quando non viene rilevata una cella vuota nella colonna 1. Questo significa che, indipendentemente dalle operazioni in corso, non è possibile lasciare vuota alcuna riga nella colonna 1. Se lo script rileva una riga vuota, presupporrà che si sia raggiunta la fine dei dati e pertanto il ciclo (e quindi lo script) terminerà. Sebbene esistano metodi in grado di aggirare questo problema, è molto più semplice evitare di lasciare vuote le righe nel foglio di calcolo.
All'interno del ciclo, iniziamo assegnando il valore presente nella riga della cella i, colonna 1 a una variabile denominata strComputer. Tenete presente che alla prima esecuzione del ciclo, i è uguale a 2; pertanto verrà utilizzato il valore contenuto nella riga della cella 2, colonna 1. Utilizzeremo quindi questa riga di codice per creare un riferimento a un oggetto (objUser) per l'account Administrator locale sul computer rappresentato dalla variabile strComputer:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
È esattamente in questa fase che lo script potrebbe generare errori. Si supponga ad esempio che si verifichino problemi di rete, che il computer sia stato spento o che uno degli Scripting Guys non abbia collegato in modo corretto il lettore DVD e abbia provocato il black-out di tutta la zona occidentale degli Stati Uniti. Se si verifica una di queste situazioni, non si sarà più in grado ovviamente di stabilire una connessione al computer. Per questo motivo, occorre controllare immediatamente il valore dell'oggetto VBScript Err.
If Err = 0 Then
Se l'oggetto Err è uguale a 0, questo indica che è possibile connettersi al computer (e all'account Administrator) senza alcun problema. Se l'oggetto Err è uguale a un valore diverso da zero, questo significa una sola cosa: il tentativo di connessione non è riuscito. In tal caso, è inutile tentare di modificare la password su tale computer, in quanto ovviamente se non è possibile stabilire una connessione, non si sarà neppure in grado di modificare la password.
Supponendo che non si verifichi alcun problema e che non venga generato alcun errore, procederemo con l'esecuzione delle due righe di codice seguenti:
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
Nella riga 1, utilizziamo il metodo SetPassword per assegnare una nuova password all'account Administrator locale (egTY634!alK2). Sì, lo sappiamo: è opportuno non utilizzare il nome del proprio figlio come password. Nella riga 2, scriviamo la data e l'ora correnti (utilizzando la funzione VBScript Now) nella riga della cella i, colonna 2. Tenete presente che la colonna Password modificata viene aggiornata solo se si è in grado di connettersi al computer remoto e modificare la password. Se non si è in grado di connettersi a un computer, il campo Password modificata corrispondente non verrà mai aggiornato; solo in questo modo è possibile sapere quali operazioni sono riuscite e quali non sono state completate.
Che cosa significa tutto questo? Significa che, la prima volta che si esegue il ciclo, il foglio di calcolo sarà simile a quello riportato nella Figura 3.
Figura 3 Elenco di computer dopo la reimpostazione della prima password
Figura 3 Elenco di computer dopo la reimpostazione della prima password (Fare clic sull'immagine per ridurla)
Figura 3 Elenco di computer dopo la reimpostazione della prima password
Figura 3 Elenco di computer dopo la reimpostazione della prima password (Fare clic sull'immagine per ingrandirla)
A questo punto sono state completate le operazioni sul computer 1. Occorre eseguire solo alcune operazioni di ordinaria amministrazione prima di procedere:
Err.Clear
i = i + 1
Sebbene piuttosto brevi, queste due righe di codice sono molto importanti (naturalmente tutte le righe di codice scritte dagli Scripting Guys rivestono un'importanza cruciale). Nella prima riga l'oggetto Err viene reimpostato su 0. Se non si è verificato alcun errore, questa impostazione è ridondante, in quanto in questo caso Err è già uguale a 0. Se si è verificato un errore, l'oggetto Err sarà uguale a un valore diverso da 0. In tal caso, è di fondamentale importanza reimpostare manualmente l'oggetto Err. Perché? Perché si tratta dell'oggetto Error, ovvero un oggetto che tiene traccia solo degli errori, non tiene traccia delle operazioni riuscite. Si supponga ad esempio che si sia verificato un problema nel computer 1 e che non si sia in grado di stabilire una connessione. Si supponga inoltre che in seguito a questo errore l'oggetto Error sia stato impostato su 99.
Infine, si supponga che il ciclo prosegua e che si sia in grado di stabilire una connessione al computer 2. Quale sarà a questo punto il valore dell'oggetto Err? Esatto: l'oggetto Err sarà ancora impostato su 99. La ragione sta nel fatto che il valore dell'oggetto Err viene modificato solo quando si verifica un errore; in caso contrario, l'oggetto Err manterrà il valore corrente per un tempo illimitato.
Questo aspetto è importante? Dovrebbe esserlo. Dopo tutto, dal punto di vista tecnico, la password su un computer non viene modificata se si è in grado di stabilire una connessione; la password viene modificata solo se l'oggetto Err è uguale a 0. E, ovviamente, 99 non è uguale a 0 (fatta eccezione per le elezioni di famiglia dello Scripting Guy). È inoltre importante perché, anche se è stata stabilita la connessione al computer 2, l'oggetto Err non è uguale a 0 e, poiché Err non è diverso da 0, è inutile tentare di modificare la password di amministratore locale.
In altre parole, se il valore di Err viene modificato, sarà necessario reimpostare tale valore su 0; in caso contrario, da quel momento in poi lo script supporrà che si sia verificato un errore. Come reimpostare l'oggetto Err su 0? Esatto: è sufficiente chiamare Err.Clear.
In seguito, occorre incrementare il valore di i di 1. Perché? Alla prima esecuzione del ciclo, la variabile i era uguale a 2, in quanto il nostro scopo era connettersi al computer elencato nella riga 2, colonna 1. Alla seconda esecuzione del ciclo, l'obiettivo è connettersi al computer elencato nella riga 3, colonna 1. Essendo i la variabile che indica la riga che si intende utilizzare, è pertanto necessario impostare i su 3. E, se la matematica non è un'opinione, 2 + 1 = 3 (per fortuna che la Calcolatrice è sempre in esecuzione). A questo punto, proseguiremo con il ciclo e ripeteremo il processo per il successivo computer elencato nel foglio di calcolo.
Tutto ciò è estremamente interessante ma, dal momento che non siamo più così ingenui come in passato, siamo consapevoli del fatto che questo script da solo intaccherà solo in minima parte la tonnellate di messaggi ricevuti "Lo stratagemma di utilizzare il foglio di calcolo di Excel è molto interessante," molti utenti diranno, "ma ho comunque bisogno di modificare la password di amministratore locale per tutti i computer in un'unità organizzativa o per tutti i computer elencati in un file di testo". Qualcun altro potrebbe dire: "Desidero visualizzare un elenco di computer ed essere in grado di selezionarne uno dall'elenco". Qualcun altro ancora potrebbe obiettare: "Ciò che desidero veramente è ..."
Rilassatevi. Ogni vostro desiderio è un ordine per gli Scripting Guys (presupponendo che siate disposti ad attendere quattro anni prima che il vostro desiderio diventi realtà). Ebbene, nello Script Center sono pubblicati numerosi modelli di ambienti con numerosi computer, modelli che semplificano notevolmente l'esecuzione di uno script su più computer. Si supponga ad esempio che si desideri modificare la password di amministratore locale per tutti i computer all'interno di un'unità organizzativa. Nessun problema. Il modello per l'esecuzione di uno script su tutti i computer di un'unità organizzativa è simile a quello illustrato nella Figura 4.
Figure 4 Esecuzione di uno script in un'unità organizzativa (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
Fate riferimento alla sezione all'interno del modello relativa all'inserimento di codice. L'unica operazione da eseguire è eliminare il codice di esempio presente in questa sezione e sostituirlo con il codice (che è possibile copiare da questo articolo) per la modifica della password di amministratore locale. In altre parole, sostituire il codice di esempio con il codice seguente:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
Questo specifico codice di esempio non consente di registrare i risultati automaticamente, ma è possibile aggiungerlo manualmente con estrema semplicità. Sostituite il codice di esempio, modificate la stringa di connessione LDAP://OU=Finance,dc=fabrikam,dc=com in modo che faccia riferimento a una delle vostre unità organizzative e il gioco è fatto.
In verità, questi modelli sono stati pubblicati più di un anno fa pensando che sarebbero diventati uno degli elementi più utilizzati dello Script Center. Ci sbagliavamo: vengono utilizzati raramente, anche se ogni giorno riceviamo numerosi messaggi di posta elettronica in cui vengono richieste informazioni su come eseguire gli script su più computer. Partiamo quindi dal presupposto che nessuno era al corrente dell'esistenza di questi modelli. Ma adesso lo sapete. O almeno lo saprete se vi indico dove reperirli: microsoft.com/technet/scriptcenter/scripts/templates. Hmmm, ora si spiega perché nessuno ha mai utilizzato questi modelli...
A questo punto, è chiaro che gli Scripting Guys non sono più così ingenui come in passato. La logica conseguenza di questo ragionamento potrebbe essere che gli Scripting Guys non sono più così stupidi come in passato? Mettiamola in questo modo. Non molto tempo fa uno degli Scripting Guys decise di trascorrere il weekend a collegare una serie di dispositivi elettronici. Quando il lunedì è tornato al lavoro, aveva un pollice fratturato che non smetteva di sanguinare e un taglio profondo sulla gamba.
Ma, tutto sommato, non era poi così doloroso. Almeno non per uno Scripting Guy.

Gli Scripting Guys di Microsoftlavorano o, per meglio dire, sono stipendiati da Microsoft. Quando non si dedicano al baseball (o a varie altre attività) da giocatori, allenatori o semplici spettatori essi gestiscono il TechNet Script Center. Consultare la pagina www.scriptingguys.com.


 Controllo della protezione: Configurazione guidata della protezione
Controllo della protezione
Configurazione guidata della protezione
John Morello
Le informazioni contenute in questo articolo sono relative a una versione non definitiva di Windows Server "Longhorn" e sono soggette a modifica.

Garantire la protezione avanzata dei server in modo efficiente e coerente rappresenta una delle principali problematiche che la maggior parte delle organizzazioni IT deve affrontare, in particolare quelle con un numero elevato di computer distribuiti su numerosi confini geografici e organizzativi. Se la protezione avanzata di un singolo server può essere un'attività relativamente semplice per un amministratore esperto, la protezione avanzata di decine, centinaia o
persino migliaia di server può risultare un processo piuttosto difficoltoso. Nel corso degli anni, molte organizzazioni hanno sviluppato standard ed elenchi di controllo interni per la protezione dei server o hanno adottato le indicazioni fornite da Microsoft, dall'istituto NIST (National Institute of Standards and Technology) o da altre parti esterne. Sebbene possa risultare estremamente utile, questa documentazione da sola non è sufficiente a garantire la corretta implementazione da parte delle organizzazioni di tali procedure consigliate sulle rispettive reti. Numerose organizzazioni si sono pertanto trovate davanti alla necessità di decidere se adottare le impostazioni di installazione predefinite oppure investire una quantità significativa di tempo e risorse per creare script o criteri personalizzati per la protezione avanzata dei sistemi.
Grazie all'introduzione della Configurazione guidata impostazioni di sicurezza (SCW, Security Configuration Wizard) in Windows Server® 2003 Service Pack 1 (SP1), attualmente Microsoft fornisce un metodo semplice e supportato per la protezione avanzata dei server e la riduzione della relativa superficie di attacco in base ai ruoli svolti dai server. Combinando i vantaggi della Configurazione guidata impostazioni di sicurezza con le funzionalità di distribuzione e gestione centralizzate di Criteri di gruppo, la Configurazione guidata impostazioni di sicurezza garantisce le caratteristiche di scalabilità necessarie a soddisfare le esigenze delle organizzazioni IT di maggiori dimensioni. Nell'articolo di questo mese verrà illustrato il modo in cui le organizzazioni IT possono utilizzare la Configurazione guidata impostazioni di sicurezza e Criteri di gruppo per gestire i server in modo più sicuro e coerente, riducendo nel contempo i costi operativi e di distribuzione.

Introduzione a Configurazione guidata impostazioni di sicurezza
Configurazione guidata impostazioni di sicurezza è un componente facoltativo, installato tramite il pulsante del Pannello di controllo Installazione componenti di Windows®, disponibile in tutti i membri della famiglia di Windows Server 2003 SP1, compreso Windows Server 2003 R2. Un amministratore deve innanzitutto eseguire Configurazione guidata impostazioni di sicurezza su un server di destinazione per identificare i ruoli svolti da tale server. Configurazione guidata impostazioni di sicurezza guida quindi l'amministratore nel processo di creazione di un criterio di protezione, che consente di garantire la protezione avanzata del computer mediante uno schema basato sul principio dei privilegi minimi. In altri termini, Configurazione guidata impostazioni di sicurezza garantisce che siano disponibili solo i servizi, le funzionalità delle applicazioni e le porte necessari per il funzionamento dei ruoli specifici. Tutti gli elementi non necessari per i ruoli svolti dal server vengono disattivati. Questo approccio consente di ridurre la superficie di attacco del server di destinazione. L'esecuzione di servizi non necessari per il ruolo svolto dal server determina un incremento dell'esposizione del server ai rischi, senza ottenere alcun vantaggio in termini di capacità o funzionalità. La disattivazione di questi servizi consente di ridurre i livelli di rischio e di migliorare le prestazioni del server.
Sebbene Microsoft abbia introdotto notevoli miglioramenti in termini di protezione con Windows Server 2003, riducendo significativamente la superficie di attacco globale rispetto alle precedenti versioni di Windows Server, questo sistema operativo non è stato creato sulla base della stessa architettura strutturata in componenti di Windows Vista™ e della prossima versione di Windows Server, nome in codice "Longhorn". È possibile pertanto che in un'installazione predefinita di Windows Server 2003 siano attivati e vengano eseguiti servizi non necessari per tutte le configurazioni dei ruoli dei server. Il servizio Spooler di stampa, ad esempio, è attivato per impostazione predefinita ma non è necessario per un computer utilizzato solo come server di database.

Implementazione della protezione basata sui ruoli
Nel corso degli ultimi anni Microsoft ha rilasciato un'estesa documentazione incentrata sulla protezione, che consente agli amministratori di determinare quali servizi sono necessari nei diversi ruoli dei server e fornisce modelli predefiniti per i ruoli noti, come i server Web. Tuttavia, l'implementazione in ambienti di grandi dimensioni di indicazioni come quelle riportate nella Guida alla protezione di Windows Server 2003 può rivelarsi piuttosto difficoltosa, in particolare quando le applicazioni utilizzate in questi ambienti sono più complesse delle installazioni di base di IIS o SQL Server. La situazione viene ulteriormente complicata dalle innumerevoli applicazioni di terze parti utilizzate nelle organizzazioni, molte delle quali hanno dipendenze da più ruoli dei server e i cui requisiti di applicazione e servizio non sono sempre ben definiti.
Configurazione guidata impostazioni di sicurezza fa fronte a questi problemi incapsulando tutte le informazioni e le procedure consigliate relative alle dipendenze contenute nelle guide all'interno di una procedura guidata destinata agli amministratori. Se, ad esempio, un amministratore intende distribuire una nuova applicazione line-of-business (LOB) che richiede sia SQL Server™ che IIS, non dovrà più sprecare tempo prezioso per setacciare la Guida alla protezione e sviluppare un elenco di dipendenze personalizzate. Potrà invece installare l'applicazione sul server e avviare Configurazione guidata impostazioni di sicurezza. Configurazione guidata impostazioni di sicurezza è in grado di rilevare i servizi in esecuzione e presentare all'amministratore un elenco di ruoli da selezionare per il server. A seconda della selezione effettuata dall'amministratore, Configurazione guidata impostazioni di sicurezza genererà un criterio che consentirà di disattivare tutti i servizi non richiesti dalla matrice di dipendenze per i ruoli. Configurazione guidata impostazioni di sicurezza prevede inoltre opzioni per la protezione avanzata del Registro di sistema, il blocco delle comunicazioni di rete non necessarie e l'applicazione di un criterio di controllo efficace. Dopo aver eseguito Configurazione guidata impostazioni di sicurezza, l'amministratore può salvare il criterio di Configurazione guidata impostazioni di sicurezza come file XML e applicarlo a qualsiasi altro server che esegue la stessa applicazione LOB.
L'esecuzione di Configurazione guidata impostazioni di sicurezza offre quindi tre vantaggi significativi rispetto agli approcci tradizionali alla protezione di Windows Server. Innanzitutto, consente di ridurre notevolmente (se non di eliminare) la necessità di consultare di continuo la documentazione del prodotto per determinare i servizi e le impostazioni necessari per un determinato carico di lavoro. Queste informazioni sono incorporate in Configurazione guidata impostazioni di sicurezza e l'interfaccia basata su domande semplifica l'immissione da parte dell'amministratore dei dettagli necessari. Inoltre, Configurazione guidata impostazioni di sicurezza consolida le indicazioni per numerose aree, tra cui la protezione avanzata, la riduzione della superficie di attacco della di rete, la protezione avanzata dei servizi LDAP e SMB e il blocco di IIS. L'esecuzione di queste attività di configurazione richiedeva in precedenza l'utilizzo di utilità separate, a ciascuna delle quali erano associati una specifica interfaccia e un determinato approccio. Infine, poiché le impostazioni di Configurazione guidata impostazioni di sicurezza vengono conservate in un file di criteri XML, è possibile utilizzarla in scenari di tipo "create once, apply many" (creare una sola volta, applicare più volte). Indipendentemente dal numero di server che si distribuiscono per supportare una specifica applicazione LOB, è possibile applicare lo stesso criterio di Configurazione guidata impostazioni di sicurezza a tutti i server. Questa capacità garantisce una maggiore coerenza delle impostazioni di protezione, assicura la riduzione dei costi operativi e consente di semplificare il rollback dei criteri di Configurazione guidata impostazioni di sicurezza.

Componenti di Configurazione guidata impostazioni di sicurezza
Considerate tutte le funzionalità e i vantaggi che offre, Configurazione guidata impostazioni di sicurezza è in realtà uno strumento piuttosto semplice costituito da tre elementi principali: interfaccia della procedura guidata, interfaccia a riga di comando e database di configurazione della protezione (SCD, Security Configuration Database). Gli amministratori in aziende di piccole o medie dimensioni potrebbero avere l'esigenza di interagire solo con l'interfaccia della procedura guidata. In ambienti di maggiori dimensioni o più complessi, gli amministratori possono utilizzare l'interfaccia a riga di comando per automatizzare le attività di Configurazione guidata impostazioni di sicurezza, come la trasformazione di un criterio di Configurazione guidata impostazioni di sicurezza in un oggetto Criteri di gruppo. Solo gli amministratori avanzati che desiderano creare ruoli di Configurazione guidata impostazioni di sicurezza personalizzati modificheranno il database di configurazione della protezione.
L'interfaccia della procedura guidata, illustrata nella Figura 1, consente agli amministratori di creare, modificare, applicare ed eseguire il rollback delle impostazioni di protezione su un server di destinazione. In questa interfaccia le opzioni disponibili agli amministratori vengono presentate in un flusso di lavoro coerente, che prevede anzitutto l'analisi dei servizi e delle impostazioni, quindi della connettività di rete e dei criteri di controllo della protezione e, infine, delle impostazioni di IIS.
Figura 1 Interfaccia di Configurazione guidata impostazioni di sicurezza
Figura 1 Interfaccia di Configurazione guidata impostazioni di sicurezza (Fare clic sull'immagine per ridurla)
Figura 1 Interfaccia di Configurazione guidata impostazioni di sicurezza
Figura 1 Interfaccia di Configurazione guidata impostazioni di sicurezza (Fare clic sull'immagine per ingrandirla)
L'interfaccia a riga di comando di Configurazione guidata impostazioni di sicurezza fornisce tre funzioni di base. Consente agli amministratori di analizzare e configurare più server (in locale o in remoto) e di eseguire il rollback dei criteri. Consente di convertire automaticamente un criterio di Configurazione guidata impostazioni di sicurezza basato su XML in un oggetto Criteri di gruppo che può essere utilizzato in modo nativo negli strumenti di gestione standard degli oggetti Criteri di gruppo, come la console Gestione Criteri di gruppo. Infine, lo strumento a riga di comando di Configurazione guidata impostazioni di sicurezza illustrato nella Figura 2 viene utilizzato per registrare tutte le nuove estensioni del database di configurazione della protezione.
Figura 2 Strumento a riga di comando di Configurazione guidata impostazioni di sicurezza
Figura 2 Strumento a riga di comando di Configurazione guidata impostazioni di sicurezza (Fare clic sull'immagine per ridurla)
Figura 2 Strumento a riga di comando di Configurazione guidata impostazioni di sicurezza
Figura 2 Strumento a riga di comando di Configurazione guidata impostazioni di sicurezza (Fare clic sull'immagine per ingrandirla)
Il database di configurazione della protezione è semplicemente un insieme di file XML che descrivono in modo dettagliato gli specifici servizi e impostazioni, necessari per ciascun ruolo di Configurazione guidata impostazioni di sicurezza. Questi file sono nella directory %windir%\security\msscw\kbs. Per impostazione predefinita, Configurazione guidata impostazioni di sicurezza viene fornita con una serie di ruoli Windows Server di base e 12 ruoli applicazione predefiniti, tra cui: BizTalk®, Commerce Server, Exchange Server, Host Integration Server, Internet Security and Acceleration Server, Microsoft Identity Integration Server, Microsoft Operations Manager, Small Business Server, SharePoint® Portal Server, SharePoint Team Services, SQL Server e Systems Management Server. Ciascun ruolo dispone di un proprio file XML (vedere la Figura 3). Ogni volta che viene creata una nuova definizione di ruolo, il file XML corrispondente viene posizionato in questa directory. I file sono in formato XML standard e possono essere letti in qualsiasi visualizzatore di testo o altra applicazione che supporti il formato XML (vedere la Figura 4).
Figura 3 Ruoli predefiniti
Figura 3 Ruoli predefiniti (Fare clic sull'immagine per ridurla)
Figura 3 Ruoli predefiniti
Figura 3 Ruoli predefiniti (Fare clic sull'immagine per ingrandirla)
Figura 4 File di configurazione dei ruoli
Figura 4 File di configurazione dei ruoli (Fare clic sull'immagine per ridurla)
Figura 4 File di configurazione dei ruoli
Figura 4 File di configurazione dei ruoli (Fare clic sull'immagine per ingrandirla)

Combinazione di Configurazione guidata impostazioni di sicurezza e di Criteri di gruppo
Configurazione guidata impostazioni di sicurezza, utilizzata singolarmente, si è rivelata uno strumento straordinario, ma le sue reali potenzialità emergono completamente solo quando utilizzata in combinazione con Criteri di gruppo. A partire dal rilascio di Windows® 2000, i consigli di Microsoft per la protezione dei server di Windows si sono incentrati sull'utilizzo di Criteri di gruppo, al fine di garantire l'applicazione coerente, persistente e gestita centralmente dei criteri. Raggruppando i server in unità organizzative basate sui relativi ruoli, gli amministratori sono in grado di distribuire le configurazioni della protezione standard in tutta l'organizzazione piuttosto che a livello del singolo computer. Basandosi sulla logica dell'applicazione e sull'accumulo di Criteri di gruppo standard, le organizzazioni possono progettare una gerarchia di ruoli dei server a più livelli in cui un numero ridotto di criteri master è in grado di garantire la protezione di centinaia o migliaia di singoli server. Quando ruoli di server univoci richiedono una variazione rispetto ai criteri master, è possibile creare criteri differenziali basati sui ruoli di minori dimensioni al livello più prossimo ai server all'interno della gerarchia di unità organizzative. Questo consente di apportare modifiche di entità minima per attivare funzionalità specifiche dei ruoli senza duplicare tutti i criteri master, un approccio che offre alle organizzazioni di grandi dimensioni i vantaggi di un criterio gestito in modo centralizzato oltre alla flessibilità di adattarsi, quando necessario, ai requisiti di specifiche applicazioni.
Tuttavia, tradurre in realtà un approccio di questo tipo rappresenta una vera e propria sfida per le organizzazioni. Per le organizzazioni di grandi dimensioni con un'ampia gamma di applicazioni e ruoli di server, la creazione del gruppo appropriato di criteri risulta un'attività difficoltosa e dispendiosa in termini di tempo, almeno così era prima dell'introduzione di Configurazione guidata impostazioni di sicurezza. Utilizzando Configurazione guidata impostazioni di sicurezza per generare criteri e associando tali criteri all'unità organizzativa appropriata, è possibile ridurre il tempo necessario per distribuire la protezione basata sui ruoli e ospitata da directory sia per i carichi di lavoro esistenti che per quelli eventualmente impiegati in futuro. Per illustrare in maniera più efficace in che modo un'organizzazione potrebbe conseguire tale obiettivo, si esaminerà l'implementazione in un'azienda di grandi dimensioni di Configurazione guidata impostazioni di sicurezza e degli oggetti di Criteri di gruppo basati sui ruoli.

Implementazione di Configurazione guidata impostazioni di sicurezza nell'ambiente aziendale
Ai fini dell'esempio, verrà utilizzata la rete fittizia di Contoso. Contoso dispone di un'azienda IT di grandi dimensioni, complessa e distribuita su una vasta area geografica. Per ridurre i costi operativi e migliorare la protezione dei relativi server, Contoso segue le indicazioni di Microsoft per la creazione di una gerarchia di unità organizzative basata sui ruoli che separa e organizza i server in base al carico di lavoro. Per creare i criteri da associare a queste unità organizzative, Contoso utilizza Configurazione guidata impostazioni di sicurezza.
Poiché Configurazione guidata impostazioni di sicurezza non è installata per impostazione predefinita, Contoso deve specificamente attivare il componente Configurazione guidata impostazioni di sicurezza nella relativa immagine dell'installazione automatica. A tal fine, aggiunge una nuova riga, SCW=On, alla sezione [Componenti] del file Unattend.txt. Successivamente, durante il processo di installazione il componente Configurazione guidata impostazioni di sicurezza verrà automaticamente installato in tutti i nuovi sistemi creati con questa immagine. La semplice configurazione di Configurazione guidata impostazioni di sicurezza per l'installazione non comporta l'applicazione di alcun criterio ai computer durante il relativo processo di creazione.
Per applicare un criterio predefinito durante il processo di installazione, Contoso modifica la sezione [Comandi] del file cmdlines.txt nell'immagine per chiamare scwcmd con le opzioni seguenti:
scwcmd configure /p:ContosoBaselinePolicy.xml
È necessario che sia il file di testo che il file XML risiedano nella directory $OEM$ dell'immagine. Perché applicare un criterio di base in fase di creazione anziché utilizzare semplicemente il criterio associato all'unità organizzativa di primo livello all'interno della directory? Con l'applicazione di un criterio in fase di creazione, Contoso sarà in grado di assicurare un criterio di base coerente, indipendentemente dall'appartenenza di un computer a un dominio Active Directory®. Se, ad esempio, un server viene creato a scopo di testing, l'applicazione del criterio di base durante il processo di creazione garantisce che il criterio soddisfi almeno i criteri di protezione standard dell'organizzazione, anche se non è stato mai aggiunto all'ambiente Active Directory di produzione. Se il server viene in seguito aggiunto ad Active Directory, l'applicazione Criteri di gruppo e l'algoritmo di precedenza sostituiranno le impostazioni locali con quelle configurate a livello di dominio o unità organizzativa (l'ordine di precedenza per l'applicazione dei criteri è locale, sito, dominio, unità organizzativa).
Dopo l'installazione di Configurazione guidata impostazioni di sicurezza, Contoso può iniziare a creare il criterio di base. Il criterio di base viene in genere distribuito al livello superiore della gerarchia di unità organizzative per la protezione basata sui ruoli e rappresenta il criterio più restrittivo della gerarchia. Lo scopo consiste nel disporre di un'impostazione predefinita che garantisca il massimo livello di protezione e nel rendere disponibili solo i servizi e le porte per i singoli carichi di lavoro richiesti dai ruoli dei server. A tal fine, è consigliabile creare il criterio di base utilizzando un normale server, creato di recente, aggiungendo l'insieme di strumenti e utilità di gestione standard di Contoso ed eseguendo Configurazione guidata impostazioni di sicurezza su tale server. Una volta completata l'installazione di Windows di base, ad esempio, Contoso installa (manualmente o tramite il file cmdlines.txt) i relativi strumenti di monitoraggio, gestione backup e antivirus standard sul server. Poiché ciascuno di questi strumenti comporta la creazione dei rispettivi servizi Windows, la disponibilità degli strumenti sul server prima di creare il criterio di base consente a Configurazione guidata impostazioni di sicurezza di riconoscerli durante la fase di blocco dei servizi.
Una volta creato il server, Contoso esegue Configurazione guidata impostazioni di sicurezza. È possibile eseguire Configurazione guidata impostazioni di sicurezza in modalità locale o remota, da parte di un membro del gruppo Administrators locale sul computer. Se eseguita in remoto, la configurazione guidata delle impostazioni di sicurezza consente di specificare l'account utente con cui deve essere eseguita sull'host remoto. Se viene eseguita in locale, è possibile utilizzare runas.exe per ottenere lo stesso risultato. La prima attività eseguita da Configurazione guidata impostazioni di sicurezza prevede la valutazione dei servizi eseguiti sul computer locale e la visualizzazione dei ruoli già installati (vedere la Figura 5).
Figura 5 Selezione e visualizzazione dei ruoli del server
Figura 5 Selezione e visualizzazione dei ruoli del server (Fare clic sull'immagine per ridurla)
Figura 5 Selezione e visualizzazione dei ruoli del server
Figura 5 Selezione e visualizzazione dei ruoli del server (Fare clic sull'immagine per ingrandirla)
È consigliabile non selezionare alcun ruolo sul server di base di Contoso in quanto il computer è progettato per essere in uno stato caratterizzato da restrizioni elevate. Una volta selezionati i ruoli svolti dal server, la fase successiva prevede l'identificazione delle funzioni client necessarie in modo da attivare funzionalità come Aggiornamenti automatici, Active Directory o il client FTP. Per la maggior parte delle organizzazioni, l'accettazione delle impostazioni predefinite di Configurazione guidata impostazioni di sicurezza (come illustrato nella Figura 6) consente di utilizzare importanti funzionalità, come la capacità di far parte di un dominio, mentre impedisce l'impiego di funzionalità meno critiche, come il client FTP.
Figura 6 Funzionalità installate
Figura 6 Funzionalità installate (Fare clic sull'immagine per ridurla)
Figura 6 Funzionalità installate
Figura 6 Funzionalità installate (Fare clic sull'immagine per ingrandirla)
Configurazione guidata impostazioni di sicurezza consente quindi agli utenti di specificare quali strumenti amministrativi e servizi non predefiniti rendere disponibili per l'utilizzo. Le opzioni relative ai servizi non predefiniti consentono di specificare il motivo per cui eseguire Configurazione guidata impostazioni di sicurezza dopo l'installazione degli strumenti standard per la gestione dei server di Contoso. Dopo aver installato il programma antivirus, gli strumenti di backup e le applicazioni correlate, Configurazione guidata impostazioni di sicurezza sarà in grado di riconoscere tali servizi e pertanto includerli nelle impostazioni dei criteri.
L'ultima domanda nella sezione relativa alla protezione avanzata riguarda la modalità con cui gestire i servizi non specificati. I servizi non specificati sono i servizi che potrebbero essere installati in altri computer a cui viene applicato il criterio di Configurazione guidata impostazioni di sicurezza, anche se non vengono eseguiti sul computer su cui il criterio è stato originariamente creato. Se, ad esempio, il criterio di base viene applicato a un nuovo server con una nuova applicazione di terze parti, tutti i servizi installati da tale applicazione verranno gestiti in base alla scelta effettuata in questa fase dall'amministratore. Configurazione guidata impostazioni di sicurezza consente all'amministratore di scegliere di non modificare la modalità di avvio del servizio o di disattivare il servizio. Disattivato è l'opzione che garantisce il massimo livello di protezione, ma deve essere utilizzata con cautela in quanto non potranno essere eseguiti tutti i servizi dei quali non è esplicitamente consentita l'esecuzione. Questa opzione è più adatta ad ambienti ben gestiti e a protezione elevata. Per le altre parti di un'organizzazione, è consigliabile scegliere di non modificare la modalità di avvio. Questa è stata pertanto l'opzione scelta nell'esempio di Contoso. Prima di completare la fase delle attività di Configurazione guidata impostazioni di sicurezza, che prevede la protezione avanzata, viene visualizzato un report che informa l'amministratore dei servizi che verranno modificati.
Una volta completata questa fase, Configurazione guidata impostazioni di sicurezza fornisce le opzioni per la limitazione dell'accesso alla rete in ingresso. Analogamente all'elenco dei servizi richiesti per un determinato ruolo, viene incluso nel database XML di Configurazione guidata impostazioni di sicurezza anche l'elenco delle porte necessarie per uno specifico carico di lavoro.
Gli amministratori possono configurare porte aggiuntive in base alle esigenze e creare regole di porta per ogni servizio, come illustrato nella Figura 7. Per il server di base di Contoso, devono essere consentiti solo i servizi di base, come Desktop remoto. Tutte le altre eccezioni saranno configurate nei criteri basati sui ruoli al livello inferiore della gerarchia di unità organizzative.
Figura 7 Visualizzazione e utilizzo delle porte
Figura 7 Visualizzazione e utilizzo delle porte (Fare clic sull'immagine per ridurla)
Figura 7 Visualizzazione e utilizzo delle porte
Figura 7 Visualizzazione e utilizzo delle porte (Fare clic sull'immagine per ingrandirla)
Configurazione guidata impostazioni di sicurezza consente quindi all'amministratore di selezionare le opzioni del Registro di sistema, come la firma del traffico di file e di stampa. Ancora una volta, nella configurazione di base è consigliabile selezionare le impostazioni predefinite che definiscono il livello di protezione più elevato.
Il gruppo successivo di opzioni riguarda il criterio di controllo del sistema. Nella maggior parte dei sistemi, è consigliabile selezionare l'opzione Controlla operazioni riuscite, poiché il controllo di tutte le attività richiede l'utilizzo di un maggior numero di risorse del processore e determina la generazione di una quantità significativa di dati nel registro di controllo. Se si sospetta un attacco o è necessaria un'analisi più dettagliata, sarà possibile abilitare il controllo delle operazioni non riuscite sul computer specifico.
Infine, Configurazione guidata impostazioni di sicurezza presenterà all'amministratore le opzioni per la protezione avanzata di IIS. Queste opzioni sono simili a quelle disponibili nello strumento IIS Lockdown e sono ora integrate direttamente nei criteri di Configurazione guidata impostazioni di sicurezza.
Una volta completati tutti i passaggi, viene chiesto all'amministratore di salvare il file XML. Il file salvato deve essere convertito in un formato riconosciuto in modo nativo da Criteri di gruppo. Per convertire il file XML salvato in un oggetto Criteri di gruppo viene utilizzato il file scwcmd.exe. Ecco il comando da immettere:
scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy
Il criterio viene automaticamente creato in Active Directory e può essere associato al livello superiore della gerarchia di unità organizzative per la protezione avanzata basata sui ruoli di Contoso.
Una volta applicato il criterio al livello superiore della gerarchia, qualsiasi computer aggiunto alla gerarchia di unità organizzative erediterà le relative impostazioni. Quando viene aggiunto un computer che richiede la modifica di questo criterio, ad esempio un server IIS che richiede che sia in esecuzione il servizio W3SVC, gli amministratori di Contoso eseguono di nuovo Configurazione guidata impostazioni di sicurezza per il nuovo ruolo del server, convertono il nuovo criterio in un oggetto Criteri di gruppo e associano l'oggetto Criteri di gruppo a una nuova unità organizzativa secondaria che contiene il server. Poiché ha la precedenza l'oggetto Criteri di gruppo più vicino al server, il risultato finale sarà l'applicazione di tutte le impostazioni di base, eccetto quelle che richiedono l'implementazione di determinate modifiche per attivare la funzionalità del ruolo desiderata per la specifica unità organizzativa (vedere la Figura 8).
Figura 8 Applicazione di criteri nell'ambiente di Contoso
Figura 8 Applicazione di criteri nell'ambiente di Contoso (Fare clic sull'immagine per ridurla)
Figura 8 Applicazione di criteri nell'ambiente di Contoso
Figura 8 Applicazione di criteri nell'ambiente di Contoso (Fare clic sull'immagine per ingrandirla)
La potenzialità reale di questo approccio emerge con maggiore chiarezza nelle organizzazioni di grandi dimensioni o in caso di distribuzione di un numero elevato di server. Dopo aver creato il criterio iniziale di Configurazione guidata impostazioni di sicurezza e averlo associato a un'unità organizzativa, i server successivi dovranno essere semplicemente aggiunti a tale unità organizzativa in modo da ereditare automaticamente il criterio di protezione appropriato. Pertanto, dopo che il gruppo di criteri iniziale è stato creato e aggiunto ad Active Directory, la distribuzione di nuovi server o la sostituzione di quelli esistenti diventa un processo rapido e semplice.

Sviluppi futuri
Nella versione di Windows Server "Longhorn", il sistema operativo è stato completamente strutturato in componenti, determinando la riduzione della superficie di attacco. Anziché incentrarsi sul blocco dell'installazione predefinita minima, gli amministratori utilizzeranno lo strumento Server Manager per aggiungere i ruoli e i carichi di lavoro necessari su ciascun server. Server Manager funziona in modo molto simile a Configurazione guidata impostazioni di sicurezza, poiché dispone di un database di dipendenze interno che consente al programma di installazione di aggiungere solo le funzionalità necessarie per fornire il servizio di ruolo desiderato. Inoltre, la protezione basata sui ruoli e gestita a livello centrale mediante l'uso di Criteri di gruppo, come illustrato nel presente articolo, viene ulteriormente migliorata grazie al set notevolmente più esteso delle funzionalità controllate dagli oggetti Criteri di gruppo. In breve, Windows Server "Longhorn" migliora il concetto alla base di Configurazione guidata impostazioni di sicurezza grazie alla garanzia di una maggiore flessibilità e all'adozione di un approccio che mira ad aumentare le condizioni di sicurezza.
Risorse della Configurazione guidata impostazioni di sicurezza
Nelle pagine Web seguenti vengono fornite le informazioni necessarie per iniziare a utilizzare la Configurazione guidata impostazioni di sicurezza:
  • Documentazione della Configurazione guidata impostazioni di sicurezza
  • Configurazione guidata impostazioni di sicurezza per Windows Server 2003
  • Windows Server "Longhorn"

John Morello si è laureato con lode presso la LSU e lavora in Microsoft da sei anni ricoprendo diversi ruoli. Come consulente senior, ha progettato soluzioni di protezione per le aziende Fortune 100 nonché per i clienti della difesa e civili americani. Attualmente è Senior Program Manager presso il gruppo Windows Server e si dedica alle tecnologie di protezione e accesso remoto.


 Desktop file: Con sistemi x64
Desktop file
Con sistemi x64
Wes Miller

Windows XP è disponibile in modalità nativa per le architetture a 64 bit da oltre cinque anni. A meno di non essere tra i primi ad aver adottato il processore Itanium di Intel (Windows XP per Itanium è stato messo sul mercato lo stesso giorno di Windows XP), è probabile che se ne sia avuta notizia solo di recente con la disponibilità delle versioni di Windows XP e Windows
Server 2003 per i sistemi x64. x64, a volte definito anche x86-64, è il nome generico per le architetture AMD64 di AMD e EM64T di Intel. Se si è acquistato un computer nuovo nell'ultimo anno, è molto probabile che contenga un processore a 64 bit, anche se utilizzato solo a 32 bit (come nella stragrande maggioranza dei casi).
Oggi lavoro per una piccola azienda di Austin, in Texas. Data l'architettura di uno dei nostri prodotti, siamo interessati a sfruttare i vantaggi molto specifici offerti dall'architettura x64, come è già successo al team Microsoft ® Exchange 2007, che ha avviato una piccola rivoluzione iniziando a distribuire solo prodotti per l'architettura x64. Allo stesso modo il team di sviluppo e test che gestisco si è concentrato esclusivamente sulle versioni x64 di Windows® XP e Windows® Server 2003 per workstation di sviluppo, computer portatili, server e server di produzione. Inoltre, utilizzo Windows XP Professional x64 Edition sul mio computer portatile per sottoporre a test ed eseguire il debug del nostro prodotto.
È interessante che la prima risposta che ottengo dalla maggior parte delle persone quando accenno all'utilizzo di Windows a 64 bit, soprattutto su un sistema mobile, è uno sguardo piuttosto confuso. Se l'interlocutore conosce bene l'elaborazione a 64 bit, l'espressione riassume un'incredulità mista a nausea e sorpresa. Il motivo che sta alla base di queste reazioni, è la diffusa convinzione che sia molto difficile trovare tutti i driver di dispositivo necessari per i sistemi a 64 bit. In questo articolo spiegherò come e perché utilizzo Windows XP e Windows Server 2003 su sistemi x64 nella modalità a 64 bit e descriverò alcuni dei vantaggi (e dei possibili ostacoli) della distribuzione. Esaminerò anche gli aspetti del supporto, della migrazione e della distribuzione di Windows Vista™ x64.

Un po' di storia
Come già accennato, l'origine del supporto a 64 bit per Windows è iniziato con il supporto per il processore Itanium di Intel (sebbene fosse disponibile una versione per processori Alfa a 64 bit, Windows non era mai effettivamente a 64 bit quando eseguito su Alfa). In Windows XP e Windows Vista non è previsto alcun supporto per Itanium, quindi l'architettura x64 è attualmente il punto di riferimento per l'elaborazione dei client Windows a 64 bit. È disponibile una gamma più ampia di edizioni di Windows Server 2003 per x64 che per Itanium (che è stato sostanzialmente rilegato ai carichi di lavoro intensivi dei centri dati), una tendenza che probabilmente continuerà con la prossima versione di Windows Server, nome in codice "Longhorn".
Il supporto per Windows sulla piattaforma x64 è diventato disponibile con la pubblicazione di Windows Server 2003 Service Pack 1 (SP1). Sebbene potesse generare qualche confusione, questo momento coincide con la disponibilità della versione x64 di Windows XP, quindi con prodotti Windows XP a 32 bit e a 64 bit che derivavano da strutture di codice diverse all'interno di Windows. Mentre per i prodotti a 32 bit è disponibile un secondo service pack, per la versione a 64 bit di Windows XP tecnicamente parlando non esiste alcun service pack (anche se si potrebbe dire che integra già il SP1 per Windows Server 2003).
Per l'utilizzo di un qualsiasi Windows a 64 bit, ovvero Windows XP, Windows Server 2003, Windows Vista o Windows Server "Longhorn", i requisiti restano sempre gli stessi. È ovviamente necessario disporre di un processore a 64 bit. Nel caso di AMD significa aver acquistato un sistema single, dual o quad-core con compatibilità AMD64 (vedere amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html). Per Intel, significa aver acquistato un sistema single, dual o quad core con supporto per EM64T o architettura Intel 64 (vedere intel.com/technology/intel64). È importante sottolineare i dettagli. Un sistema Intel Core Duo, ad esempio, non è a 64 bit. Un sistema Intel Core 2 Duo è invece a 64 bit, ma è possibile che venga denominato semplicemente Centrino Duo (come nel caso del mio computer portatile).

Vivere con x64
Una volta determinato se il sistema supporta in modalità nativa una versione a di Windows 64 bit, è necessario occuparsi del supporto dei dispositivi. Purtroppo, per quanto Microsoft abbia sollecitato produttori e OEM (con almeno due anni di sessioni di WinHEC) a creare e certificare driver a 64 bit per i rispettivi dispositivi e sistemi, il problema maggiore da affrontare quando si decide di utilizzare un Windows x64 è il reperimento dei driver per l'hardware o il software. In base alla mia esperienza non esistono soverchie difficoltà nell'utilizzare un sistema operativo x64 su un server con un supporto di dispositivi limitato.
È invece più difficile trovare i driver per i sistemi desktop e portatili. In genere è più facile trovare tutto il necessario per i sistemi prodotti dai principali OEM del mercato o per un sistema creato con componenti di livello aziendale (poiché la probabilità che il sistema venga utilizzato in ambito aziendale spinge produttori o OEM a creare e firmare dei driver per x64).
Per Windows Vista, la situazione è molto migliore. In questo caso, a un mondo in cui x86 è l'architettura preferita mentre x64 è l'architettura ignorata, con driver a disponibilità limitata per la maggioranza dell'hardware, si contrappone il mondo del nuovo sistema operativo. Per Windows Vista, un produttore di dispositivi deve presentare i driver per x64 per ottenere una verifica di compatibilità. Non è infatti necessario includere i driver x86, sebbene sia ovviamente possibile. Teoricamente questo significa che alcuni dispositivi hardware, soprattutto i dispositivi che sfruttano le nuove funzionalità di Windows Vista, potrebbero supportare solo Windows x64 e non x86.
In realtà i driver sono solo uno dei problemi da affrontare quando si tenta di eseguire Windows a 64 bit in modalità nativa. Il problema maggiore consiste nel riuscire a implementare (o eseguire la migrazione verso) il nuovo sistema operativo, ma questo è un argomento che verrà affrontato in seguito.

Perché a 64 Bit?
AMD, Intel e Microsoft hanno deciso di passare a un'architettura a 64 bit a ragion veduta. Il passaggio ai 64 bit offre diversi vantaggi importanti. Come è possibile notare nella Figura 1, il miglioramento più importante garantito dall'architettura x64 è la capacità indirizzare molta più memoria: fino a 16 terabyte (TB) rispetto ai 4 GB di Windows a 32 bit. È importante sottolineare che, mentre i puntatori a 64 bit possono indirizzare fino a 16 TB, le applicazioni possono accedere solo a un massimo di circa 8 TB.
Figure 1 Limiti dello spazio degli indirizzi di memoria (Close Figure 1)

Spazio degli indirizzi | Windows a 64 bit | Windows a 32 bit
Memoria virtuale | 16 TB | 4 GB
File di paging | 512 TB | 16 TB
Pool di paging | 128 GB | 470 MB
Pool non di paging | 128 GB | 256 MB
Cache di sistema | 1 TB | 1 GB
Inoltre, le versioni x64 di Windows consentono di sfruttare anche la Protezione esecuzione programmi (DEP) basata sull'hardware, disponibile anche sui sistemi x86 con il supporto NX (No Execute). Si tratta di una soluzione basata sull'hardware utilizzata da Windows per evitare gli overflow del buffer impedendo l'esecuzione di codice dalle pagine di dati in memoria. Per ulteriori informazioni su quest'argomento, vedere support.microsoft.com/kb/875352.
Le versioni x64 di Windows prevedono il supporto nativo di CPU multiprocessore o multicore, proprio come le versioni x86 di Windows. Una delle maggiori complessità per la creazione di immagini di un sistema Windows XP viene però eliminata con l'utilizzo di un unico Hardware Abstraction Layer (HAL) per tutte le installazioni di Windows x64. Non è più necessario lottare per identificare l'HAL in uso nei sistemi non ACPI o a CPU singola.
Windows x64 come architettura consente di utilizzare l'infrastruttura di gestione esistente e il software a 32 bit già disponibile (tramite l'emulazione), oltre al software a 64 bit con la possibilità di accedere agli importanti miglioramenti illustrati in termini di memoria. In effetti, gli unici effetti collaterali spiacevoli del passaggio a Windows x64 sono: assenza completa di supporto per applicazioni a 16 bit (compresi i trucchi come le applicazioni a 32 bit con programmi di installazione a 16 bit); problemi con le applicazioni che non vengono eseguite in modo attendibile quando si attiva la DEP hardware (sebbene sia possibile disattivare DEP per singoli processi e il team di Windows Application Compatibility stia risolvendo i problemi di alcune applicazioni che non vengono eseguite correttamente con DEP attivata); infine, in Windows Vista a 64 bit, tutti i driver devono essere firmati.
Quest'ultima voce è stata aggiunta per migliorare la difesa contro la manomissione del kernel di Windows in memoria, una tecnica spesso utilizzata dai rootkit. Dal momento che, nelle intenzioni di Microsoft, x64 è l'architettura per cui i produttori devono sviluppare i driver per primi (per ottenere la certificazione di qualità dell'hardware di Windows), questo non è il requisito problematico che sarebbe stato in passato.
Quando si pensa a una migrazione a un sistema x64, è necessario prendere in considerazione un altro paio di punti. Non esistono versioni di Windows XP per sistemi x64 che contengano le funzionalità disponibili in Windows Media® Center Edition o Windows Tablet PC Edition. Tuttavia, questo non è vero per Windows Vista, dove le versioni x64 di Windows hanno le stesse funzionalità delle versioni x86.

Virtualizzazione
Una caratteristica non ancora menzionata è la virtualizzazione. Non mi riferisco ai prodotti di virtualizzazione come Microsoft Virtual PC o VMWare, ma alla virtualizzazione del sistema operativo per gli eseguibili a 32 bit. Nelle versioni a 32 bit di Windows le applicazioni a 16 bit venivano tutte eseguite nel contesto di NTVDM, una macchina virtuale MS-DOS®. Come già anticipato, nelle versioni a 64 bit di Windows non è previsto il supporto per applicazioni a 16 bit. Inoltre, mentre i componenti più integrati di Windows vengono eseguiti in modo nativo come binari 64 bit, alcuni componenti e molti programmi di terze parti vengono eseguiti come applicazioni a 32 bit.
Windows dispone di un livello di emulazione del tutto nuovo, denominato Windows On Windows (WOW), che consente di eseguire le applicazioni a 32 bit in una versione effettivamente a 32 bit di Windows. Sotto WOW, le applicazioni x86 vedono Programmi (x86) semplicemente come Programmi. Allo stesso modo, %WINDIR%\SysWOW64 viene rilevato dalle applicazioni x86 come %WINDIR%\System32. Le applicazioni x86 vedono la chiave del Registro di sistema HKLM\SOFTWARE\Wow6432Node come fosse il nodo HKLM\SOFTWARE.
Con lo strumento Process Explorer è possibile notare un'altra peculiarità della virtualizzazione. Poiché molte applicazioni a 32 bit sono progettate per interagire con i binari a 32 bit integrati in Windows, molti di tali binari sono disponibili in entrambe le versioni a 64 e 32 bit. È possibile notare questa specificità del nuovo sistema operativo aggiungendo una colonna in Process Explorer. Nella Figura 2 è possibile notare due istanze di cmd.exe, una versione a 32 bit e una a 64 bit. Inoltre, nell'istanza a 32 bit evidenziata, è possibile notare alcune DLL wow64* caricate nel processo a 32 bit. Queste dimostrano che è in corso una virtualizzazione, che consente alle applicazioni a 32 bit di funzionare sotto un sistema operativo Windows a 64 bit. Notare infine la directory di lavoro (percorso) utilizzata dalle versioni di cmd.exe a 64 e a 32 bit.
Figura 2 Process Explorer rivela le versioni a 32 bit e a 64 bit di cmd.exe
Figura 2 Process Explorer rivela le versioni a 32 bit e a 64 bit di cmd.exe (Fare clic sull'immagine per ridurla)
Figura 2 Process Explorer rivela le versioni a 32 bit e a 64 bit di cmd.exe
Figura 2 Process Explorer rivela le versioni a 32 bit e a 64 bit di cmd.exe (Fare clic sull'immagine per ingrandirla)
Una considerazione finale sull'argomento della virtualizzazione: Windows esegue explorer.exe come applicazione nativa a 64 bit e questa caratteristica propone vantaggi e svantaggi. Lo svantaggio principale consiste nella necessità di ricompilare le eventuali estensioni della shell di explorer.exe per l'architettura x64.
Per Internet Explorer®, che per impostazione predefinita viene eseguito in modo nativo con la versione a 32 bit, è vero il contrario. In tal modo si è voluto salvaguardare il corretto funzionamento dei tanti controlli Activex® già disponibili su Internet. In caso contrario, poiché le applicazioni a 64 bit non caricano DLL o driver a 32 bit, non vi sarebbe modo di caricare i controlli Activex a 32 bit, che comprendono quasi tutto i controlli Activex attualmente disponibili, in un browser a 64 bit, con il risultato che una buona parte del contenuto Internet resterebbe inaccessibile. Per un esempio pratico, provare a caricare C:\Programmi\Internet Explorer\iexplore.exe in un sistema Windows a 64 bit e visitare un qualunque sito che preveda il caricamento di un controllo Activex (anche Windows Update). Il risultato sarà un'operazione non riuscita a vari livelli. Windows Update (vedere la Figura 3) ora è stato aggiornato in modo da aprire un'istanza a 32 bit di Internet Explorer in questa situazione. In futuro, verrà di certo sviluppato del contenuto di controlli Activex aggiornati in modo da sfruttare i vantaggi offerti da Internet Explorer a 64 bit, ma con la maggioranza di sistemi Windows che oggi utilizzano esclusivamente Windows a 32 bit, non si sente la necessità di aggiornare i contenuti dei controlli Activex. È difficile immaginare che la situazione cambi in tempi brevi.
Figura 3 Operazioni non riuscite dei controlli Activex a 32 bit in Internet Explorer a 64 bit
Figura 3 Operazioni non riuscite dei controlli Activex a 32 bit in Internet Explorer a 64 bit (Fare clic sull'immagine per ridurla)
Figura 3 Operazioni non riuscite dei controlli Activex a 32 bit in Internet Explorer a 64 bit
Figura 3 Operazioni non riuscite dei controlli Activex a 32 bit in Internet Explorer a 64 bit (Fare clic sull'immagine per ingrandirla)

Windows x64 in Pluck
Ho anticipato all'inizio di questo articolo che in Pluck abbiamo iniziato la transizione a Windows x64. La transizione ha interessato tre versioni diverse di Windows: Windows XP Professional x64 Edition, Windows Server 2003 Enterprise Edition x64 e Windows Vista x64.
La nostra organizzazione è abbastanza piccola da sopportare l'improvvisa migrazione a Windows x64 non appena è iniziato lo sviluppo del nostro prodotto più recente, per approfittare dei vantaggi offerti dal sistema operativo. Per una migrazione corretta e completa, è stato necessario accertarsi che tutto il nuovo hardware ordinato fosse compatibile con l'architettura x64. Infatti, sono proprio le funzionalità espanse di gestione della di memoria dell'architettura x64 unite alla virtualizzazione che ci consente di eseguire il nostro prodotto nel modo desiderato. Tutti i server fisici vengono utilizzati come server a 64 bit virtuali su un server host a 64 bit. Ciascun server host dispone di 16 GB di RAM divisa tra i server virtuali ospitati (in genere 2 GB per ciascuna macchina virtuale o VM di gestione temporanea e 3 GB per ciascuna VM di produzione).
Con l'utilizzo di sistemi di livello 1 e di hardware virtualizzato, siamo in grado di ottenere un supporto dei dispositivi prossimo al 100%. Nel mio computer portatile, ad esempio, sono presenti tre periferiche che non dispongono di driver per x64. Sembra trattarsi di dispositivi di tipo backplane non critici e il sistema funziona bene anche senza. È interessante notare che un'installazione di Windows Vista RC1 x64 ha prodotto esattamente lo stesso supporto dei dispositivi. Mi aspetto tuttavia che arriveranno molto presto anche questi driver per il mio sistema con il logo Windows Vista Capable.
Poiché il nostro uso dei sistemi si limita principalmente a Microsoft Office, Visual Studio® e ad alcuni strumenti aggiuntivi utilizzati per i processi di sviluppo e generazione, non abbiamo molte applicazioni legacy che possano provocare problemi di compatibilità durante la migrazione. Mentre una parte importante della nostra organizzazione utilizza ancora versioni di Windows a 32 bit, abbiamo iniziato la migrazione a 64 bit con dell'hardware nuovo e il passaggio è stato relativamente indolore.

Distribuzione e migrazione verso x64
È necessario sottolineare alcuni aspetti relativi alla distribuzione. Microsoft fornisce una versione di Windows Preinstallation Environment (Windows PE) specifica per l'architettura x64. Tuttavia, poiché nei sistemi x64 persiste la parità x86, in alcuni casi è preferibile utilizzare la versione x86 di Windows PE per la distribuzione, specialmente se si utilizza una soluzione di imaging. Quando si distribuisce Windows XP utilizzando l'installazione automatica, è necessario che Windows PE sia specifico per l'architettura, come winnt32.exe deve essere eseguito sotto la medesima architettura oggetto della distribuzione. Poiché Windows PE non dispone di un livello di compatibilità a 32 bit e winnt32.exe sotto x64 è un'applicazione a 64 bit, per Windows a 32 bit è necessario utilizzare Windows PE a 32 bit. Lo stesso vale per le versioni a 64 bit di Windows, per le quali è necessario utilizzare Windows PE a 64 bit.
Da questo punto di vista Servizi di installazione remota (RIS) si comporta in modo diverso, ed è per questo che in Pluck utilizziamo RIS. RIS, a partire da Windows Server 2003 SP1, è in grado di distribuire architetture di Windows x64, x86 o Itanium. Quando un sistema x64 si connette a un server RIS, il server (nella configurazione predefinita) offre immagini RISetup o RIPrep x86 e x64. È possibile configurare RIS anche in modo da offrire ai client x64 solo immagini x86 o solo immagini x64. La scelta viene offerta come predefinita per garantire una migliore gestione con l'hardware x64.
Non si è ancora detto degli aggiornamenti e per una buona ragione. Purtroppo, l'aggiornamento di un intero sistema operativo da x86 a x64 è una vera impresa. Per questo motivo, e data la distribuzione limitata di Windows XP Pro x64 Edition, non è possibile eseguire l'aggiornamento a Windows XP x64 da una qualsiasi versione x86, né è possibile eseguire l'aggiornamento da una versione di Windows XP (x86 o x64) a Windows Vista x64. Windows Vista su sistemi x64 è concepito, come già in precedenza Windows XP Pro x64 Edition, come un prodotto per la sola installazione pulita. Per questo motivo, in molte organizzazioni la migrazione a x64 viene presa in considerazione solo quando è previsto un aggiornamento generale dell'hardware aziendale. Una strategia simile a quella che, si prevede, verrà adottata da molte organizzazioni per Windows Vista in generale (il doppio salto sembra quasi logico in questo caso).
Ma ciò non significa che le persone o le organizzazioni che intendono passare da un Windows x86 a un Windows x64 non possano disporre di strumenti facilmente reperibili. Le versioni di Utilità di migrazione stato utente (USMT) per Windows XP e per Windows Vista sono state entrambe estese per supportare la migrazione (rispetto a un aggiornamento in-band del sistema operativo) da un'installazione di Windows a un'altra. Questo è il metodo più utilizzato oggi nelle organizzazioni per distribuire Windows, anche su uno stesso computer, e l'utilizzo dello stesso meccanismo per passare a un Windows sotto un'architettura interamente nuova non dovrebbe presentare un più ostacoli di prima.

Conclusioni
Nonostante la migrazione graduale a x64 della nostra piccola organizzazione possa presentarsi decisamente più facile rispetto al complesso processo di migrazione delle organizzazioni più grandi, è opportuno che tutti i professionisti IT prendano in considerazione il passaggio all'architettura x64. La realtà è che, sebbene l'architettura x86 e le versioni native x86 di Windows resteranno in circolazione per i prossimi dieci anni, l'architettura x64 rappresenta certamente il futuro dell'informatica aziendale. Con il completamento del passaggio di Microsoft alle funzionalità dell'architettura x64 con Exchange Server e altri prodotti, si inizierà a capire quali sono i settori aziendali in cui l'architettura x64 si adatta meglio al preesistente. Sarà anche più facile decidere l'eventuale integrazione di questa migrazione con il passaggio a Windows Vista, indipendentemente dall'utilizzo corrente di Windows XP o Windows Server 2003 in modo nativo sui sistemi x64 esistenti.

Wes Miller è Development Manager presso Pluck (www.pluck.com) ad Austin, Texas. In precedenza ha lavorato a Winternals Software e a Microsoft in qualità di program manager e product manager per Windows. È possibile contattarlo all'indirizzo technet@getwired.com.


 Inside Microsoft.com: Come utilizzare Active Directory Federation Services
Inside Microsoft.com
Come utilizzare Active Directory Federation Services
Jim Guthrie

Qui alla Microsoft forniamo una Extranet per dare ai nostri partner commerciali l’accesso a importanti risorse interne. L'architettura della Extranet richiede che ogni partecipante esterno all'organizzazione abbia un unico account di dominio per questo spazio. Questo account viene creato e gestito dai dipendenti di Microsoft e non dai
partner, per ovvie ragioni. Tuttavia, durante il funzionamento, l'esperienza per l'utente può essere meno soddisfacente e la responsabilità di Microsoft di gestire tali partner richiede talvolta molte risorse.
Ecco come funziona la Extranet. Quando un cliente o un partner accede a un'applicazione, gli viene chiesto di inserire le proprie credenziali. Durante la stessa sessione, se tale utente decide di accedere a una risorsa diversa gli verranno ancora richieste le credenziali. Queste richieste continueranno ogni volta che l'utente passerà da una richiesta all’altra. Se l'utente si è autenticato in un'applicazione che utilizza risorse multiple, come un database finanziario, deve autenticarsi per ogni risorsa in modo indipendente. Questa esperienza può essere fastidiosa per gli utenti.
Fortunatamente, utilizzando Active Directory® Federation Services (ADFS), possiamo risolvere facilmente il problema delle autenticazioni multiple. ADFS è un componente di Windows Server® 2003 R2 che semplifica il trust tra due o più organizzazioni consentendo di condividere più risorse mantenendo nel contempo la capacità per ciascuna organizzazione di gestire i propri utenti. In quest'articolo, illustrerò come Microsoft progetta di utilizzare ADFS per risolvere tale problema, fornendo le informazioni necessarie per implementare una soluzione simile. Prima di entrare nei dettagli, tuttavia, occorre dare un'occhiata alla Figura 1 per familiarizzarsi con la terminologia fondamentale di ADFS.
Figure 1 Terminologia ADFS (Close Figure 1)

Termine | Definizione
Federazione | Alcune aree di autenticazione o di domini che hanno stabilito un trust di Active Directory.
Federation Service Resource (FS-R) | Indirizza la richiesta delle autenticazioni in entrata a FS-A e alle risorse desiderate.
Federation Service Accounts (FS-A) | Fornisce un token di account per l’autenticazione su FS-R.
Federation Service Proxy (FS-P) | Fornisce un livello di separazione dal traffico Internet in ingresso per i server FS.
Attestazione | Una dichiarazione effettuata da un server (ad esempio, il nome, l'identità, la chiave, il gruppo, il privilegio o la funzionalità) su un client.
Individuazione dell'area di autenticazione principale | Ogni FS-A dispone di un dominio o di un’area di autenticazione principale, in cui le credenziali di accesso vengono memorizzate. L'individuazione dell'area di autenticazione principale determina quale FS-A viene utilizzato per la sessione ADFS.

Una soluzione ADFS
Quando un utente tenta di accedere a un'applicazione in grado di riconoscere ADFS, il browser viene inviato alla Federation Service Resource (FS-R) per l’individuazione dell'area di autenticazione principale. Qui l'utente sceglierà quale set di credenziali utilizzare durante la sessione. A seconda dell’area di autenticazione principale scelta dal client, l'utente verrà reindirizzato al server di Federation Service Accounts (FS-A). È a questo server che riceverà un token di account valido (in un cookie) basato sulle credenziali nel modulo di Windows Live™ ID (noto in precedenza come Passport account), Windows Integrated Authentication o autenticazione SSL (vedere la Figura 2). In questo modello, è compito delle organizzazioni effettuare la manutenzione del proprio server di federazione degli account. Nel caso dei server partner di Microsoft, questa operazione elimina la responsabilità di Microsoft.com di gestire tutti gli account nell'ambiente. Naturalmente, se si implementa quel livello di responsabilità, è necessario scegliere attentamente le organizzazioni con cui ci si è federati ed è necessario assicurarsi che tali organizzazioni gestiscano attivamente le proprie informazioni di account.
Figura 2 Flusso ADFS
Figura 2 Flusso ADFS (Fare clic sull'immagine per ridurla)
Figura 2 Flusso ADFS
Figura 2 Flusso ADFS (Fare clic sull'immagine per ingrandirla)
La fase successiva consiste nel ritornare al server di FS-R per scambiare il token di account con un token di risorsa. Nella nostra configurazione, questo token contiene un elenco completo delle autorizzazioni concesse all’utente attraverso un processo di mapping delle attestazioni effettuato su FS-R. Ricevuto il token, l’utente ottiene la funzionalità Single Sign-On (SSO) sulle applicazioni in grado di riconoscere ADFS finché la sessione è aperta o fino a 24 ore per impostazione predefinita (questa finestra è configurabile). In tal modo si ottiene l’abilitazione SSO a queste applicazioni in grado di riconoscere ADFS, con un'esperienza utente più protetta ed efficiente. Per uno scenario completo del processo di autenticazione di ADFS, vedere l'articolo di Matt Steele dell’edizione di luglio 2006 di TechNet Magazine intitolato "Semplificare il Single Sign-On con ADFS".
Per mantenere la protezione delle risorse aziendali di Microsoft, abbiamo isolato il lato che accede a Internet dell'Extranet aziendale e di conseguenza ogni server dispone potenzialmente di due configurazioni. Consentiamo un trust unidirezionale da parte degli utenti aziendali interni e utilizziamo i server per fornire la protezione necessaria. Abbiamo anche un dominio separato per lo spazio Extranet nel quale forniamo agli utenti esterni l’accesso alle risorse necessarie.
Due aspetti principali che suscitavano molto interesse durante l'implementazione erano il bilanciamento del carico e le modifiche di file dei criteri ADFS. Il bilanciamento del carico era una sfida sia a livello globale che a livello locale. In fase iniziale, in produzione utilizzeremo il bilanciamento del carico globale dai nostri partner di Content Delivery Network (CDN) Akamai o Savvis per i cluster di server Web front-end in due regioni. Questa operazione assicurerà la disponibilità del sistema per gli utenti finali anche nell'eventualità, improbabile, che un paio di server regionali non siano in linea. Ciò viene realizzato mediante failover automatico basato sui servizi di controllo integrità del server forniti dai CDN. Inoltre, possiamo aggiungere facilmente altri cluster in futuro. Per realizzare un risparmio dei costi, le nostre distribuzioni di preproduzione hanno deciso di non utilizzare il servizio CDN.
A livello regionale abbiamo accoppiato i server per il failover locale mediante il clustering del bilanciamento del carico di rete (Network Load Balancing, NLB). Anche se non utilizziamo funzionalità speciali di bilanciamento del carico, come si potrebbe facilmente fare con l’hardware, utilizziamo NLB per ottenere una riduzione dei costi. Questa configurazione fornirà la stabilità per assicurare oltre il 99,9 percento di tempo di operatività in tutti gli ambienti supportati.
Un'altra sfida che abbiamo affrontato consisteva nell’assicurare che il file dei criteri ADFS, il backbone di ADFS, fosse correttamente distribuito ovunque nel nostro ambiente e che fossero replicate anche le modifiche al file. A questo scopo, sfruttiamo un'altra funzionalità incorporata di Windows Server 2003 R2, la Replica DFS (DFSR), un nuovo motore di replica multimaster basata sullo stato. Su ciascuno dei server back-end abbiamo attivato un'appartenenza al gruppo DFS-R con una replica full mesh di 24 ore. Ora, indipendentemente da dove avviene la modifica al file dei criteri, questo sarà distribuito a tutti i server. Finché controlliamo chi può modificare il file, abbiamo un servizio estremamente stabile e disponibile.
Nonostante abbiamo tentato di assicurare che tutte le modifiche siano effettuate attraverso lo snap-in ADFS, in pratica, abbiamo constatato che a volte è necessario aggiornare manualmente questo file. Durante l’aggiornamento manuale è importante ricordare che ADFS rileva la versione di questo file. Quindi è necessario incrementare il file in modo che le modifiche vengano applicate nell'ambiente:
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
È necessario inoltre ricordare che, come tutto XML, il file XML dei criteri rileva la distinzione tra maiuscole e minuscole. In tutto il file XML dei criteri esistono molti riferimenti alle applicazioni o ad altri server ADFS e in tutti i casi essi devono essere copiati verbatim da un server all’altro. Si notino gli esempi seguenti dove il primo, RevocationCheckFlags, è stato inserito manualmente e il secondo è un URL di applicazione attendibile modificato dall'interfaccia utente:
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
Per un livello di protezione aggiuntivo utilizziamo un altro componente di ADFS, Federation Service Proxy (FS-P), che assicura che i FS-R non possano accedere direttamente dalle richieste Internet in entrata. Abbiamo implementato i proxy in Microsoft.com attraverso l'uso di un singolo set di proxy per ospitare diversi ambienti ADFS nella nostra area di preproduzione. Durante l’organizzazione iniziale della tecnologia abbiamo scoperto che era necessario apportare una semplice modifica alla chiave del Registro di sistema per realizzare questa operazione. La chiave si trova in HKLM\Software\Microsoft\WebSSO. Modificando semplicemente il valore della directory iniziale in questa chiave è possibile utilizzare il proxy per diversi ambienti. Il valore predefinito era:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
Per passare da un ambiente all'altro la chiave deve essere modificata nel modo seguente:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
La creazione di un file batch può semplificare la gestione di questo processo. Sfortunatamente la versione attuale dello snap-in di MMC per ADFS non supporta il passaggio da un ambiente all'altro poiché esiste un rapporto uno a uno tra il proxy e il server di risorsa o di account. Questo è l'unico modo per ottimizzare l'utilizzo dei server proxy. Il risultato finale è una notevole riduzione dei costi poiché viene limitato il numero dei server fisici indipendentemente da quanti ambienti si sceglie di ospitare.
Da un punto di vista dell'architettura eseguiamo il nostro ambiente di preproduzione con computer virtuali, il che contribuisce alla riduzione dei costi. In tal modo si elimina la necessità di acquistare e dover sistemare sei server aggiuntivi. Fino ad oggi non abbiamo avuto problemi di prestazioni. Tuttavia, per rispondere alla richiesta notevolmente aumentata nell'ambiente di produzione, abbiamo deciso di utilizzare computer fisici con prestazioni superiori.

Non solo per Active Directory
Non solo Microsoft.com utilizza gli account di Active Directory per l'autenticazione, ma abbiamo anche integrato con successo gli account ID di Windows Live. Abbiamo scoperto che, grazie a Windows Live ID (WLID) 4.5, possiamo utilizzare un account di Windows Live ID di un singolo utente per delegare l’accesso alle risorse di Microsoft utilizzando una trasformazione di attestazioni personalizzata. Ciò rappresenta una notevole vittoria per il raggiungimento dell'autenticazione SSO poiché non richiediamo più un account di dominio specifico.

Le sfide che rimangono da affrontare
La maggiore sfida che stiamo affrontando è la gestione di ADFS per condividere i certificati per la firma di token. Utilizziamo certificati standard che rimangono validi solitamente per un anno prima di richiedere il rinnovo. Al momento del rinnovo ogni server avrà bisogno di essere conseguentemente aggiornato, il che avrà un impatto significativo sugli FS-R. Mentre ora è possibile trattare con 15 o 20 federazioni, vorremmo arrivare a gestirne almeno centinaia se non migliaia. Questo richiederebbe l'impiego di personale a tempo pieno per la gestione dei certificati SSL per ogni singolo ambiente. Abbiamo diversi team che stanno cercando i metodi migliori per automatizzare questa soluzione, ma non hanno deciso quale linea di condotta seguire.
Un’altra sfida da affrontare è il fatto che non tutte le applicazioni sono in grado di riconoscere ADFS. Per far sì che i siti sfruttino l'opportunità di ADFS, sono necessarie altre operazioni di programmazione. Lavoriamo a stretto contatto con il team di Microsoft® Office SharePoint® Services per assicurarci che la prossima generazione di SharePoint sia in grado di supportare le nostre esigenze di implementazione per ADFS.

Conclusioni
Esistono numerosi fattori da considerare quando si decide di passare a un modello ADFS. Uno di questi è il numero dei clienti di risorse che vi accederà. Il processo di impostare un trust tra le organizzazioni può essere un compito banale, ma scrivere, riesaminare ed eseguire criteri di accesso accettabili richiede tempo e impegno. Quindi, se si ha una sola risorsa alla quale i propri clienti accederanno, si dovrà decidere se ne vale la pena. Poiché il numero di risorse cresce, i benefici aumentano.
Per ulteriori informazioni, vedere Panoramica di ADFS e Active Directory Federation Services: verso un'identità federata e la gestione degli accessi.

Jim Guthriecollabora con Microsoft nel team operativo di Microsoft.com e, oltre a lavorare con ADFS, è un ingegnere di sistemi nel team di supporto per le piattaforme dei portali aziendali.


 Taccuino: Le gioie (e i dolori) dell'apprendimento
Taccuino
Le gioie (e i dolori) dell'apprendimento
Mark D. Scott

Ricordo come mi sentivo quando veniva lanciato un nuovo prodotto, l'emozione di essere il primo a mettere le mani sull'ultima tecnologia, la curiosità di scoprirne le funzionalità man mano che lo utilizzavo. Sono sempre stato tra i primi a sperimentare nuovi prodotti, quello che sapeva il fatto suo, l'unico a cui gli altri si rivolgevano per scoprire i segreti di cui ero a conoscenza.
Purtroppo, col passare del tempo, la gioia è diminuita. Non sono sicuro di cosa le sia successo. Forse si è appannata per via della frustrazione di non riuscire a far funzionare le applicazioni critiche alle 3.00 di notte. Oppure l'ho lasciata insieme alla documentazione del prodotto che sono riuscito a leggere a tratti perché il server di posta aziendale si arrestava (ai tempi in cui un server era sufficiente). Forse sto solo diventando vecchio e cinico. Non importa. Non mi entusiasmo più a lavorare fino a tarda notte come facevo dieci anni fa. Ma non significa che è giusto smettere di imparare cose nuove. E lo pensavo già da tempo.
Sono passato di recente a Microsoft® Outlook® 2007 e mi piace davvero. Ma sono anche abbonato a MSN® Premium; il mio ISP mi fornisce la sottoscrizione come parte del servizio. Nella versione precedente di Outlook avevo bisogno di un software speciale chiamato connettore per accedere al mio indirizzo di posta elettronica MSN. Questo connettore software non funzionava con Outlook 2007, dunque ho contattato MSN. Mi hanno detto di contattare il mio ISP, il quale ha detto, alla fine, che non supportava il connettore Outlook MSN in Outlook 2007. Prova e riprova, usando la posta elettronica, le chat e i messaggi vocali, alla fine sono riuscito a ottenere queste informazioni.
Poi ha funzionato, forse non avevo più bisogno di un connettore. Ho avviato Outlook 2007 e ho configurato una connessione nuova a MSN senza utilizzare il connettore software. Outlook ha trovato il server in Internet e ha configurato l'account senza nessuna difficoltà. L'ha fatto anche per altri account del mio POP3. Quindi, ho ottenuto l'accesso alla mia posta elettronica e ho imparato una nuova e grande funzionalità del prodotto.
Ecco la morale della storia. Se qualche addetto al supporto si fosse disturbato a collaudare il nuovo prodotto, probabilmente avrebbe potuto dirmi che non avevo bisogno del connettore e avrebbe risparmiato a entrambi parecchio tempo.
Più precisamente, se avessi collaudato prima il prodotto, avrei trovato probabilmente da solo la soluzione. Invece ho voluto che qualcuno mi desse la risposta. E poiché nessuno aveva avuto il tempo di esplorare qualcosa che era, del resto, importante per le nostre vite, entrambi avremmo perso meno tempo se avessimo fatto delle ricerche e risolto il problema da soli, esattamente quello che ho fatto alla fine.
Le evoluzioni tecnologiche prevalgono sulle nostre supposizioni. In qualità di professionisti IT, abbiamo bisogno di tenere lontano idee preconcette. Il sapere più difficile da conquistare è quello che verrà sostituito inevitabilmente dalla nuova tecnologia. È l'evoluzione del sapere che ci consente di utilizzare la tecnologia. Non possiamo utilizzare questo sapere arcano come nostro margine competitivo per sempre. Il margine reale non sta nelle informazioni ormai obsolete sul funzionamento della tecnologia, ma piuttosto nella capacità di approfondire nuovi concetti e tecniche. Imparando continuamente, facendo dell'apprendimento una parte essenziale della nostra vita, affiniamo le nostre abilità. Con la vasta gamma di prodotti nuovi che vengono presentati continuamente, l'apprendimento deve rimanere il nostro stile di vita.
Contattami tramite posta elettronica al mio account Microsoft o al mio account MSN, posso scaricare la posta da entrambi in Outlook 2007.

Mark D. Scott è un consulente senior per Microsoft Consulting Services. Lavora con i client per semplificare la progettazione e la creazione di applicazioni su larga scala mirate ai dati. È possibile contattare Mark all'indirizzo granddaddy2002@msn.com oppure mascott@microsoft.com.


 Windows Confidential: Il potere dei bug
Windows Confidential
Il potere dei bug
Raymond Chen

In Windows 95 , era possibile accedere alla pagina Risoluzione dei problemi e scegliere Disattiva il buffer sincrono. Ma che cosa succede dopo averla selezionata? E perché?
Il comportamento normale della funzione Commit di MS-DOS® era quello di cancellare tutti i dati non scritti per un determinato file sul disco e aspettare finché i dati non venivano confermati come scritti prima restituirli. Attivando l'opzione Disattiva il buffer sincrono, la chiamata verrebbe restituita subito piuttosto che aspettare la scrittura dei dati. Si trattava, certamente, di una violazione della specifica funzionale, in base alla quale la chiamata non doveva essere restituita finché i dati non venivano scritti. Di conseguenza aumentava il rischio di ciò che l'articolo 139669 della Knowledge Base definisce, in modo eufemistico, "problemi di integrità del file" poiché il programma che emetteva la richiesta di cancellazione presupponeva che i dati fossero al sicuro sul disco quando non lo erano.
È possibile che un programma di database utilizzi la funzione Commit per stabilire i punti in cui lo stato del file sul disco corrisponde a quanto il programma prevede sia presente sul disco. Se, durante un aggiornamento, viene a mancare l'alimentazione, il programma di database è in grado di utilizzare le informazioni registrate nell'ultimo punto di commit per ristabilire l'integrità del database. Se veniva restituito un risultato subito prima del termine del commit, questo punto di controllo di integrità veniva perso. Come conseguenza il database risultava danneggiato.
Perché quest'opzione era disponibile se le conseguenze erano così terribili? La causa: un bug in Windows® 3.11.
Figura 1 Abilitare il comportamento anomalo in Windows Server 2003
Figura 1 Abilitare il comportamento anomalo in Windows Server 2003 (Fare clic sull'immagine per ridurla)
Figura 1 Abilitare il comportamento anomalo in Windows Server 2003
Figura 1 Abilitare il comportamento anomalo in Windows Server 2003 (Fare clic sull'immagine per ingrandirla)
Windows 3.11 ha introdotto "l'acceso al file a 32 bit", un'implementazione a 32 bit dell'interfaccia I/O del file di livello inferiore. Ma l'implementazione della funzione Commit conteneva un bug che ignorava le richieste di cancellazione dei buffer di file. Se si utilizzava un programma che cancellava i buffer di file e lo si eseguiva in Windows 3.11, la chiamata di cancellazione non aveva effetto. Di conseguenza, se l'alimentazione mancava al momento sbagliato, il database risultava danneggiato.
Il team che si occupava del file system di Windows 95 ha corretto questo bug ma allo stesso tempo sono aumentate le segnalazioni di nuovi bug. Un sistema di contabilità fornitori ha iniziato a funzionare molto lentamente. Poi un altro programma di database ha subito forti rallentamenti. Cos'era successo?
Si è scoperto che questi programmi emettevano costantemente chiamate di cancellazione. I programmatori hanno notato che le chiamate di cancellazione erano veloci in Windows 3.11, quindi le hanno inserite in tutto il programma. Scrivere un byte, cancellare. Scrivere una stringa, cancellare. Poiché i flussi erano così veloci, l'applicazione avrebbe potuto eseguire il commit dei dati sul disco dopo ogni operazione senza alcun effetto negativo sulle prestazioni. Ma una volta corretto il bug in Windows 95, l'esecuzione di questi programmi è diventata molto lenta a causa delle chiamate di Commit.
Certamente, se il team di file system non avesse fatto niente, questi programmi avrebbero continuato ad essere eseguiti lentamente e gli utenti sarebbero arrivati alla conclusione che la causa del problema risiedeva in Windows 95. "Windows 95 è lentissimo", avrebbero detto. D'altra parte, se il file system fosse ritornato al vecchio comportamento di Windows 3.11, sarebbe stato reintrodotto un bug che avrebbe portato a quei noiosi "problemi di integrità dei file".
Quindi si è giunti alla conclusione che la soluzione era di lasciare la correzione del bug e aggiungere una casella di controllo, nascosta nella pagina della Risoluzione problemi, per consentire il ritorno al comportamento di Windows 3.11 a coloro che eseguivano programmi in cui si verificavano problemi dovuti al bug da correggere.
E la storia si ripete. In Windows Server® 2003, il team di I/O ha trovato un bug che causava la perdita del tag FUA per le richieste contrassegnate come Forced Unit Access (FUA) e la conseguente esecuzione di tali richieste come normale I/O. Era la versione moderna della soluzione che in passato consisteva nell'ignorare le richieste di cancellazione. Il bug è stato corretto ma è sempre disponibile un'opzione per ritornare al vecchio comportamento anomalo. La versione di Windows Server 2003 di questa casella di controllo è denominata "Abilita prestazioni avanzate" ma adesso si sa che non significa altro che "Ripristina il vecchio comportamento anomalo".

Raymond Chen Sempre la stessa storia e il libro dall'omonimo titolo (Addison-Wesley, 2007) illustrano la storia di Windows e la programmazione in Win32. Raymond Chen non offre alcuna soluzione.