 TechNet Magazine November 2007

TechNet Magazine November 2007

Amministrazione di Windows: Modifiche ai file non in linea in Windows Vista

È orami un problema comune capire come è possibile consentire agli utenti di lavorare con i file archiviati in rete se la connettività è assente o non affidabile, evitando allo stesso tempo problemi di controllo delle versioni. La continuità è essenziale per garantire un'esperienza senza problemi. Ecco come i miglioramenti di Windows Vista assicurano un approccio più efficiente e affidabile al lavoro con i file non in linea.

Jeremy Moskowitz Distribuzione desktop: Distribuzione semplice e scalabile con BDD 2007

Se non si dispone di SMS 2003, non è il caso di preoccuparsi: esiste un'altra soluzione per creare semplici distribuzioni desktop. Di seguito viene fornita una guida approfondita su come utilizzare BDD 2007 e SQL Server per creare distribuzioni scalabili che richiedano un input manuale minimo o inesistente.

Adam Shepherd Comunicazioni: Server Trasporto Edge di Microsoft Exchange Parte 2

I server Trasporto Edge di Exchange possono aiutare a creare un ambiente di messaggistica più affidabile e protetto. Nella Parte 1 è stato illustrato come configurare questi server, mentre qui verranno forniti alcuni esempi dettagliati dei miglioramenti che le funzionalità principali introducono nell'ambiente di messaggistica.

Kay Unkroth Rete: Configurazione dell'accesso remoto VPN con ISA Server 2006

Una rete privata virtuale può fornire una migliore connettività e una maggiore produttività, senza dover essere necessariamente difficile da implementare e gestire. In questo articolo viene illustrato come utilizzare ISA Server 2006 per gestire nel modo più efficace due scenari VPN comuni.

Alan Maddison SQL Server: Ottimizzazione delle prestazioni delle query in SQL Server

Quando si ottimizzano le prestazioni dei database, l'ottimizzazione delle singole query è importante quanto quella delle configurazioni hardware e software del server. Anche una query runaway può ridurre in ginocchio un database. Qui viene fornita una guida alla generazione, all'analisi e alla regolazione dei piani di esecuzione per ottimizzare le prestazioni delle query di SQL Server.

Maciej Pilecki Dal redattore: Più energia per te

Joshua Hoffman Casella degli strumenti: Nuovi prodotti per professionisti IT

Greg Steen Exchange Queue & A: Protezione dei protocolli di posta elettronica, posta indesiderata misteriosa e altro

Nel numero di questo mese, il team di Exchange prende in esame il protocollo Transport Layer Security per SMTP e illustra come impedire che rapporti NDR falsificati intasino le code e come affrontare alcune problematiche correlate all'installazione.

Nino Bilic and Scott Landry Utilità in primo piano: Cmdlet SMS per Windows PowerShell

In questo articolo viene illustrato come iniziare a utilizzare i cmdlet di Windows PowerShell per gestire i client di SMS 2003 dalla riga di comando.

Don Brown The Cable Guy: Single Sign-On wireless

Single Sign-On offre molti vantaggi sia agli utenti finali che agli amministratori. In questo articolo viene illustrato rapidamente come Single Sign-On può semplificare l'implementazione dell'autenticazione wireless per la rete.

Joseph Davies Note di ricerca: Utilizzo del calcolo ad alte prestazioni nella lotta contro l'HIV

In questo articolo viene illustrato come il team eScience presso Microsoft Research collabora con i ricercatori medici e utilizza il calcolo ad alte prestazioni per aiutare a scoprire una cura per l'HIV.

Kristin Firth and Mia Matusow Windows PowerShell: Scrittura di espressioni regolari

Con un'espressione regolare ben scritta, uno script di Windows PowerShell è in grado di determinare se il formato dei dati specificati è valido. In questo articolo viene fornita una panoramica sulle modalità di utilizzo delle espressioni regolari in Windows PowerShell.

Don Jones Hey, Scripting Guy!: Gestione desktop dall'aldilà

Gli Scripting Guy dimostrano come utilizzare Gestione Remota Windows per recuperare le proprietà e le istanze di classi su un computer remoto. Oh, e c'è anche un bel puzzle!

The Microsoft Scripting Guys Controllo della protezione: Protezione dell'accesso da postazioni remote

In questa sede vengono fornite considerazioni sulla progettazione della protezione e della rete per una soluzione di accesso da postazioni remote utilizzando componenti dei Servizi terminal e vengono illustrati alcuni metodi pratici e procedure consigliate per creare una soluzione in Windows Server 2008.

John Morello Desktop file: La verità sulla deframmentazione

I miti sugli inconvenienti della deframmentazione hanno impedito a molti amministratori di eseguire importanti attività di manutenzione. Questo articolo illustra quali sono i problemi reali, quali quelli improbabili e come evitarli.

Wes Miller Taccuino: Il dentice di condotta

Quando i membri di una community iniziano ad agire, forse avrebbero bisogno solo di un grande pesce. È sufficiente vedere come l'ingegneria sociale abbia aiutato a salvare Live QnA.

Betsy Aoki Windows Confidential: Il paradosso del file system

Come mai è necessario un driver del file system in miniatura integrato nei file di avvio critici?

Raymond Chen


 Amministrazione di Windows: Modifiche ai file non in linea in Windows Vista
Amministrazione di Windows Jeremy Moskowitz

Modifiche ai file non in linea in Windows Vista
Panoramica:
  • Continuità operativa in linea e non in linea
  • Disponibilità dei file
  • Evoluzione delle cartelle non in linea

Uno dei problemi più complessi nella gestione del desktop è consentire agli utenti non in linea di lavorare come se fossero in linea. Questa esigenza è più diffusa di quanto si possa pensare, a causa del crescente utilizzo di dispositivi portatili negli ultimi anni. Anche se esistono diverse situazioni in cui può essere necessario lavorare
non in linea, i tre casi più comuni sono i seguenti: quando l'utente disconnette il computer portatile dalla rete dell'ufficio per lavorare mentre è in viaggio, quando si connette tramite un collegamento lento o intermittente e quando in una succursale si perde la connessione alla sede principale.
In queste circostanze, come è possibile conservare una copia di un file sul computer non in linea mentre l'originale si trova sul server principale? In particolare, come è possibile gestire un conflitto se qualcuno nella sede principale modifica il file sul server e un altro utente lo modifica mentre è in viaggio? Fortunatamente, questi problemi vengono gestiti dal motore File non in linea, incorporato in Windows® 2000, Windows XP e Windows Vista®.

La soluzione a questo problema è la memorizzazione nella cache
Il motore File non in linea è un computer di notevoli dimensioni utilizzato per la memorizzazione nella cache. Per questo motivo, all'interno del sistema (e presso Microsoft), viene definito come cache sul lato client. Il motore File non in linea è configurabile e sufficientemente flessibile per consentire agli utenti di decidere quali elementi memorizzare nella cache, nonché di impostare l'esecuzione della procedura nel sistema. Consente di accedere agli stessi file non in linea come se fossero in linea, senza dover modificare lo spazio dei nomi. In altri termini, l'accesso ai file viene eseguito utilizzando lo stesso percorso UNC o la stessa lettera di unità sia in modalità in linea che non in linea.
È possibile configurare i file da memorizzare nella cache in modo manuale o automatico. Se si è certi di utilizzare spesso determinati file o cartelle quando si è in viaggio, è possibile indicare semplicemente cosa si desidera utilizzare in modalità non in linea. A questo scopo, in Windows XP è sufficiente fare clic con il pulsante destro del mouse su un file archiviato localmente o su una condivisione di rete e selezionare l'opzione per impostare la disponibilità non in linea del file (vedere la Figura 1). In Windows Vista, questa opzione è denominata Sempre disponibile/i non in linea. L'operazione che consente di rendere manualmente disponibile un file non in linea viene talvolta denominata blocco di un file.
Figura 1 Disponibilità di un file non in linea
Figura 1 Disponibilità di un file non in linea
Figura 1a La cartella File non in linea
Figura 1a La cartella File non in linea
La condivisione in uso può essere connessa tramite un percorso UNC o una lettera di unità. In pratica, non è necessario che il file sia archiviato in un computer su cui è in esecuzione Windows Server®. Il file può risiedere in qualsiasi posizione che fornisca il protocollo SMB (Server Message Block), ad esempio un server Samba o un dispositivo NAS (con alcune eccezioni) compatibile con il protocollo SMB.
La prima volta che si decide di bloccare un file, in Windows XP viene illustrata una serie di schermate di una procedura guidata in cui viene richiesto quando effettuare la sincronizzazione. Se si continua a fare clic su Avanti e si accettano le impostazioni predefinite, la sincronizzazione verrà effettuata a ogni connessione o disconnessione e anche in background in caso di inattività. Al termine della procedura guidata, verrà visualizzata un'icona modificata indicante che il file è disponibile non in linea.
Dopo la disconnessione dalla rete, tutti gli altri file sulla condivisione non saranno più disponibili, eccetto quelli selezionati per l'utilizzo non in linea. Talvolta ciò causa dei problemi: l'icona indica i file che sono sempre disponibili non in linea, tuttavia non è chiaro, prima di eseguire la disconnessione, che alcuni file non saranno disponibili. Questo aspetto verrà approfondito più avanti in questo articolo.
Rendere disponibili i file non in linea manualmente presenta determinati vantaggi, tuttavia a volte può essere utile eseguire questa operazione in modo automatico. Tale scenario verrà esaminato in seguito, utilizzando ciò che è comunemente definita cache automatica.

Vantaggi della memorizzazione automatica nella cache rispetto alla memorizzazione manuale nella cache
La memorizzazione automatica nella cache viene configurata sul server in base a ogni condivisione. Pertanto, se si dispone di una condivisione denominata Sales e si desidera che gli addetti alle vendite possano accedere ai propri file mentre sono in viaggio, è possibile impostare il motore CSC a tal fine. Nella Figura 2 viene illustrata la finestra di dialogo Impostazioni modalità non in linea, che viene visualizzata quando si seleziona la scheda Cache in Windows Server 2003. La descrizione delle impostazioni viene illustrata nella Figura 3.
Figure 3 Impostazioni della memorizzazione automatica nella cache (Close Figure 3)

Impostazione | Descrizione
Solo i file e i programmi specificati dall'utente saranno disponibili in modalità non in linea. | Consente agli utenti di specificare manualmente i file che saranno disponibili in modalità non in linea. È l'impostazione predefinita.
Tutti i file e i programmi della condivisione aperti dall'utente saranno automaticamente disponibili in modalità non in linea. | Consente di effettuare la memorizzazione automatica nella cache di tutti i file e programmi aperti da Esplora risorse. L'impostazione Ottimizza prestazioni viene utilizzata per memorizzare nella cache i programmi, anziché i documenti, tuttavia, in genere non incide sulle prestazioni e nella maggior parte dei casi può essere ignorata. In Windows Vista, ad esempio, viene completamente ignorata.
File o programmi della condivisione non saranno disponibili in modalità non in linea. | Se utilizzata in un client Windows 2000, Windows XP o Windows Vista, questa impostazione consente di bloccare l'accesso dell'utente all'elemento Disponibile in modalità non in linea.
Figura 2 Finestra di dialogo Impostazioni modalità non in linea in Windows Server 2003
Figura 2 Finestra di dialogo Impostazioni modalità non in linea in Windows Server 2003
Per verificare il funzionamento della memorizzazione automatica nella automatica, si supponga di disporre di una condivisione Sales che contiene 10 file, da Sales01.txt a Sales10.txt, e che sia stata abilitata l'impostazione "Tutti i file e i programmi della condivisione aperti dall'utente saranno automaticamente disponibili in modalità non in linea". I risultati non saranno subito evidenti, poiché all'utente non verrà segnalato che altri file sono diventati improvvisamente disponibili in modalità non in linea. Inoltre, solo i file che vengono aperti in Windows (e quindi memorizzati nella cache) sono disponibili per il successivo utilizzo in modalità non in linea. In breve, è necessario aprire i file in linea che si desidera utilizzare in modalità non in linea prima di disconnettersi dalla rete. In caso contrario, non saranno disponibili in seguito.
Inoltre, i file memorizzati automaticamente nella cache non verranno conservati permanentemente nella cache. In Windows XP e Windows Vista, tale spazio temporaneo viene gestito in modo leggermente diverso, ma l'aspetto fondamentale consiste nel fatto che i file possono essere rimossi per problemi di spazio. I file vengono conservati nella cache in base a criteri di utilizzo. Se non sono stati aperti per un determinato intervallo di tempo, questi file verranno rimossi per liberare spazio e consentire l'apertura di altri file. Pertanto, è estremamente probabile che i file aperti di recente siano ancora nella cache, tuttavia, se è stata impostata la memorizzazione automatica nella cache, la disponibilità dei file non sarà garantita. Per assicurarsi che un file sia disponibile, è necessario bloccarlo. In quanto amministratore, è possibile utilizzare anche Criteri di gruppo per bloccare i file con l'impostazione File non in linea assegnati dall'amministratore.
Esaminiamo ora un esempio di utilizzo reale. Si supponga che un utente di Windows XP denominato EastSalesUser1 abbia aperto il file Sales05.txt e che un utente di Windows Vista denominato EastSalesUser2 abbia aperto il file Sales05.txt sulla condivisione \\server\sales.
Poiché è stata impostata la memorizzazione automatica nella cache sulla condivisione Sales, alla disconnessione dell'utente EastSalesUser1 (in Windows XP) e dell'utente EastSalesUser2 (in Windows Vista), tali file potranno ancora essere utilizzati. In Windows, ne viene infatti archiviata una copia nella cache File non in linea. I file che non sono ancora stati utilizzati dagli utenti
vengono invece gestiti in modo diverso da Windows XP e Windows Vista, come illustrato nella Figura 4 e nella Figura 5. In Windows XP non vengono indicati i file che non sono stati memorizzati nella cache, pertanto quando si effettua la disconnessione, tali file vengono semplicemente rimossi. In Windows Vista, al contrario, vengono utilizzate immagini sovrapposte alle icone e i file che non sono stati memorizzati nella cache vengono contrassegnati da una piccola X in grigio. Ciò rappresenta un notevole passo avanti per la segnalazione dei file disponibili in modalità non in linea. L'unico problema consiste nel fatto che tale indicazione viene fornita solo dopo aver effettuato la disconnessione e non durante una sessione in linea. La possibilità di rendere più esplicito lo stato di un file sarebbe quindi una funzionalità estremamente utile.
Figura 4 In Windows XP vengono indicati solo i file disponibili dopo la disconnessione
Figura 4 In Windows XP vengono indicati solo i file disponibili dopo la disconnessione
Figura 5 In Windows Vista vengono indicati anche i file non disponibili quando si è disconnessi
Figura 5 In Windows Vista vengono indicati anche i file non disponibili quando si è disconnessi

Identificazione dei file disponibili
Alcuni amministratori hanno qualche esitazione per quanto riguarda l'utilizzo dei file in modalità non in linea, proprio perché risulta difficile identificare con esattezza i file effettivamente disponibili. Nella Figura 5, l'icona verde a forma di cerchio sul file sales01.txt indica che il file è disponibile in modalità non in linea (come quando viene bloccato).
Tuttavia, come illustrato in precedenza, il file Sales05.txt, che sia in Windows XP che in Windows Vista viene reso disponibile in modalità non in linea tramite la cache automatica, non sarà necessariamente disponibile in modalità non in linea. Occorre tenere presente che solo i file che sono stati aperti saranno disponibili in modalità non in linea. Per risolvere il problema, il sistema dovrebbe fornire una distinzione tra file temporaneamente o potenzialmente disponibili non in linea. Poiché non viene applicata una distinzione tra le icone, l'individuazione dei file disponibili o meno in modalità non in linea può creare confusione. In questo senso, è migliore l'interfaccia utente di Windows Vista, anche se l'individuazione di tali file non è molto intuitiva. In Windows Vista, le informazioni relative alla disponibilità vengono fornite da una proprietà di Esplora risorse, denominata Disponibilità non in linea e visualizzata nel riquadro di anteprima quando viene selezionato un elemento. Se l'elemento è bloccato, il valore della proprietà sarà "Sempre disponibile". Se invece non è bloccato ma è memorizzato nella cache, il valore sarà "Disponibile".
Il concetto di file temporaneamente disponibili in modalità non in linea è comune sia a Windows XP che a Windows Vista, ma le implementazioni sono leggermente diverse. Nella Figura 6 viene illustrata la gestione dei file non in linea in Windows XP e in Windows Vista.
Figura 6 Aree destinate ai file non in linea in Windows XP e in Windows Vista
Figura 6 Aree destinate ai file non in linea in Windows XP e in Windows Vista
In breve, sia in Windows XP che in Windows Vista è presente un'area specifica per i file non in linea, tuttavia i file sempre disponibili e quelli temporaneamente disponibili in modalità non in linea vengono archiviati in modo leggermente diverso nei due sistemi operativi.
In Windows XP, i file che sono sempre disponibili non in linea (contrassegnati dall'icona modificata come illustrato nella Figura 1) vengono conservati permanentemente nella relativa posizione. Se vengono bloccati 10 GB di file manualmente, tali file saranno sempre disponibili in modalità non in linea. È possibile bloccare un numero illimitato di file (oltre i limiti di dimensione massima delle partizioni). Tuttavia, in Windows XP è presente un limite massimo di 2 GB per i file memorizzati automaticamente nella cache. L'idea di base è che solo i file aperti regolarmente vengono archiviati in tale posizione, mentre quelli inutilizzati per un determinato intervallo di tempo, se necessario, vengono rimossi. Per impostazione predefinita, per la cache dei file temporaneamente disponibili viene allocato il 10% dello spazio libero su disco rigido, come illustrato nella Figura 7. Questa impostazione è disponibile solo per gli amministratori di Windows XP.
Figura 7 Impostazione dello spazio su disco per i file non in linea in Windows XP
Figura 7 Impostazione dello spazio su disco per i file non in linea in Windows XP
Anche in Windows Vista è possibile archiviare i file in modo permanente o temporaneo. Tuttavia, diversamente da Windows XP, la cache dei file temporanei fa parte della cache globale. Per impostazione predefinita, le dimensioni della cache globale, che include sia i file temporaneamente disponibili che quelli sempre disponibili in modalità non in linea, è limitata al 25% dello spazio libero su disco rigido. Il motivo per cui è stata apportata questa modifica è che in Windows XP era possibile continuare a memorizzare manualmente i file nella cache (fino a decine di GB) ed esaurire lo spazio disponibile su disco rigido. Grazie al nuovo schema, invece, l'amministratore può allocare una quantità specifica di spazio per la cache globale in modo da evitare questo problema. Come illustrato nella Figura 8, il 25% dello spazio libero su disco è indicato, in un modo che confonde, come il 15,2% dell'intera unità. Il secondo dispositivo di scorrimento, relativo allo spazio disponibile per i file temporaneamente non in linea, non può mai essere impostato su un valore superiore a quello del primo dispositivo di scorrimento, che determina la quantità massima di spazio per tutti i file non in linea. Per accedere ai dispositivi di scorrimento relativi ai limiti di utilizzo del disco per i file non in linea, è sufficiente fare clic sull'opzione Cambia limiti. Tuttavia, per modificare le impostazioni, è necessario disporre delle credenziali di amministratore.
Figura 8 Spazio disponibile per i file non in linea in Windows Vista
Figura 8 Spazio disponibile per i file non in linea in Windows Vista

Procedura per impedire un'eccessiva memorizzazione nella cache
La funzionalità di Windows "Reindirizzamento cartelle" garantisce che determinate cartelle importanti, che in genere si trovano sul computer locale, vengano effettivamente archiviate sui server. L'idea di base è che, in caso di malfunzionamento del computer locale, è disponibile una copia dei file importanti su una condivisione di rete.
Si supponga, ad esempio, che sia stata reindirizzata una cartella Documenti (in Windows XP o in Windows Vista). In questo caso, analogamente a qualsiasi reindirizzamento di cartelle, il sistema operativo presuppone che si desideri accedere a tali file in modalità non in linea, pertanto, a ogni file contenuto in una cartella reindirizzata verrà applicato il simbolo illustrato nella Figura 1. Lo svantaggio è che, se si dispone di un'ottima connettività di rete e si esegue il roaming in un nuovo computer, verranno memorizzati tutti i contenuti della cartella reindirizzata nella cache del nuovo computer, anche se si prevede di utilizzarlo per un'unica sessione. Ciò rappresenta non solo uno spreco di spazio ma anche un rischio per la protezione, se la situazione non viene gestita in modo appropriato.
Un altro caso in cui i file vengono memorizzati automaticamente nella cache si verifica quando si utilizza Esplora risorse per accedere ai file di una condivisione. Ad esempio, se per esaminare un gruppo di file grafici su una condivisione di rete viene utilizzato Esplora risorse e se è impostata la cache automatica, è molto probabile che tali file vengano automaticamente scaricati e memorizzati nella cache. Ciò è dovuto al fatto che l'apertura di un file tramite Esplora risorse richiede circa lo stesso intervallo di tempo necessario per inserirlo nella cache dei file temporaneamente disponibili in modalità non in linea. I file che risiedono sulla condivisione vengono spesso aperti per ottenere metadati quali le dimensioni dei file o l'anteprima di un'immagine. Se si dispone di un'ottima connettività di rete e di un collegamento rapido, l'operazione è semplice. In Windows è possibile memorizzare i file nella cache in modo rapido e semplice per consentirne il successivo utilizzo. Tuttavia, se si è connessi alla condivisine di rete con la cache automatica su un collegamento lento, è possibile che si verifichino notevoli ritardi. La situazione è praticamente identica sia se si utilizza Esplora risorse in Windows XP o Windows Vista. La novità positiva di Windows Vista riguarda la possibilità di impostare, nel motore di memorizzazione nella cache dei file non in linea, il riconoscimento dei collegamenti lenti.

File non in linea e Criteri di gruppo
Principali modifiche al servizio File non in linea di Windows Vista
I membri del team addetto al servizio File non in linea avrebbero voluto illustrare le modifiche apportate, ma nel presente articolo non è possibile analizzarle tutte. Di seguito, vengono riportate solo le modifiche principali:
  1. Transizioni ottimali tra modalità in linea e non in linea che consentono alle transizioni di non essere più bloccate dagli handle aperti.
  2. Granularità della modalità non in linea per file che consente che una singola condivisione non in linea non comporti la disconnessione dell'intero server.
  3. Imposizione della modalità non in linea tramite un pulsante In linea o Non in linea in Esplora risorse.
  4. Crittografia per utente dei contenuti memorizzati nella cache.
  5. Nuovo motore di sincronizzazione più rapido nell'individuazione e nell'analisi delle modifiche.
  6. Integrazione con il servizio Ricerca di Windows per l'indicizzazione delle cartelle reindirizzate.
  7. Sincronizzazione da locale a remoto che consente di sfruttare la funzionalità di trasferimento bitmap differenziale.
  8. Risoluzione dei conflitti differita tramite Centro sincronizzazione.
  9. Eliminazione delle aree commenti per le notifiche.
  10. Nuova API COM completa e il supporto di Strumentazione gestione Windows (WMI) per le attività di gestione (informazioni dettagliate su MSDN® all'indirizzo msdn2.microsoft.com/bb530662).
  11. Supporto per gli script tramite un provider WMI (informazioni dettagliate disponibili a breve su MSDN).
  12. Nuove proprietà degli elementi della shell: Stato non in linea e Disponibilità non in linea.
  13. Ghosting per rappresentare elementi dello spazio dei nomi non disponibili quando si è disconnessi. In Esplora risorse, questi elementi vengono visualizzati in grigio con un'immagine sovrapposta all'icona X, in modo da evitare modifiche eccessive della visualizzazione delle cartelle nella shell durante la transizione dalla modalità in linea a quella non in linea.
  14. Nuova applet Pannello di controllo.
Per ulteriori informazioni, è possibile consultare il mio libro e la documentazione Microsoft.

Come illustrato in precedenza, quando un file viene aperto da un utente (o da Esplora risorse), l'intero file viene memorizzato nella cache, anche se si tratta di un documento Word o Visio® da 80 MB. Sia Windows XP che Windows Vista sono in grado di identificare un collegamento lento. Per impostazione predefinita, in Windows XP viene considerato lento un collegamento da 64 kbps. Se la velocità di connessione è superiore e il client è Windows XP, il file viene comunque scaricato in fase di accesso utilizzando la pipeline lenta. Pertanto, è consigliabile configurare Windows per ottimizzare la gestione delle attività nel caso in cui il collegamento sia lento. Come indicato di seguito, è possibile eseguire questa operazione tramite Criteri di gruppo, creando un oggetto Criteri di gruppo da collegare a un'unità organizzativa contenente gli account di destinazione: Windows XP o Windows Vista.
Quando l'utente si connette utilizzando un collegamento lento, Windows XP tenta di utilizzare i file memorizzati localmente nella cache prima di utilizzare la copia di rete. Questo è chiaro, ma Windows XP effettua anche la seguente operazione: scarica file di grandi dimensioni non ancora memorizzati nella cache se vengono aperti dalla rete o da Esplora risorse. Inoltre, in base ai test effettuati, se la sincronizzazione è pianificata per essere eseguita in fase di disconnessione (impostazione predefinita), i file rimanenti verranno scaricati tramite il collegamento lento e quindi memorizzati nella cache.
Il comportamento di Windows Vista è diverso, poiché un collegamento non viene identificato come lento per impostazione predefinita. Di fatto, anche i collegamenti estremamente lenti vengono considerati da Windows Vista in modo analogo a connessioni rapide e viene utilizzata la copia dei file disponibile sulla rete. Tuttavia, è possibile impostare Windows Vista per il riconoscimento delle condivisioni a cui si desidera eseguire la transizione quando il collegamento è lento. In tali scenari, i risultati sono migliori. In base al comportamento di Windows Vista configurato tramite Criteri di gruppo, i contenuti delle condivisioni per cui è stato definito un collegamento lento non verranno resi disponibili su tale collegamento utilizzando le normali operazioni di file e di Esplora risorse.
Se la connessione è lenta, la sincronizzazione in background tramite il servizio File non in linea non verrà effettuata. Tuttavia, è possibile eseguire la sincronizzazione manuale tramite Centro sincronizzazione.
Inoltre, è possibile configurare la gestione dei collegamenti lenti in Windows Vista tramite un'impostazione di Criteri di gruppo, Configura modalità di collegamento ridotta, da non confondersi con l'impostazione dal nome simile in Windows XP, ovvero Configura velocità di collegamento ridotta. L'impostazione Configura modalità di collegamento ridotta accetta i seguenti valori: i nomi di server e condivisioni di cui si desidera effettuare automaticamente la transizione alla modalità non in linea quando la connessione è lenta e il limite minimo di velocità della connessione in base al quale la combinazione server\share verrà disconnessa. È possibile specificare qualsiasi combinazione \\server\share oppure un singolo asterisco (*) per indicare tutte le condivisioni su tutti i server. La seconda serie di valori è una dichiarazione della velocità effettiva (in kbps) e della latenza (in millisecondi) superata la quale la connessione verrà dichiarata lenta. Ciononostante, l'elemento più utile della coppia (ovvero la velocità effettiva) non viene verificato durante il download dei file. Pertanto, se una cartella Documenti reindirizzata contiene 10 GB di file e si dispone di un collegamento lento su un computer portatile in cui non sono ancora stati memorizzati tali file, il download richiederà parecchio tempo. Tuttavia, se si integra la verifica della velocità effettiva con quella della latenza e quest'ultima risulta inferiore al valore specificato, verrà effettuata la transizione della condivisione alla modalità non in linea, risparmiando all'utente una lunga attesa.
L'aggiornamento rapido di Windows Vista illustrato nell'articolo della Knowledge Base 934202 (una modifica che verrà introdotta con Windows Vista Service Pack 1) dovrebbe ottimizzare le prestazioni nel caso di connessioni VPN lente. L'articolo è disponibile in linea all'indirizzo support.microsoft.com/kb/934202. Questo aggiornamento rapido dovrebbe attivare la verifica della velocità effettiva nel caso di download effettuati su collegamenti lenti.

Conflitti di sincronizzazione
Se un file viene modificato in modalità non in linea, ad esempio da un utente che è in viaggio, e allo stesso tempo viene modificato da un altro utente in modalità in linea tramite la connessione dell'ufficio, la situazione viene gestita a livello di client. Quando si effettua una transizione dalla modalità non in linea a quella in linea, in Windows Vista verrà eseguita immediatamente la sincronizzazione in background dei file non in linea. Quindi verrà richiesto come procedere, tramite una voce nel Centro sincronizzazione dopo che è stata visualizzata un'icona nell'area di notifica sulla barra delle applicazioni. L'interfaccia utente è stata riprogettata per indicare se un file è più recente rispetto a un altro e per fornire ulteriori informazioni sul conflitto. È possibile conservare i file che causano conflitti, scegliendo di rinominare quelli momentaneamente disponibili solo sul computer quando vengono salvati sul server, come illustrato nella Figura 9.
Figura 9 Notifica dei conflitti di file in Windows Vista
Figura 9 Notifica dei conflitti di file in Windows Vista

Ulteriori informazioni
Il servizio File non in linea è estremamente utile sia per gli amministratori che per gli utenti e, se si utilizza la funzione Reindirizzamento cartelle, è nel proprio interesse apprenderne il funzionamento. In questo articolo sono state illustrate solo alcune delle numerose modifiche apportate al servizio File non in linea in Windows Vista. Per informazioni più dettagliate, è possibile consultare l'intestazione laterale "Principali modifiche al servizio File non in linea di Windows Vista".
Ulteriori informazioni sul servizio File non in linea sono disponibili in linea all'indirizzo go.microsoft.com/fwlink/?LinkId=98141 per Windows XP e all'indirizzo go.microsoft.com/fwlink/?LinkId=98138 per Windows Vista.
Un'ampia sezione del mio libro è dedicata al servizio File non in linea e sono spiegati tutti i pro e i contro delle impostazioni dei Criteri di gruppo (vedere la biografia in fondo all'articolo). Infine, per ulteriori informazioni e per confrontare con altri utenti le proprie esperienze con il servizio File non in linea, si consiglia di consultare il forum della community dedicato a questo argomento, disponibile sul sito GPanswers.com.

Jeremy MoskowitzMCSE e MVP per Criteri di gruppo, gestisce GPanswers.com, il forum della community su Criteri di gruppo. Tiene anche una serie di workshop di formazione intensiva su Criteri di gruppo. Il suo ultimo libro è Group Policy: Management, Troubleshooting, and Security (Sybex, 2007). Per ulteriori informazioni, è possibile contattare Jeremy all'indirizzo www.GPanswers.com.
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 Distribuzione desktop: Distribuzione semplice e scalabile con BDD 2007
Distribuzione desktop Adam Shepherd

Distribuzione semplice e scalabile con BDD 2007
Panoramica:
  • Funzionalità di base di BDD 2007
  • Integrazione con SQL Server
  • Creazione di una soluzione di distribuzione scalabile

La maggior parte delle persone coinvolte nella distribuzione di Windows ha sentito parlare di Microsoft Solution Accelerator for Business Desktop Deployment, anche noto come BDD. Si tratta di un insieme di procedure consigliate e di
strumenti sviluppati per semplificare la distribuzione di Windows® sui desktop client. In Windows Vista® è incluso BDD 2007, un aggiornamento di Microsoft Solution Accelerator che contiene una nuova versione di Microsoft® Management Console (MMC) e un sequencer delle attività basato su System Center Configuration Manager 2007, il successore di Systems Management Server (SMS) 2003.
Una delle funzionalità meno conosciute di BDD 2007 è la capacità di funzionare come una soluzione di distribuzione completa. Nelle versioni precedenti, BDD consentiva di creare e gestire immagini desktop in modo semplice e ripetibile. BDD 2007 fornisce ora funzionalità aggiuntive per creare una soluzione di distribuzione scalabile grazie all'integrazione con i Servizi di distribuzione Windows (WDS), SQL ServerTM e il servizio Replica DFS (DFS-R) di Windows Server® 2003.
L'utilizzo di SMS 2003 con Operating System Deployment (OSD) Feature Pack è la procedura consigliata per la distribuzione di client Windows.
Se si dispone già di un'infrastruttura SMS 2003, è consigliabile effettuare la distribuzione utilizzando BDD 2007, SMS 2003 e OSD Feature Pack. Attualmente, questa è la soluzione più completa in grado di consentire una distribuzione automatica, riducendo notevolmente i costi di installazione, configurazione e gestione di Windows all'interno dell'organizzazione.
Tuttavia, molti clienti non dispongono di SMS 2003 o di soluzioni equivalenti per la distribuzione del software. In questi casi, esiste un'altra opzione che verrà esaminata in questo articolo.

Concetti fondamentali di BDD 2007
BDD 2007 offre due principali metodi di distribuzione: il primo, Lite Touch Installation, prevede solo l'utilizzo di BDD 2007 per la distribuzione del client. La soluzione standard presenta un insieme di procedure guidate da eseguire in fase di creazione per acquisire informazioni sulla distribuzione, ad esempio il nome del computer da assegnare al client (vedere la Figura 1), il layout di tastiera, il fuso orario e così via. Questo metodo viene denominato "Lite Touch", poiché in genere richiede un input manuale minimo per raccogliere le informazioni prima che inizi il processo di creazione.
Figura 1 Procedura guidata di distribuzione Lite Touch di BDD 2007
Figura 1 Procedura guidata di distribuzione Lite Touch di BDD 2007
Il secondo metodo, Zero Touch Installation, è basato sulle funzionalità di SMS 2003 con OSD Feature Pack integrate con BDD 2007. Questa configurazione può fornire una soluzione di distribuzione completamente automatica, scalabile e gestibile.
In fase di creazione, durante uno dei primi passaggi per la distribuzione di un sistema operativo client, BDD 2007 raccoglie informazioni da un'ampia gamma di origini, ad esempio dalle chiamate WMI e dai file di configurazione di BDD 2007, Bootstrap.ini e CustomSettings.ini. Le informazioni vengono raccolte e archiviate come variabili che verranno utilizzate durante la distribuzione. In uno scenario Lite Touch, i file Bootstrap.ini e CustomSettings.ini consentono di predefinire tutte le informazioni che verrebbero altrimenti raccolte tramite input manuale nelle procedure guidate di distribuzione.
La possibilità di specificare in anticipo le informazioni che verrebbero acquisite dalle procedure guidate di Lite Touch consente di automatizzare l'intero processo e di avvicinarsi a una soluzione Zero Touch negli ambienti non supportati da SMS 2003. Tali informazioni potrebbero includere, ad esempio, ComputerName=RDG0001VST per assegnare al computer il nome RDG0001VDT o TimeZoneName=GMT Standard Time per impostare il fuso orario del computer sull'ora di Greenwich (GMT). Tutte le proprietà che possono essere utilizzate durante una distribuzione con BDD sono illustrate nella documentazione di riferimento alla configurazione disponibile all'indirizzo technet.microsoft.com/library/bb490302.aspx.
Per ulteriori informazioni sulla configurazione e sull'utilizzo di BDD 2007, vedere l'articolo "Distribuzione di Windows Vista con BDD 2007" nel numero di settembre 2007 di TechNet Magazine (technetmagazine.com/issues/2007/09/BDD).

BDD e SQL Server
A che scopo utilizzare un database con BDD 2007? La risposta sta nella velocità con cui, durante la distribuzione, vengono fornite le informazioni che altrimenti dovrebbero essere immesse manualmente tramite le procedure guidate di Lite Touch Installation. Come illustrato in precedenza, è possibile far ciò utilizzando il file CustomSettings.ini. Il problema consiste nel fatto che, in una distribuzione reale, queste informazioni possono variare in base al computer in cui si esegue la distribuzione. Inoltre, il file CustomSettings.ini può diventare rapidamente ingestibile nel caso in cui si tenti di definire opzioni e impostazioni specifiche per 500 computer diversi. Collegando un database back-end alla console di BDD, è possibile ottenere una soluzione molto più gestibile, dinamica ed estendibile.
Per integrare SQL Server in BDD 2007, è necessario innanzitutto verificare che nel server di distribuzione sia installato SQL Server (preferibilmente SQL Server 2005 o versione successiva). Fortunatamente, la procedura per creare il database in BDD 2007 è estremamente semplice: è sufficiente fare clic con il pulsante destro del mouse sul nodo Database di Deployment Workbench BDD 2007, scegliere New e seguire le istruzioni (vedere la Figura 2). Il team di BDD ha creato procedure guidate che consentono di diventare operativi in modo estremamente rapido e semplice.
Figura 2 Configurazione del database di distribuzione per BDD 2007
Figura 2 Configurazione del database di distribuzione per BDD 2007
Una volta creato il database, è possibile iniziare a esaminarne le funzionalità. Le voci del database sono suddivide in quattro categorie principali: Computer, Role, Location e Make and Model. Ogni categoria consente di definire determinate voci e, per ogni voce, è possibile specificare variabili di BDD 2007, assegnare applicazioni e configurare altre impostazioni chiave (vedere la Figura 3).
Figura 3 Assegnazione delle proprietà di distribuzione
Figura 3 Assegnazione delle proprietà di distribuzione
È utile suddividere queste quattro categorie in due gruppi distinti. Le categorie Computer, Location e Make and Model offrono diversi metodi per identificare un computer durante la fase di creazione. Ogni computer identificato può essere associato a un ruolo specifico del database e quindi configurato per un determinato scopo, ad esempio le vendite, il marketing o la gestione finanziaria. Ogni ruolo garantisce pertanto che siano installate le applicazioni line-of-business appropriate.
La sezione Computer consente di identificare i computer in base a un indirizzo MAC, un tag asset, un identificatore unico universale (UUID) o un numero di serie. A causa dell'elevato numero di voci che verranno probabilmente create in questa sezione, una per ogni computer dell'organizzazione, si consiglia di aggiungere a ogni voce solo proprietà specifiche, ad esempio ComputerName.
La sezione Location consente invece di creare voci per posizioni geografiche specifiche all'interno dell'organizzazione. Ogni voce è identificata dal gateway predefinito in tale posizione. Ciò può risultare particolarmente utile se in Active Directory® si dispone di unità organizzative (OU) basate sulle posizioni e si desidera che i computer creati in una posizione specifica vengano aggiunti al dominio dell'unità organizzativa corrispondente.
La sezione Make and Mode consente infine di creare voci per ogni tipo di hardware che deve essere supportato nella distribuzione. In BDD 2007, queste voci vengono associate alle informazioni rilevate tramite chiamate WMI. Negli ambienti di sviluppo, la sezione Make and Model viene spesso utilizzata per creare una voce in grado di determinare se il computer è un Virtual PC 2007 o Virtual Server 2005, controllando rispettivamente le proprietà "Microsoft Corporation" e "Virtual Machine". Se in fase di creazione vengono rilevate tali corrispondenze, per indicare a BDD che è necessario installare l'applicazione Virtual Machine Additions in fase di distribuzione, è sufficiente aggiungere l'applicazione alla voce Make and Model.
Dopo aver fornito i metodi di identificazione dei computer, è possibile utilizzare la sezione Roles per creare le voci per ogni ruolo di distribuzione che si desidera configurare. Ad esempio, è possibile creare una voce per un ruolo Windows XP e un ruolo Windows Vista aggiungendo a ogni voce la proprietà BuildID che corrisponde alla build di Windows XP o Windows Vista definita in BDD. In alternativa, è possibile specificare ruoli di reparto, ad esempio per la contabilità, le vendite o la gestione finanziaria. In genere, è consigliabile compilare la maggior parte delle proprietà di BDD disponibili in questa sezione (fuso orario, impostazioni internazionali, informazioni sull'organizzazione e così via). In questo modo, l'attività di gestione del database sarà ridotta al minimo, poiché le voci non sono associate a posizioni, computer o hardware specifici.
È necessario indicare a BDD 2007 che, in fase di distribuzione, occorre cercare nel database eventuali voci corrispondenti al computer che verrà creato. Per configurare BDD in modo che utilizzi il database durante la distribuzione, è sufficiente fare clic con il pulsante destro del mouse sul punto di distribuzione e scegliere Configure DB. Verrà visualizzata una serie di procedure guidate per compilare il file CustomSettings.ini con le voci in base alle quali il processo Lite Touch Installation eseguirà una query nel database per ottenere informazioni.

Scalabilità della distribuzione
A questo punto, si dispone di un server di distribuzione in grado di automatizzare il processo Lite Touch Installation e di configurare in modo dinamico ogni computer in base a un ruolo aziendale specifico. Di seguito viene indicata la procedura per garantire la scalabilità di questa soluzione.
L'architettura della soluzione si basa su una topologia hub e spoke, come illustrato nella Figura 4. Il primo server di distribuzione configurato sarà l'hub e il server di distribuzione padre e ciascun server di distribuzione figlio fungerà da spoke.
Figura 4 Architettura di distribuzione hub e spoke
Figura 4 Architettura di distribuzione hub e spoke
Per abilitare questa architettura, è necessario utilizzare DFS-R per replicare la condivisione di distribuzione in ciascun server di distribuzione. È necessario quindi utilizzare la replica snapshot di SQL Server per configurare una copia del database di distribuzione di BDD nei server di distribuzione figlio. L'aspetto interessante di questa soluzione consiste nel fatto che i server di distribuzione figlio presentano requisiti minimi: per abilitare la distribuzione, è sufficiente che in ogni computer siano installati SQL Server Express, i Servizi di distribuzione Windows e DFS-R.
A causa della notevole quantità di dati che può essere archiviata nella condivisione di distribuzione di BDD 2007, è consigliabile utilizzare DFS-R in Windows Server 2003 R2 anziché il servizio Replica file nelle versioni precedenti di Windows Server. DFS-R utilizza la tecnologia RDC (Remote Differential Compression) per replicare solo le modifiche differenziali dei file (delta) tra i membri del gruppo di distribuzione. Se viene apportata una piccola modifica al file di immagine personalizzato, ad esempio l'aggiunta di un nuovo driver, questa soluzione può incidere notevolmente sulla quantità del traffico di replica. Con DFS-R, il traffico sarà infatti pari all'entità delle modifiche apportate, poiché non sarà necessaria una ridistribuzione dell'intero file di immagine.
Sul sito Web Microsoft sono disponibili numerose informazioni su DFS, ad esempio all'indirizzo microsoft.com/windowsserver2003/technologies/storage/dfs. Tuttavia, anche in questo articolo verranno illustrati i principali passaggi di installazione e configurazione, allo scopo di fornire una panoramica sul processo nel contesto di una distribuzione basata su BDD.
Si tenga presente che se la versione di Active Directory eseguita sui server in uso è basata su un'installazione di Windows Server 2003 precedente alla versione R2, potrebbe essere necessario aggiornare lo schema di Active Directory per consentire l'esecuzione di DFS-R, poiché il servizio di replica richiede nuove classi di oggetti. Per informazioni complete sull'estensione dello schema di Active Directory in Windows Server 2003 R2, vedere go.microsoft.com/fwlink/?LinkId=99936.
Il primo passaggio prevede l'installazione dei componenti DFS nel server di distribuzione di Windows Server 2003 R2. Questa operazione può essere eseguita in diversi modi. Uno dei più semplici consiste nell'utilizzare la procedura guidata standard, ovvero Installazione componenti di Windows. Una volta completato questo passaggio, è necessario configurare un gruppo di replica utilizzando la console di gestione DFS illustrata nella Figura 5.
Figura 5 Console di gestione DFS
Figura 5 Console di gestione DFS
Per garantire la scalabilità della soluzione BDD 2007, è necessario replicare due cartelle specifiche. La prima cartella è la condivisione di distribuzione di BDD 2007 che contiene tutti i file di configurazione e di origine BDD. Tali file devono essere disponibili su ogni server di distribuzione.
La seconda cartella da replicare è la cartella di avvio utilizzata dai Servizi di distribuzione Windows per conservare il file LiteTouch_x86.wim. Si tratta dell'ambiente di avvio BDD fornito dai Servizi di distribuzione Windows sui computer client desktop per iniziare il processo di distribuzione. È necessario replicare questo file per garantire che eventuali modifiche apportate all'ambiente di avvio sul server di distribuzione padre vengano replicate nell'intera infrastruttura di distribuzione.
I percorsi da replicare sono X:\Distribution (dove X è la lettera di unità specificata durante l'installazione di BDD 2007) e Y:\RemoteInstall\boot (dove Y è la lettera di unità del volume che contiene la condivisione RemoteInstall dei Servizi di distribuzione Windows).
La replica effettuata in DFS-R è di tipo multimaster, pertanto non è possibile creare una topologia di replica unidirezionale. Di conseguenza, per consentire una gestione centralizzata della condivisione di distribuzione, è necessario configurare l'accesso in sola lettura alla cartella di distribuzione di ogni server figlio. In questo modo, solo la replica DFS-R potrà scrivere in tale cartella, utilizzando diritti di backup e ripristino. I computer client basati su tali server figlio non dovranno mai scrivere in questa cartella, pertanto non sarà necessario garantire agli account autorizzazioni superiori a quelle di lettura.
L'ultimo passaggio di configurazione per completare la replica dei dati tramite DFS-R consiste nell'impostare i criteri di aggiornamento per l'archivio di dati di configurazione di avvio (BCD) nei Servizi di distribuzione Windows. In questo modo, si garantisce che eventuali modifiche apportate all'ambiente di avvio vengano riflesse in ogni server di distribuzione figlio. Questa modifica alla configurazione deve essere impostata su tutti i server dei Servizi di distribuzione Windows ed è consigliabile effettuarla durante il processo di creazione e configurazione dei server di distribuzione.
Su ogni server di distribuzione, è necessario eseguire il comando indicato di seguito:
WDSUTIL /set-server /BCDRefreshPolicy /Enabled:yes /RefreshPeriod:<time in minutes>
L'intervallo di aggiornamento dipende dalla frequenza con cui vengono aggiornati i dati sui server di distribuzione. Se DFS-R viene configurato per eseguire una replica ogni ora, è opportuno configurare i criteri di aggiornamento dell'archivio BCD per eseguire l'aggiornamento ogni 60 minuti.

Replica di SQL Server
Finora è stato illustrato come garantire la scalabilità di BDD 2007 per replicare la condivisione di distribuzione BDD e l'immagine di avvio dei Servizi di distribuzione Windows dal server di distribuzione primario ai server figlio. Il passaggio successivo consiste nel completare il processo e replicare il database BDD 2007 Deployment Workbench in modo che sia disponibile localmente su ogni server di distribuzione.
In SQL Server viene utilizzata una metodologia di replica che nella documentazione del prodotto viene paragonata al processo di pubblicazione di una rivista. In base a tale esempio, il processo prevede un editore che produce la rivista, i distributori che ne gestiscono la distribuzione per l'editore e gli abbonati che effettuano una sottoscrizione per ricevere la rivista. La stessa terminologia viene utilizzata per descrivere le funzionalità di replica incorporate in SQL Server.
Si tenga presente che, per pubblicare un database di SQL Server, sul server non è sufficiente SQL Server Express Edition, ma è necessaria la versione completa di SQL Server. Come server di distribuzione primario, si consiglia di utilizzare SQL Server 2005 (sebbene sia supportato anche SQL Server 2000). Come server di distribuzione figlio, è possibile utilizzare SQL Server 2005 o SQL Server 2005 Express.
Prima di iniziare a configurare la replica di SQL Server, è necessario completare alcuni passaggi per verificare che SQL Server sia configurato correttamente per supportare la replica. Quando si configurano i server di distribuzione, è necessario includere i componenti di replica durante l'installazione di SQL Server 2005 o SQL Server 2005 Express Edition. Per impostazione predefinita, i componenti di replica non vengono installati in SQL Server Express.
Successivamente, per consentire la connessione remota tra l'ambiente di avvio Lite Touch e SQL Server, è necessario abilitare le connessioni remote in SQL Server. A questo scopo, è sufficiente avviare lo strumento Configurazione superficie di attacco di SQL Server, selezionare Configurazione superficie di attacco per servizi e connessioni e configurare il server in modo che accetti sia le connessioni locali che quelle remote da TCP/IP e named pipe.
Quindi, è necessario creare sul server di distribuzione primario una cartella condivisa contenente i dati degli snapshot di replica che verranno letti dagli agenti di replica su ogni server di distribuzione figlio. Tale cartella condivisa verrà descritta più avanti in questo articolo. In genere, si consiglia di posizionare la cartella nello stesso volume in cui si trovano gli altri contenuti della distribuzione.
Gli ultimi passaggi di configurazione sono richiesti solo se si utilizza SQL Server Express Edition sui server di distribuzione figlio. Per impostazione predefinita, il servizio SQL Server Browser è disabilitato. Per consentire la replica, questo servizio deve essere impostato sull'esecuzione automatica e avviato. Sarà quindi possibile configurarlo utilizzando lo strumento Gestione configurazione SQL Server. Inoltre, sarà necessario creare un database sui server figlio in cui replicare i contenuti. Per ridurre al minimo le operazioni di configurazione richieste, si consiglia di assegnare a questo database lo stesso nome del database di BDD 2007.

Configurazione della replica
Per iniziare a configurare la replica di SQL Server, è necessario innanzitutto avviare SQL Server Management Studio sul server di distribuzione master, in cui deve essere eseguita la versione completa di SQL Server 2005. Il primo passaggio consiste nel creare e configurare una distribuzione. A questo scopo, è necessario accedere alla cartella Replica della console di gestione, come illustrato nella Figura 6. Per avviare la procedura guidata di distribuzione, è sufficiente fare clic con il pulsante destro del mouse sulla cartella Replica e scegliere Configura distribuzione.
Figura 6 SQL Server Management Studio: replica
Figura 6 SQL Server Management Studio: replica
Nella procedura guidata, è necessario confermare che il server di distribuzione primario deve fungere da proprio server di distribuzione. Successivamente, è necessario impostare la cartella principale degli snapshot come percorso UNC (Universal Naming Convention) della condivisione di replica di SQL Server creata in precedenza. Infine, è necessario impostare il server di distribuzione primario come server di pubblicazione.
Una vota configurato il server per la distribuzione e la pubblicazione tramite la procedura guidata, è necessario indicare a SQL Server il database che si desidera pubblicare. Per eseguire questa operazione, fare clic con il pulsante destro del mouse sulla cartella Replica e scegliere Proprietà server di pubblicazione. Nella finestra di dialogo delle proprietà, selezionare Database di pubblicazione e scegliere il database di BDD 2007 per la replica transazionale, come illustrato nella Figura 7. Anche se non si utilizza la replica transazionale, questa opzione viene selezionata a prescindere se si desideri eseguire la replica snapshot o quella transazionale.
Figura 7 Pubblicazione del database
Figura 7 Pubblicazione del database
Sarà quindi necessario creare una pubblicazione a cui possano effettuare la sottoscrizione i server di distribuzione figlio. Nella cartella Replica, fare clic con il pulsante destro del mouse su Pubblicazioni locali e scegliere Nuova pubblicazione per avviare la procedura guidata di pubblicazione. Selezionare quindi il database di BDD come database da pubblicare. Selezionare la replica snapshot come tipo di pubblicazione e specificare tutte le tabelle, le stored procedure e le visualizzazioni da replicare. Si consiglia di impostare la creazione immediata di uno snapshot iniziale. Per la pianificazione dell'agente snapshot, dovrebbe essere più che sufficiente configurare un'esecuzione giornaliera come impostazione predefinita, a meno che non si preveda di apportare modifiche frequenti al database.
L'ultimo passaggio consiste nel sottoscrivere ciascun server di distribuzione figlio a questa pubblicazione. Ciò consentirà a SQL Server di inviare una copia del database a ogni server di distribuzione figlio a intervalli di tempo specificati. Nella sottocartella Pubblicazioni locali della cartella Replica, fare clic con il pulsante destro del mouse sulla pubblicazione appena creata e scegliere l'opzione che consente di avviare la procedura guidata per creare nuove sottoscrizioni. Nella procedura guidata, selezionare la pubblicazione di BDD creata nei passaggi precedenti. Scegliere di eseguire tutti gli agenti durante la distribuzione, abilitando la topologia di replica come sottoscrizione push. Aggiungere quindi ogni server di distribuzione figlio come sottoscrittore e indicare il database creato su ogni server in modo che riceva la copia dei dati replicati (questo database deve avere lo stesso nome del database di distribuzione primario). Infine, sarà necessario configurare un account da utilizzare per le connessioni e definire una pianificazione di replica, che dovrebbe riflettere quella impostata per l'agente snapshot. Questa rapida panoramica fornisce gli elementi necessari per iniziare subito a utilizzare la replica di SQL Server.

Configurazione di BDD 2007
Finora è stato illustrato come configurare BDD 2007 per utilizzare un database e impostare la replica del database e della condivisione di distribuzione BDD 2007 nei server di distribuzione figlio. Per completare la soluzione di distribuzione, è necessario configurare BDD 2007 in modo che, quando un client scarica l'ambiente di avvio BDD, venga automaticamente connesso al server di distribuzione locale.
In un ambiente Windows PE Lite Touch, se il client viene avviato da un server dei Servizi di distribuzione Windows, in Windows PE viene impostato un valore del Registro di sistema che contiene il nome del server da cui è stato scaricato l'ambiente di avvio. Gli script di distribuzione iniziali di BDD 2007 selezionano questo valore e lo archiviano in una variabile di ambiente denominata %WDSServer%.
Se si utilizza la versione iniziale di BDD 2007, è possibile che tale valore non venga compilato correttamente nel Registro di sistema di Windows PE. Per correggere questo comportamento, è disponibile un aggiornamento all'indirizzo support.microsoft.com/kb/937191.
Per configurare BDD 2007, è sufficiente modificare i file di configurazione Bootstrap.ini e CustomSettings.ini in modo che qualsiasi riferimento al server di distribuzione venga sostituito con %WDSServer%. In genere, questa operazione richiede la sostituzione dei valori del nome di istanza SQL Server, nonché del valore di DeploymentRoot, ovvero il server che ospita la condivisione di distribuzione. Nella Figura 8 e nella Figura 9 sono illustrati un file Bootstrap.ini di esempio e una porzione del file CustomSettings.ini.
Figure 9 CustomSettings.ini (Close Figure 9)
[Settings]
Priority=MMSettings, MMApps, CSettings, CRoles, RSettings, RApps, Default
Properties=Manufacturer

[Default]
OSInstall=Y
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234

[CSettings]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[CRoles]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Figure 8 Bootstrap.ini (Close Figure 8)
[Settings]
Priority=Default

[Default]
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234
SkipBDDWelcome=YES
Questa soluzione richiede la presenza dei Servizi di distribuzione Windows sullo stesso server che contiene le repliche del database e della condivisione di distribuzione di BDD 2007. Le ragioni sono evidenti: in questo modo, è possibile utilizzare la variabile %WDSServer% in modo semplice e sicuro per indicare al computer client la posizione del server di distribuzione locale e per impedire ulteriori comunicazioni sulla rete WAN.

Considerazioni aggiuntive
L'aspetto interessante di BDD 2007 consiste nel fatto che è estendibile, pertanto è possibile valutare molti altri aspetti per estendere la soluzione. Ad esempio, è possibile utilizzare le funzionalità incorporate per monitorare SQL Server e DFS-R, per progettare metodi che consentano di compilare i computer del proprio ambiente con le informazioni ottenute da un database di gestione delle risorse, oppure per recuperare tali informazioni utilizzando una stored procedure SQL. Anche se in questo articolo non vengono illustrati questi scenari, è stata comunque fornita una panoramica su alcuni metodi per sfruttare le funzionalità di BDD all'interno dell'organizzazione.

Adam Shepherd lavora come consulente per i servizi di consulenza Microsoft nel Regno Unito. Adam si interessa principalmente di questioni relative alla distribuzione, alla manutenzione e alla gestione di client Windows. È possibile contattare Adam all'indirizzo adamshep@microsoft.com.


 Comunicazioni: Server Trasporto Edge di Microsoft Exchange Parte 2
Comunicazioni Kay Unkroth

Server Trasporto Edge di Microsoft Exchange Parte 2
Panoramica:
  • Utilizzo dei registri e delle tracce del Trasporto Edge
  • Configurazione della protezione dalla posta indesiderata tramite script
  • Test di scenari di posta indesiderata tipici
Scarica il codice per questo articolo: Edge2007_11.exe (161KB)

Di fronte all'inondazione di posta indesiderata e ai contenuti dannosi che fluiscono in Internet, come è possibile garantire agli utenti un sistema di messaggistica affidabile e sicuro nell'organizzazione? Un metodo, la cui descrizione è iniziata il mese scorso nella prima parte di questa serie, è costituito dalla distribuzione di
server Trasporto Edge di Exchange Server 2007 e Forefront Security per Exchange Server in una rete perimetrale tra Internet e l'ambiente di produzione.
In questo secondo articolo conclusivo della serie verrà spiegato come analizzare gli agenti di Trasporto Edge in azione utilizzando le funzionalità di registrazione agente e traccia standard di Exchange Server 2007. Verrà anche utilizzato un metodo personalizzato per eseguire il dump di tutti gli oggetti evento dalla pipeline di trasporto su file XML. Verrà quindi illustrato come applicare impostazioni di protezione dalla posta indesiderata in un laboratorio per i test di Trasporto Edge in base alla configurazione utilizzata da Microsoft nel proprio ambiente di produzione aziendale. Infine, l'articolo si concluderà con alcuni interessanti e realistici scenari di test per vedere in che modo gli agenti di Trasporto Edge rispondono alle varie situazioni di posta indesiderata.
Per ulteriori informazioni sull'installazione del laboratorio per i test di Trasporto Edge e sull'architettura generale di Trasporto Edge, consultare il primo articolo di questa serie nel numero di ottobre 2007 di TechNet Magazine, disponibile all'indirizzo technetmagazine.com/issues/2007/10/Edge.
Utilizzo in modo intensivo script e file batch per automatizzare le attività di configurazione più importanti ed è possibile trovare questi script nel download del codice che accompagna questo articolo (accedere all'indirizzo technetmagazine.com/code07.aspx). Inoltre, per ulteriori informazioni sulla configurazione IT Microsoft degli agenti di Trasporto Edge, è consigliabile consultare il white paper tecnico "Trasporto Edge di Microsoft® Exchange Server 2007 e protezione della messaggistica", prodotto per Microsoft IT ShowCase È possibile scaricare questo white paper di IT Showcase dall'indirizzo microsoft.com/technet/itshowcase/content/edgetransport.mspx.

Registrazione e traccia
Exchange Server 2007 contiene numerose funzionalità di registrazione e traccia, tra cui la registrazione protocollo, la registrazione agente e la traccia della pipeline, che semplifica la diagnosi e la risoluzione dei problemi degli agenti di trasporto. Anche se in questo articolo non viene trattata nello specifico la risoluzione dei problemi relativi agli agenti di trasporto, le informazioni di registrazione e traccia sono utili per esaminare il funzionamento degli agenti di Trasporto Edge.
Se si desidera tenere traccia delle attività di invio e ricezione SMTP, è necessario attivare la registrazione protocollo per i connettori di invio e ricezione. Utilizzando l'ambiente di test, ho configurato la prima parte di questa serie (vedere la Figura 1), ho attivato la registrazione protocollo tramite la seguente impostazione nei cmdlet New-SendConnector e New-ReceiveConnector:
Figura 1 Ambiente di test
Figura 1 Ambiente di test
–ProtocolLoggingLevel: Verbose
Per impostazione predefinita è possibile trovare i file di registro SMTP risultanti nelle sottocartelle in %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog.
La registrazione protocollo è utile se si desidera analizzare le conversazioni SMTP, anche se gli agenti di protezione dalla posta indesiderata non sempre interferiscono con la sessione SMTP. Ad esempio, l'agente filtro contenuto può contrassegnare solo i messaggi in ingresso con un valore del livello di probabilità di posta indesiderata (SCL). Finché il livello di probabilità di posta indesiderata è inferiore alla soglia specificata (l'impostazione predefinita è 7), l'agente filtro contenuto non determina il rifiuto del messaggio da parte del processo di Trasporto Edge. Pertanto la conversazione SMTP prosegue inalterata.
Per analizzare le azioni eseguite dagli agenti di protezione dalla posta indesiderata (filtro connessioni, filtro contenuto, regole Edge, filtro destinatario, filtro mittente e ID mittente) sui messaggi che passano dalla pipeline del trasporto, è necessario verificare i registri agente e non i registri protocollo. La registrazione agente è generalmente attivata in base al parametro AgentLogEnabled nel file EdgeTransport.exe.config. Per impostazione predefinita, i registri agente si trovano nella cartella %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog. È possibile aprire i registri in Blocco Note, anche se il cmdlet Get-AgentLog visualizza le informazioni del registro agente in modo più intuitivo in Exchange Management Shell.
Un'altra funzionalità utile è la traccia della pipeline, che consente di acquisire istantanee dei messaggi provenienti da un determinato mittente quando passano attraverso la pipeline di trasporto. Il concetto è relativamente semplice: il processo di Trasporto Edge crea un'istantanea di ciascun messaggio prima e dopo aver richiamato gli agenti di ricezione SMTP e routing registrati per gli eventi OnEndOfHeaders, OnEndofData, OnSubmittedMessage e OnRoutedMessage. Confrontando le istantanee dei messaggi, è possibile osservare in che modo i singoli agenti modificano ciascun messaggio. Ovviamente, è imperativo che questa preziosa funzionalità venga attivata nell'ambiente di test.
Il seguente utilizzo del cmdlet Set-TransportServer attiva la traccia della pipeline per un utente test. Come era possibile prevedere, il parametro PipelineTracingEnable impostato su $true attiva la traccia della pipeline. L'indirizzo di posta elettronica dell'utente test è impostato nel parametro PipelineTracingSenderAddress:
Set-TransportServer –Identity EDGE01
–PipelineTracingEnabled $true
-PipelineTracingSenderAddress Contoso.User@contoso.com
Con la traccia della pipeline attivata, è possibile trovare i file di istantanea del messaggio per ciascun messaggio proveniente dal mittente specificato (in questo caso, si tratta di Contoso.User@contoso.com) nella cartella %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots. Questa è la cartella predefinita. Per ciascun messaggio, i file di istantanea si trovano in una sottodirectory denominata in base a un GUID assegnato al messaggio. Si noti che è possibile trovare il messaggio originale in un file denominato Original.eml nonché alcune copie del messaggio nei file .eml che iniziano con SmtpReceive o Routing in base agli eventi rilevati e agli agenti installati. Per analizzare l'elaborazione degli agenti di protezione dalla posta indesiderata registrati per gli eventi di ricezione SMTP OnEndofData e OnEndOfHeaders, verificare i file SmtpReceive*.eml. Per analizzare l'elaborazione degli agenti antivirus e di altro tipo registrati per gli eventi di routing OnSubmittedMessage e OnRoutedMessage, analizzare invece i file Routing*.eml.

Dump personalizzato della pipeline
Le funzionalità di registrazione agente e traccia standard di Exchange Server 2007 rispondono a tutte le esigenze di risoluzione dei problemi malgrado le funzionalità standard non riguardino tutti gli eventi di trasporto. Ad esempio, la traccia della pipeline non è in grado di acquisire informazioni su OnConnectEvent, OnEhloCommand, OnMailCommand, OnRcptCommand, OnDataCommand ed eventi di trasporto simili perché l'host di invio non ha ancora trasferito alcun messaggio che potrebbe essere stato scritto nella cartella %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. Per acquisire informazioni dettagliate su questi eventi, è necessario implementare un agente personalizzato che esegue il dump dei dati di evento su file nel file system.
Come è stato discusso nel mio articolo precedente, la creazione di agenti personalizzata non è complicata, quindi non ho potuto fare a meno di sviluppare un agente di ricezione SMTP e di un agente di routing per eseguire il dump di tutti gli oggetti evento dalla pipeline di trasporto in file XML. È possibile trovare un progetto Microsoft Visual Studio® 2005 corrispondente, denominato PipelineXMLDump, nel download disponibile per questo articolo. I due file importanti sono DumpAgents.cs, che implementa factory dell'agente e gli agenti, e XMLDump.cs, che implementa una classe helper per scrivere i campi degli oggetti origine evento e argomento evento per mezzo dei metodi System.Reflection nei file XML. Se si compila il codice sorgente e si copia il file PipelineXMLDump Dll risultante in una cartella denominata C:\PipelineXMLDump sul server Trasporto Edge, è possibile registrare e attivare gli agenti personalizzati utilizzando gli script RegisterPipelineXMLDump.ps1 e EnableDumpAgents.ps1 Gli script sono contenuti nella cartella di progetto PipelineXMLDump del download. Ovviamente, il fine degli agenti personalizzati è puramente illustrativo in quanto non sono stati testati a sufficienza e non devono mai installati su un server di produzione. L'utilizzo di questi agenti è a proprio rischio.
DumpAgents.cs illustra come implementare tutti i gestori eventi di ricezione SMTP e routing supportati dalla pipeline di trasporto. Questo può costituire un buon punto di partenza se si desidera implementare agenti personalizzati. I miei agenti di dump scrivono file XML nelle sottocartelle in %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump che corrispondono all'identificatore della sessione SMTP (agente di ricezione SMTP) o all'identificatore del messaggio (agente di routing). Nella Figura 2 viene illustrato un esempio di informazioni sull'argomento dell'evento passate all'agente di ricezione SMTP nel gestore OnConnectEvent. L'esempio rivela l'endpoint IP locale (indirizzo IP e porta) che ha accettato una richiesta di connessione in entrata.
Figura 2 Informazioni sull'argomento scaricate durante l'evento OnConnect
Figura 2 Informazioni sull'argomento scaricate durante l'evento OnConnect

Preparazione delle esecuzioni di test
Basta con la teoria su registrazione, traccia e dump. Passiamo ad alcune esecuzioni di test che illustrano gli agenti di protezione dalla posta indesiderata in azione. Di seguito viene fornito un breve riepilogo che rispecchia il più possibile la configurazione di Microsoft IT nell'ambiente di test. Come è stato accennato in precedenza, le informazioni generali sono disponibili nel white paper tecnico "Trasporto Edge di Microsoft Exchange Server 2007 e protezione della messaggistica".
Per iniziare, basta disattivare l'agente di riscrittura degli indirizzi dei messaggi in ingresso, di filtro allegati e di riscrittura degli indirizzi dei messaggi in uscita eseguendo lo script EDGE01_disable_agents.ps1 disponibile nel download che accompagna l'articolo. Non è necessario riscrivere gli indirizzi perché i destinatari utilizzano gli stessi indirizzi di posta elettronica sia internamente che esternamente. Non viene utilizzato l'agente filtro allegati perché sono disponibili funzionalità di filtro degli allegati sostitutive in Forefront Security.
L'ambiente di test non è connesso a Internet e questo rende difficile testare l'agente filtro connessioni. Per risolvere il problema, è possibile creare un elenco di blocco IP nell'host Internet eseguendo il file INTERNET01_create_IP_block_list.bat. Controllare che Windows® Support Tools sia installato perché contiene lo strumento della riga di comando DNS (dnscmd.exe). In caso contrario, è possibile dedicare un po' di tempo alla creazione manuale di record DNS utilizzando la console DNS.
Ora è possibile configurare l'agente filtro connessioni eseguendo lo script EDGE01_add_block_list_provider.ps1. Questo script aggiunge un provider elenco indirizzi IP bloccati per ip-bl.consolidatedmessenger.com. Si tratta dell'elenco di indirizzi IP bloccati di Consolidated Messenger, già creato nell'ambiente di test tramite l'esecuzione del file INTERNET01_create_IP_block_list.bat nell'host Internet, come citato in precedenza. Microsoft IT utilizza anche l'elenco indirizzi IP bloccati locale e l'elenco IP consentiti, ma queste funzionalità non richiedono la configurazione manuale. È importante notare che Microsoft IT non utilizza i provider di elenco indirizzi IP consentiti.
Quindi, configurare l'agente filtro destinatario eseguendo lo script EDGE01_recipient_filter.ps1 per bloccare i messaggi a destinatari inesistenti e i messaggi alle caselle di posta e alle liste di distribuzione globali riservate per uso interno o solo in uscita.
Anche l'agente filtro mittente richiede un aggiornamento della configurazione. Microsoft IT utilizza il filtro dei mittenti come contromisura contro gli attacchi flood di posta da indirizzi mittente specifici e per bloccare determinati server di elenco e origini simili che sono non ritenuti pertinenti per l'azienda. Microsoft IT utilizza inoltre il filtro dei mittenti per bloccare i messaggi con informazioni sul mittente non valide o mancanti. Applichiamo questa configurazione all'ambiente di test eseguendo lo script EDGE01_sender_filter.ps1 sul server Trasporto Edge.
Se si desidera rispecchiare la configurazione di Microsoft IT è anche necessario configurare i record Sender Policy Framework (SPF) in DNS. Per generare una record SPF che attesta l'autorità del server Trasporto Edge per i messaggi dal dominio adventure-works.com, è possibile utilizzare la procedura guidata Microsoft per la creazione di record SPF del framework ID mittente disponibile all'indirizzo microsoft.com/mscorp/safety/content/technologies/senderid/wizard. È possibile fare un tentativo e specificare un nome di dominio Internet esistente. Nell'ambiente di test, è possibile eseguire il file INTERNET01_create_SPF_record.bat nell'host Internet.
Tutto qui. Non è necessario configurare altri parametri perché la maggior parte degli agenti è provvista di impostazioni predefinite appropriate. Per eseguire una rapida verifica delle impostazioni predefinite più importanti per gli agenti regole Edge, ID mittente, analisi protocollo e filtro contenuto, eseguire lo script EDGE01_check_defaults.ps1 sul server Trasporto Edge.

Agenti di Trasporto Edge in azione
Ora, ipotizziamo il funzionamento degli agenti di Trasporto Edge in alcuni scenari di messaggistica realistici. Per inviare messaggi di test al server Trasporto Edge, utilizzo il servizio SMTP e POP3 incluso in Windows Server 2003 e Outlook® Express come client di messaggistica, adottando le impostazioni predefinite per la maggior parte del tempo, ma controllando che la registrazione sia attivata.
Ma prima, un avvertimento: non seguire i passaggi o eseguire gli script descritti in questa sezione se nell'ambiente di test è attiva una connessione a un sistema di produzione o a Internet. Il test viene svolto a proprio rischio.
Il primo agente che viene testato è filtro connessioni. Merita di essere il primo perché è quello con il funzionamento più difficoltoso su un server Trasporto Edge. In Microsoft, l'agente filtro connessioni blocca circa l'88% di tutti gli invii di messaggi Internet. Su 13 milioni di tentativi di invio che hanno luogo in una normale giornata lavorativa, solo 1,5 milioni provengono da mittenti legittimi.
Quindi inviamo un messaggio di posta elettronica come Fabrikam.User@Fabrikam.com ad Administrator@adventure-works.com. Se tutto funziona correttamente, l'amministratore non dovrebbe ricevere il messaggio. Al contrario, Fabrikam.User dovrebbe ricevere una notifica sullo stato del recapito indicante che il destinatario non ha ricevuto il messaggio. Fabrikam.User verifica che l'indirizzo di posta elettronica sia corretto, invia di nuovo lo stesso messaggio e Fabrikam.User riceve ancora una notifica sullo stato del recapito. Quindi Fabrikam.User chiama l'assistenza e riferisce il problema. Non è la prima segnalazione. Infatti, nessuno in Fabrikam è più in grado di comunicare con Adventure Works. È accaduto qualcosa. Il problema è urgente. Tentando di risolverlo rapidamente, si controllano i registri SMTP nella cartella %systemroot%\system32\Logfiles\SMTPSVC1 in INTERNET01 e, come è illustrato dal testo rosso nella Figura 3, ecco il problema.
Figure 3 I registri SMTP illustrano il problema (Close Figure 3)
... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu,
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by
ip-bl.consolidatedmessenger.com. Please visit
http://www.consolidatedmessenger.com/ip-bl for more information.
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,
La risposta di errore 550 indica che Consolidated Messenger ha inserito il proprio indirizzo IP dell'host Internet in un elenco indirizzi IP bloccati. La cosa è abbastanza ragionevole. Si contatta Consolidated Messenger per essere rimossi dall'elenco. Come si potrà constatare, è più facile essere inseriti nell'elenco di blocco di Consolidated Messenger che essere rimossi. L'eliminazione richiederà dei giorni, se non settimane.
È necessario un aiuto più rapido, così si contatta Adventure Works tramite l'indirizzo di posta elettronica cmipbl@adventure-works.com. Si invia un messaggio di posta elettronica come Fabrikam.Admin@Fabrikam.com, descrivendo la situazione e chiedendo di sbloccare l'indirizzo IP Internet dell'host (in questo caso 192.168.1.100). Dopo avere verificato l'identità, Adventure Works sblocca l'indirizzo utilizzando il comando seguente per autorizzare un'eccezione temporanea che scade automaticamente dopo 30 giorni:
Add-IPAllowListEntry -IPAddress 192.168.1.100
-ExpirationTime (get-date).AddDays(30)
Trenta giorni dovrebbero essere sufficienti per sistemare le cose con Consolidated Messenger e Adventure Works non deve perdere tempo nella manutenzione manuale dell'eccezione. Tramite la concessione di eccezioni temporanee, Adventure Works tiene al minimo l'overhead amministrativo associato alla manutenzione degli elenchi indirizzi IP consentiti.

Mittente attendibile
Quindi, è possibile testare il riconoscimento dei mittenti attendibili del filtro contenuto, una nuova e interessante funzionalità che aumenta la precisione del filtro posta indesiderata. EdgeSync propaga le informazioni sui mittenti attendibili dall'ambiente interno in formato hash e crittografato ai server Trasporto Edge. L'agente filtro contenuto utilizza queste informazioni durante il processo di filtro per prendere decisioni consapevoli. È necessario solamente ottenere informazioni sui mittenti attendibili (ovvero, elenco Mittenti attendibili, elenco Destinatari attendibili, elenco Mittenti bloccati e contatti esterni) in Active Directory® utilizzando il cmdlet Update-SafeList e replicando quindi le informazioni sul server Trasporto Edge utilizzando il cmdlet Start-EdgeSynchronization. Microsoft IT esegue il cmdlet Update-SafeList in base a una pianificazione durante gli orari di minor traffico. Nel nostro ambiente di test è sufficiente eseguire manualmente uno script corrispondente (HUB-MBX-01_update_safelist.ps1).
Per prima cosa, ripulire l'ambiente di test eseguendo lo script EDGE01_clean_up.ps1 sul server Trasporto Edge per rimuovere la voce dell'elenco indirizzi IP consentiti creata in precedenza. Ciò è necessario perché l'agente filtro contenuto non agisce sui messaggi provenienti dalle origini presenti in questo elenco. Quindi, è necessario rimuovere la voce dell'elenco indirizzi IP bloccati per 100.1.168.192.ip-bl.consolidatedmessenger.com dall'elenco di blocco di Consolidated Messenger eseguendo il file INTERNET01_clean_up.bat sull'host Internet. In caso contrario, l'host di Internet simulato non sarà in grado di inviare messaggi, come dimostrato in precedenza.
Infine, inviare un messaggio che l'agente filtro contenuto considera quasi certamente come posta indesiderata. Questo è difficile perché l'agente filtro contenuto utilizza la soglia di livello di probabilità di posta indesiderata predefinita per recapitare la maggior parte dei messaggi agli utenti al fine di ridurre al minimo i falsi positivi. Dopo vari test, ho trovato ancora una versione di messaggio che alza la valutazione della soglia del livello di probabilità di posta indesiderata al livello di rifiuto. Per inviare il messaggio come Contoso.User@Contoso.com, eseguire lo script INTERNET01_contoso_msg.vbs nell'host Internet.
Il mio script utilizza una connessione SMTP anonima per inviare il messaggio al servizio SMTP in INTERNET01. Per un funzionamento corretto, è necessario configurare il servizio SMTP per l'inoltro dei messaggi per gli utenti anonimi. In Gestione IIS, aprire le proprietà per il Server virtuale SMTP predefinito. Nella scheda relativa all'accesso, fare clic sul pulsante che consente di inoltrare i messaggi e selezionare l'opzione che consente di inviare tutto tranne l'elenco specificato. Tra breve verranno spiegate le implicazioni di questa configurazione.
Quando si esegue lo script per inviare questo messaggio, Contoso.User dovrebbe ricevere una notifica sullo stato del recapito indicante che il recapito non è riuscito con: Codice diagnostico: smtp;550 5.7.1 Messaggio rifiutato a causa di limitazioni del contenuto. È anche possibile visualizzare questa risposta nel registro SMTP nell'host Internet e se si esegue il comando Get-AgentLog | Select-Object -Last 1 sul server Trasporto Edge per visualizzare l'ultima voce del registro agente, dovrebbe essere possibile vedere che il messaggio è stato rifiutato perché il livello SCL era 7, come illustrato nella Figura 4.
Figura 4 Messaggio bloccato a causa di limitazioni del contenuto
Figura 4 Messaggio bloccato a causa di limitazioni del contenuto
Ora, Contoso.User non è uno spammer. È una sfortuna che in questo caso il messaggio non sia passato, ma Contoso.User è generalmente in grado di comunicare con i destinatari di Adventure Works. Quindi Contoso.User comunica all'amministratore in un altro messaggio di posta elettronica che il messaggio originale è stato erroneamente bloccato. L'amministratore conosce Contoso.User e, per garantire che i filtri posta indesiderata non blocchino più i suoi messaggi in futuro, aggiunge Contoso.User all'elenco Mittenti attendibili. A tal scopo in Office Outlook 2007, fare clic con il pulsante destro del mouse su un messaggio ricevuto da Contoso.User, puntare su Posta indesiderata, quindi fare clic su Aggiungi mittente all'elenco Mittenti attendibili.
All'intervallo consueto, viene eseguito il cmdlet Update-SafeList per aggiornare le informazioni degli indirizzi attendibili in Active Directory e dopo la successiva sincronizzazione di Edge, Contoso.User potrà comunicare con l'amministratore senza falsi positivi. Per simulare questa procedura, eseguire lo script HUB-MBX-01_update_safelist.ps1.
Ora eseguire lo script INTERNET01_contoso_msg.vbs per inviare di nuovo il messaggio di Contoso.User. Al termine controllare il registro agente sul server Trasporto Edge utilizzando il comando Get-AgentLog | Select-Object -Last 1 e in ReasonData è possibile notare che il filtro contenuto non è stato aggirato. I falsi positivi per Contoso.User sono così terminati.

Attacco di posta indesiderata
Concludiamo adesso il discorso sulle esecuzioni di test. Come è stato certamente notato, durante il test precedente ho configurato l'host Internet come inoltro aperto, cosa che consente l'accesso agli spammer. Vediamo quindi che cosa accade se Spam.Sender@cohovineyards.com nota questa configurazione debole e abusa dell'host per inviare migliaia di messaggi di posta indesiderata a Adventure Works. Lo script INTERNET01_spam_msg.vbs invia solo un messaggio di posta indesiderata, ma è possibile modificarlo e cambiare il valore max_loop per generare più script.
Per simulare un attacco di posta indesiderata, ho inviato 1.000 messaggi al mio host compromesso in modo che vengano inoltrati al server Trasporto Edge. Il servizio SMTP limita il numero di messaggi per la connessione in uscita a 20, quindi è stato necessario un po' di tempo per inoltrare un numero sufficiente di messaggi di posta indesiderata prima che l'agente analisi protocollo sul server Trasporto Edge ne ricevesse a sufficienza e reagisse.
L'agente analisi protocollo assiste l'agente filtro connessioni mantenendo automaticamente le voci di elenco indirizzi IP bloccati basato sull'analisi del protocollo SMTP e sugli aggiornamenti della reputazione IP di Microsoft Update. In questo caso, l'analisi del protocollo SMTP ha intercettato i messaggi di posta indesiderata. L'agente di analisi protocollo tiene traccia di ciascuna valutazione SCL di ciascun messaggio per calcolare un valore SCL medio che utilizza per determinare un livello di reputazione del mittente (SRL). All'aumentare del numero di messaggi illegittimi arrivati durante la campagna di posta indesiderata simulata, il valore SRL dell'host Internet è aumentato fino a superare la soglia di blocco SRL. Come risultato, per 24 ore l'host è andato a finire sull'elenco degli IP bloccati. Da questo host non è più arrivata posta indesiderata e la cosa è avvenuta automaticamente. Non è stato necessario alcun intervento dell'amministratore.
Nella Figura 5 viene illustrato l'elenco degli IP bloccati risultante e le modifiche corrispondenti nella gestione dei messaggi. Prima di bloccare l'host, il server Trasporto Edge ha rifiutato ciascun messaggio di posta indesiderata durante l'evento OnEndOfData perché era l'agente filtro contenuto che agiva su ciascun messaggio in base alla soglia SCL (per riferimento, vedere la Figura 4). Il messaggio è stato inviato, anche se senza successo. Dopo il blocco dell'host, la connessione è stata rifiutata dall'agente filtro connessioni durante l'evento OnMailCommand. I messaggi non vengono più inviati. Consente di risparmiare larghezza di banda di rete e risorse di elaborazione per disconnettere gli spammer prima dell'invio dei messaggi.
Figura 5 Interruzione di un host Internet dannoso
Figura 5 Interruzione di un host Internet dannoso

Ulteriori test
Naturalmente, sono disponibili numerose altre funzionalità di agente e scenari che è possibile testare. Ad esempio, è possibile testare il filtro mittente inviando messaggi come Blocked.User@Contoso.com o Blocked.User@Fabrikam.com. È possibile testare il filtro destinatario inviando messaggi a Blocked.User@adventure-works.com. È anche possibile utilizzare Telnet per simulare attacchi directory harvesting (raccolta di directory) con intervalli di tarpitting variabili. Microsoft utilizza l'intervallo predefinito di cinque secondi per le risposte 5yz SMTP sul connettore di ricezione Internet, che per Microsoft IT è una quantità di tempo sufficiente per vanificare l'efficacia degli attacchi di directory harvesting per gli spammer. Tuttavia è possibile applicare valori diversi utilizzando il cmdlet Set-ReceiveConnector, come dimostrato nello script EDGE01_tarpitting.ps1.
È anche possibile andare più a fondo e verificare i file di istantanea che vengono creati dalla traccia della pipeline per i messaggi da Contoso.User@Contoso.com. Esaminare gli indicatori dell'antivirus, X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0, utilizzato da Forefront Security per contrassegnare i messaggi sottoposti a scansione. Quando Forefront Security sul server Trasporto Hub trova questo indicatore con informazioni di versione recenti, non deve eseguire la scansione del messaggio una seconda volta. Se si tenta di ingannare Forefront Security inserendo falsi indicatori degli antivirus nei messaggi di test, è possibile osservare in azione il firewall intestazioni, che rimuove questi indicatori subito dopo l'evento OnDataCommand, molto prima che venga attivato l'evento OnSubmittedMessage che richiama l'agente routing FSE.
Mentre si esaminano le intestazioni di messaggio nei file di istantanea, è possibile decidere di creare un record di test SPF per Contoso.Com che identifica un indirizzo IP errato come mittente legittimo. Un metodo per ottenere questo risultato è l'esecuzione del file INTERNET01_wrong_SPF_record.bat nell'host Internet. Quindi è necessario inviare un messaggio di test come Contoso.User@Contoso.com e osservare l'intestazione X-MS-Exchange-Organization-SenderIdResult e Received-SPF:
X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

Conclusioni
Come si è visto in questo articolo e in quello precedente, i server Trasporto Edge di Exchange Server 2007 sono provvisti di una serie completa di agenti di trasporto per implementare funzionalità di protezione dalla posta indesiderata affidabili e di elevata precisione, tra cui filtro connessioni, analisi protocollo e filtro contenuto. L'architettura di trasporto è estendibile e supporta l'implementazione di ulteriori agenti per funzionalità aggiuntive. L'agente routing FSE è un buon esempio di agente aggiuntivo che consente di integrare Forefront Security per Exchange Server nell'architettura di trasporto.
Insieme a funzionalità aggiuntive, quali il tarpitting connessione, firewall intestazioni, TLS e autenticazione, i server Trasporto Edge offrono i mezzi necessari per ottenere un livello estremamente elevato di protezione della messaggistica a diversi livelli e senza singoli i punti di errore. Tramite la distribuzione di server Trasporto Edge e di Forefront Security in una rete perimetrale, rigorosamente separati dall'organizzazione di Exchange Server interna, è possibile tenere il flusso di contenuto illegittimo e dannoso lontano dall'ambiente di messaggistica e garantendo il recapito dei messaggi legittimi con un numero estremamente ridotto di falsi positivi per gli utenti.

Kay Unkroth è un imprenditore che ha lavorato per oltre 15 anni come Support Engineer, sviluppatore di sistema, consulente, istruttore e autore, dedicandosi principalmente alle tecnologie server di Microsoft. Kay è inoltre fondatore, nonché presidente, della Biblioso Corporation, una società specializzata in servizi gestiti di documentazione e localizzazione.


 Rete: Configurazione dell'accesso remoto VPN con ISA Server 2006
Rete Alan Maddison

Configurazione dell'accesso remoto VPN con ISA Server 2006
Panoramica:
  • Protocolli VPN
  • Configurazione di una connessione VPN da sito a sito
  • Configurazione di una connessione VPN di accesso remoto
  • Nuove funzionalità di ISA Server 2006

Le reti private virtuali (VPN) garantiscono un elevato livello di adattabilità, scalabilità e controllo sulla connettività di rete. Oltre ad assicurare una protezione più avanzata, consentono di realizzare considerevoli risparmi sui costi
rispetto alle tradizionali connessioni dedicate point-to-point. In più, sono estremamente flessibili.
Sono disponibili VPN di diversi tipi: alcune vengono utilizzate per collegare gli utenti mobili alla rete aziendale, mentre altre sono progettate per connettere due reti geograficamente separate. Le funzionalità offerte e i protocolli di cui si avvalgono le diverse reti VPN variano. In alcuni casi vengono fornite funzionalità di protezione integrate, ad esempio per l'autenticazione e la crittografia, mentre in altri non sono assolutamente previsti strumenti di questo tipo. E, naturalmente, alcune reti sono più facili da installare e gestire rispetto ad altre.
In questo articolo, illustrerò come implementare una rete VPN mediante Internet Security and Acceleration (ISA) Server 2006. In particolare, mi soffermerò sull'uso della funzionalità VPN di ISA Server per la gestione di due scenari comuni, ovvero la configurazione di connessioni VPN di accesso remoto per gli utenti e la configurazione di connessioni VPN da sito a sito. Entrambe le implementazioni prevedono funzionalità di protezione per garantire la privacy dei dati e tutelare la sicurezza delle risorse della rete interna.
Nel primo scenario, rappresentato da una connessione VPN di accesso remoto, un client remoto avvia una connessione VPN al server ISA tramite Internet. Successivamente, il server ISA collega il client remoto alla rete interna, consentendo così all'utente di accedere agevolmente alle risorse della rete, compresi dati e applicazioni. Il secondo scenario, rappresentato da una connessione VPN da sito a sito, è un po' più complesso in quanto richiede l'utilizzo di un router, che può essere lo stesso ISA. Questo tipo di connessione, tuttavia, consente di collegare facilmente uffici o succursali differenti a una sede centrale o tra loro.
Sono diversi i vantaggi che si possono ottenere utilizzando ISA Server 2006 per implementare una rete VPN. Uno dei più significativi deriva dalla natura integrata che caratterizza questa soluzione, grazie alla quale le funzionalità VPN e firewall operano in perfetta sinergia. Inoltre, in ISA Server è disponibile una funzionalità di quarantena VPN, basata su Controllo quarantena accesso alla rete di Windows Server® 2003, che permette di mettere in quarantena un computer di accesso remoto finché la relativa configurazione non viene convalidata da uno script sul lato server. Questa funzionalità aggiunge un ulteriore livello di protezione in quanto offre la possibilità di eseguire alcune importanti verifiche sul computer remoto, ad esempio relativamente allo stato della definizione dell'antivirus e ai criteri firewall locali, prima di consentire l'accesso alle risorse della rete interna.
Tra i vantaggi più significativi offerti sul piano amministrativo da ISA Server come soluzione VPN figurano le varie funzionalità disponibili per la gestione dei criteri, il monitoraggio, la registrazione e la creazione di rapporti a livello centralizzato. Per lo svolgimento delle mansioni amministrative quotidiane, tali funzionalità possono rivelarsi estremamente preziose. In particolare, il monitoraggio in tempo reale e il filtro dei registri offrono informazioni critiche sulle connessioni e il traffico di rete che passano attraverso ISA Server.

Protocolli VPN
I principali protocolli di tunneling utilizzati in una connessione VPN ISA rappresentano la prima linea di difesa per la protezione delle connessioni. ISA Server supporta tre protocolli: Layer 2 Tunneling Protocol (L2TP) su IPsec, Point-to-Point Tunneling Protocol (PPTP) e la modalità tunnel di IPsec. Quest'ultimo protocollo è supportato unicamente per le connessioni da sito a sito ed è utilizzato essenzialmente per l'interoperabilità con i router e con altri sistemi operativi non compatibili con L2TP o PPTP.
L2TP non dispone di meccanismi per tutelare la privacy dei dati ed è per questa ragione che viene utilizzato in combinazione con IPsec, che offre invece metodi di autenticazione e di crittografia altamente affidabili. Insieme, i due protocolli formano una soluzione vincente. PPTP utilizza Microsoft® Challenge Handshake Authentication Protocol (MS CHAP) versione 2 o Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) per l'autenticazione e Microsoft Point-to-Point Encryption (MPPE), naturalmente, per la crittografia.
Per un'organizzazione, la scelta della soluzione più appropriata tra i protocolli L2TP su IPsec e PPTP dipende spesso da fattori che sono specifici dell'organizzazione stessa. L2TP su IPsec consente di utilizzare sistemi di crittografia più complessi e sofisticati e supporta una gamma più ampia reti, tra cui IP, X.25, Frame Relay e ATM. Tuttavia, PPTP è più facile da implementare e in genere presenta di meno requisiti. Detto ciò, in situazioni in cui non esistono vincoli peculiari a livello di organizzazione, è preferibile scegliere L2TP rispetto a IPsec.

Connessione VPN da sito a sito
In ISA Server 2006 sono stati fatti considerevoli progressi ai fini di semplificare l'installazione di una rete VPN da sito a sito. Nelle versioni precedenti, infatti, il numero di passaggi richiesti era di gran lunga superiore. Per questo esempio, prenderò in esame il caso di un unico sito remoto che viene collegato a un ufficio centrale mediante il protocollo L2TP su IPsec, con un server ISA in entrambe le posizioni. Il processo richiede che la configurazione del server ISA dell'ufficio centrale preceda la configurazione del sito remoto.
Il primo passaggio da mettere in atto consiste nel configurare gli account utente locali necessari in entrambi i server ISA. Tale identità utente fornirà il contesto di protezione in cui verrà eseguita la connessione al server ISA principale o remoto. Il nome dell'account deve corrispondere al nome della connessione VPN che viene creata all'interno della console di amministrazione ISA. Ad esempio, una buona convenzione di denominazione può essere quella di impostare come nome utente "Site VPN" nel server ISA della sede centrale, che punta al sito remoto, e "HQ VPN" nel server ISA remoto. Una volta creati questi account, è necessario accedere alle relative proprietà, aprire la scheda relativa alle connessioni remote e accertarsi che l'opzione che consente l'accesso sia selezionata.
Il passaggio successivo consiste nel creare il certificato di infrastruttura a chiave pubblica (PKI) che verrà utilizzato per l'autenticazione tra i due siti. Eventualmente, è possibile anche scegliere di utilizzare una chiave già condivisa, tuttavia un certificato è sempre preferibile. Il metodo più semplice per installare un certificato per una connessione VPN consiste nel collegarsi direttamente alla propria autorità di certificazione Enterprise e richiederne uno mediante il sito Web del server dei certificati. Per fare questo, però, può rendersi necessario creare una regola di accesso che consenta al server ISA di collegarsi al server dei certificati via HTTP.
Se si ha dimestichezza con le versioni precedenti di ISA Server, si noterà senz'altro che l'interfaccia di ISA Server 2006, illustrata nella Figura 1, è di gran lunga più intuitiva. Quando si seleziona VPN nel riquadro a sinistra, nei due riquadri al centro e a destra vengono visualizzate le opzioni sensibili al contesto relative alla configurazione e alle attività.
Figura 1 L'interfaccia di ISA Server 2006 è molto più intuitiva
Figura 1 L'interfaccia di ISA Server 2006 è molto più intuitiva
Avviare la procedura guidata per le reti VPN da sito a sito facendo clic sull'attività Crea connessione VPN da sito a sito nel riquadro a destra. Verrà richiesto di immettere il nome che si desidera assegnare alla rete; tale nome deve corrispondere a quello dell'account utente creato precedentemente. Dopo aver inserito il nome, fare clic sul pulsante Avanti. Nella schermata successiva (vedere la Figura 2), selezionare il protocollo VPN da utilizzare, che nel mio esempio è L2TP su IPsec, quindi fare clic su Avanti. Al termine, verrà visualizzato un messaggio in cui si avvisa che l'account utente corrispondente al nome della rete deve essere disponibile. Se si è seguito con attenzione quanto su esposto e si è creato l'account nel modo suggerito, sarà sufficiente fare clic su OK per accedere alla schermata successiva.
Figura 2 Selezione del protocollo VPN da utilizzare
Figura 2 Selezione del protocollo VPN da utilizzare
A questo punto è necessario creare un pool di indirizzi IP. Le possibilità a disposizione sono due: creare un pool di indirizzi statici sul server ISA oppure utilizzare il server DHCP esistente per gestire l'assegnazione degli indirizzi. Poiché entrambi i metodi sono accettabili, la scelta della soluzione più appropriata deve tener conto delle specifiche procedure aziendali in materia. All'utente verrà richiesto di immettere il nome del server remoto. Specificare il nome di dominio completo (FQDN) del server e, successivamente, le credenziali utente per la connessione. Si ricordi che è necessario immettere in questo passaggio le informazioni sull'account utente create nel server ISA remoto. Nell'esempio in esame, l'account utente in questione è HQ VPN, come illustrato nella Figura 3.
Figura 3 Immissione del nome FQDN del server remoto
Figura 3 Immissione del nome FQDN del server remoto
Nella schermata successiva, selezionare il metodo di autenticazione in uscita (come detto in precedenza, è sempre preferibile scegliere un certificato). Immettere quindi l'intervallo di indirizzi IP utilizzato nella rete interna presso il sito remoto.
Al termine, se si sta utilizzando ISA Server 2006 Enterprise Edition, sarà possibile configurare gli indirizzi IP dedicati relativi al bilanciamento carico di rete per il sito remoto. Se invece si sta utilizzando ISA Server 2006 Standard Edition, ignorare il passaggio riguardante il bilanciamento del carico di rete e accedere direttamente alla schermata successiva (vedere la Figura 4), in cui è possibile creare la regola di rete per l'instradamento del traffico dal sito remoto alla rete locale.
Figura 4 Creazione della regola di rete per l'instradamento del traffico
Figura 4 Creazione della regola di rete per l'instradamento del traffico
È necessario creare anche una regola di accesso ed è questo il passaggio successivo della procedura. Quando si configura la regola di accesso, sono disponibili tre opzioni per l'utilizzo dei protocolli: è possibile consentire tutto il traffico in uscita oppure tutto il traffico in uscita ad eccezione di alcuni protocolli o infine consentire solo alcuni protocolli. Nella maggior parte delle situazioni è preferibile selezionare l'opzione per consentire tutto il traffico in uscita.
La procedura è quasi terminata. A questo punto, verrà mostrato un riepilogo della configurazione definita e, non appena l'utente avrà fatto clic sul pulsante Fine, verrà creata la connessione VPN da sito a sito. Successivamente verrà visualizzata una nuova finestra di dialogo per segnalare che è necessario attivare una regola dei criteri di sistema per i download di Certificate Revocation List: fare clic su Sì per attivare la regola. La procedura guidata fornirà quindi informazioni su eventuali altri passaggi di configurazione che potrebbe essere necessario implementare. Una volta completata la configurazione di ISA Server presso il sito principale, occorrerà seguire la stessa procedura per configurare il sito remoto. Quando entrambe le procedure saranno completate, gli utenti di entrambi i siti saranno in grado di comunicare attraverso la rete VPN.

Connessione VPN di accesso remoto
La configurazione di una connessione VPN di accesso remoto per l'accesso client è decisamente più semplice (vedere la Figura 5). Il primo passaggio consiste nel selezionare VPN nel riquadro a sinistra della console di amministrazione di ISA Server. Successivamente è necessario selezionare nel riquadro a destra l'attività denominata Attiva accesso client VPN. A questo punto, verrà visualizzato un avviso in cui si segnala che tale operazione può causare il riavvio del servizio Routing e Accesso remoto. Poiché possono verificarsi problemi di connessione, è consigliabile implementare questa modifica durante un processo di manutenzione pianificato. Fare clic su OK per chiudere l'avviso; ISA Server attiva un criterio di sistema che consente l'accesso del traffico client VPN al server ISA. È possibile visualizzare questa regola selezionando prima Criterio firewall nella console di amministrazione di ISA Server e successivamente l'attività Mostra regole criteri di sistema.
Figura 5 Configurazione di una connessione VPN di accesso remoto
Figura 5 Configurazione di una connessione VPN di accesso remoto
Viene inoltre attivata una regola di rete predefinita per consentire l'instradamento del traffico tra la rete interna e le due reti VPN (Client VPN e Client VPN in quarantena). Tale regola può essere visualizzata o modificata selezionando Reti nel riquadro sinistro e quindi aprendo la scheda Regole rete nel riquadro centrale.
Il passaggio successivo è la configurazione dell'accesso client VPN. In particolare, è necessario configurare tre parametri aggiuntivi: i gruppi di protezione di Windows cui è permesso l'accesso, i protocolli che possono essere utilizzati dai client e il mapping utente. La finestra di dialogo per la configurazione di questi parametri viene mostrata nella Figura 6.
Figura 6 Configurazione dell'accesso client VPN
Figura 6 Configurazione dell'accesso client VPN
Nella scheda Gruppi è necessario semplicemente selezionare i gruppi di Windows a cui si desidera consentire l'accesso remoto tramite VPN. Da un punto di vista amministrativo, ritengo sia una buona idea creare un unico gruppo cui concedere l'autorizzazione. In tal modo infatti si semplifica considerevolmente la gestione dell'accesso remoto.
Nella scheda Protocolli risulta abilitato per impostazione predefinita solo PPTP. È senz'altro consigliabile abilitare L2TP su IPsec, se compatibile con l'ambiente in uso.
La scheda Mapping utente consente di eseguire il mapping degli account utente dagli spazi dei nomi, ad esempio RADIUS (Remote Authentication Dial-In User Service), agli account Windows, in modo da garantire che i criteri di accesso vengano applicati correttamente. Una volta completata l'impostazione di queste opzioni di configurazione e applicate le modifiche necessarie a ISA Server, la procedura è terminata. A questo punto i client dovrebbero essere in grado di accedere facilmente ai dati e alle applicazioni della rete interna utilizzando una connessione VPN.

Novità e miglioramenti di ISA Server 2006
In ISA Server 2006 sono stati introdotti numerosi e significativi miglioramenti che ne incrementano l'efficienza e le prestazioni rispetto alle versioni precedenti. Le nuove funzionalità, tra cui la compressione HTTP, il servizio di trasferimento intelligente in background (BITS, Background Intelligent Transfer Service) e la qualità del servizio (QoS, Quality of Service), offrono svariate tecniche per ottimizzare l'uso della rete. Naturalmente, anche sfruttando questo ulteriore supporto, è necessario continuare a utilizzare le tecnologie comuni per l'ottimizzazione della larghezza di banda che sono integrate in ISA Server, come la memorizzazione nella cache.
La compressione HTTP è supportata in numerosi prodotti Microsoft già da qualche tempo, ad esempio in Internet Explorer® a partire dalla versione 4 e in Windows Server a partire da Windows® 2000. Questa è, tuttavia, la prima versione di ISA Server che offre supporto per tale tipo di compressione, nonché per gli algoritmi standard del settore GZIP e Deflate.
Cosa significa tutto ciò? Grazie al supporto per la compressione HTTP, un browser Web compatibile con HTTP 1.1 può richiedere contenuto compresso da qualsiasi sito Web. Si ricordi, tuttavia, che solo le risposte vengono compresse, non le connessioni iniziali in uscita dal client.
La compressione HTTP rientra tra le impostazioni dei criteri HTTP globali e si applica a tutto il traffico HTTP che passa attraverso ISA Server, anziché essere associato a una regola di rete specifica. È possibile, tuttavia, implementarla per singolo listener, eseguendo tale configurazione mediante la Creazione guidata listener Web.
La compressione HTTP, a cui è possibile accedere mediante l'opzione Generale nel riquadro a sinistra, è attivata per impostazione predefinita. Come mostra la Figura 7, per poterla utilizzare è necessario però configurare gli elementi di rete cui si desidera applicarla. Nell'esempio della rete VPN da sito a sito, è necessario selezionare la scheda Restituisci dati compressi e aggiungere l'elemento di rete Site VPN precedentemente creato. A questo punto è possibile anche configurare i tipi di contenuto da comprimere. In ISA Server 2006 è già disponibile un elenco di tipi standard, ma si possono aggiungere altri tipi di contenuto personalizzati mediante il riquadro attività Criterio firewall nella scheda Casella degli strumenti. Si tenga presente la scheda Restituisci dati compressi va selezionata se si desidera che ISA Server comprima i dati prima che vengano restituiti al client. Per richiedere invece che un server Web gestisca la compressione dei dati prima che questi vengano inviati a ISA Server, è necessario utilizzare la scheda Richiedi dati compressi.
Figura 7 Configurazione della compressione HTTP
Figura 7 Configurazione della compressione HTTP
BITS è un servizio di trasferimento file asincrono per la gestione del traffico HTTP e HTTPS. Windows Server 2003 include la versione 1.5 di tale servizio, che supporta le operazioni sia di download che di caricamento dei file, sebbene il caricamento richieda anche la disponibilità di Internet Information Services (IIS) versione 5.0 o superiore. Trattandosi di un servizio di trasferimento file intelligente, BITS è in grado di esaminare il traffico di rete e utilizzare unicamente la larghezza di banda inattiva. Inoltre, il trasferimento dei file è dinamico e BITS reagirà a eventuali picchi del traffico normale limitando l'utilizzo della rete. Il vantaggio è che BITS assicura che le operazioni di download e caricamento dei file non influiranno negativamente sull'utilizzo della rete. Dal punto di vista amministrativo, ciò significa che si dovrebbero ricevere meno chiamate di reclamo da parte di utenti che registrano un calo delle prestazioni di rete. Un ottimo risultato, direi!
BITS offre anche altri vantaggi che consentono di migliorare l'esperienza utente e di ottimizzare le prestazioni di rete. Ad esempio, un trasferimento file che utilizza questo servizio è binario, vale a dire che BITS è in grado di riprendere operazioni di trasferimento che sono state interrotte in seguito a problemi di varia natura, come un'interruzione della connettività, senza che sia necessario riavviare il processo dall'inizio. Inoltre, ISA Server 2006 include supporto incorporato per una funzionalità di memorizzazione nella cache di Microsoft Update che utilizza la memorizzazione nella cache del servizio BITS per ottimizzare gli aggiornamenti.
Il protocollo DiffServ (Differentiated Services) consente l'impostazione della priorità dei pacchetti (o QoS) per il traffico HTTP e HTTPS. In altre parole, a seconda della configurazione di ISA Server, verrà assegnata la priorità a un tipo di traffico specifico. Ciò risulta particolarmente utile nel caso di reti che dispongono di una larghezza di banda limitata, a causa del volume del traffico o della velocità di connessione. Secondo l'Internet Engineering Task Force (IETF), DiffServ è un meccanismo di gestione del traffico basato su classi. Pertanto, è in grado di distinguere tra i diversi tipi di traffico e gestirli di conseguenza, assicurando sempre la precedenza al traffico ad alta priorità.
Per offrire tale funzionalità, ISA Server collabora con i router che supportano QoS. È importante assicurarsi che i bit DiffServ di ISA Server corrispondano alle priorità definite nei router in uso se si desidera che i pacchetti vengano instradati con la stessa impostazione della priorità.
In ISA Server, questo tipo di impostazione della priorità dei pacchetti rientra tra le impostazioni dei criteri HTTP globali e si applica a tutto il traffico HTTP che passa attraverso ISA Server 2006 mediante un filtro Web DiffServ. Ciò significa che ISA Server non supporta DiffServ per altri protocolli e può, in effetti, eliminare bit DiffServ esistenti nel traffico non HTTP.
Come illustrato nella Figura 8, DiffServ viene implementato come filtro Web ed è possibile accedervi selezionando Componenti aggiuntivi nel riquadro sinistro. È importante non modificare le impostazioni predefinite o l'ordine di priorità del filtro DiffServ data la necessità per ISA Server di controllare le dimensioni della richiesta/risposta nel momento in cui viene elaborata.
Figura 8 Visualizzazione del filtro Web DiffServ
Figura 8 Visualizzazione del filtro Web DiffServ
Se si osserva attentamente la Figura 8, si noterà che il filtro DiffServ non è attivato per impostazione predefinita. Per attivare il filtro, selezionare l'opzione che consente di attivare i filtri selezionati nel riquadro Attività, quindi configurare il filtro. Dal momento che l'impostazione della priorità dei pacchetti DiffServ in ISA Server è basata su URL o domini specifici, è necessario immettere gli URL o i domini in questione nelle preferenze DiffServ. A tale scopo, selezionare Generale nel riquadro sinistro della console di gestione e quindi, in Impostazioni dei criteri HTTP globali, scegliere Specifica preferenze Diffserv. Quando si impostano tali preferenze, è necessario definire le priorità e gli URL e i domini a cui si desidera applicarle. ISA Server 2006 offre un'ampia gamma di nuove, potenti funzionalità per la configurazione dell'accesso remoto per i client VPN o la creazione di reti VPN da sito a sito e rappresenta pertanto la scelta ideale per chi desidera implementare una soluzione VPN.

Alan Maddison è consulente senior del reparto Microsoft Technology Practice di MTI Technology Corporation. Il principale centro di interesse della sua attività è rappresentato da Active Directory, Server Exchange e dalla virtualizzazione.


 SQL Server: Ottimizzazione delle prestazioni delle query in SQL Server
SQL Server Maciej Pilecki

Ottimizzazione delle prestazioni delle query in SQL Server
Panoramica:
  • Analisi dei piani di esecuzione
  • Ottimizzazione delle query
  • Identificazione delle query da ottimizzare

Quando si ottimizza il server di database, è necessario ottimizzare le prestazioni delle singole query. Questo è forse più importante dell'ottimizzazione di altri aspetti dell'installazione server che influiscono sulle prestazioni, come le configurazioni hardware e software.
Anche se il server di database viene eseguito sull'hardware più potente a disposizione, il comportamento anomalo di alcune query può influire in modo negativo sulle prestazioni. Di fatto, anche una sola query difettosa, spesso indicata col termine di "query runaway", può causare gravi problemi alle prestazioni di un database.
Viceversa, le prestazioni complessive del database possono essere migliorate notevolmente ottimizzando una serie di query più dispendiose o eseguite più di frequente. In questo articolo verranno esaminate alcune delle tecniche a disposizione per identificare e ottimizzare le query più dispendiose e meno efficienti in esecuzione su un server.

Analisi dei piani di esecuzione
L'ottimizzazione di una query inizia in genere dall'esame del relativo piano di esecuzione. Il piano di esecuzione descrive la sequenza delle operazioni, fisiche e logiche, che verranno eseguite da SQL ServerTM per soddisfare la query e produrre i risultati desiderati. Il piano di esecuzione viene prodotto da un componente del motore di database, definito Query Optimizer, durante la fase di ottimizzazione dell'elaborazione della query: questo tiene conto di molti fattori diversi, come i predicati di ricerca utilizzati nella query, le tabelle utilizzate e le relative condizioni di join, l'elenco delle colonne restituite e la presenza di indici utili che possono fungere da percorsi di accesso efficienti ai dati.
Nel caso delle query complesse, il numero di tutte le permutazioni possibili può essere elevato, quindi Query Optimizer non valuta tutte le possibilità ma tenta invece di trovare un piano che sia "sufficientemente buono" per una determinata query. Quanto appena detto è dovuto al fatto che l'individuazione di un piano perfetto non sempre è possibile e anche se lo è, il costo della valutazione di tutte le possibilità per trovare il piano perfetto potrebbe non essere compensato dagli eventuali guadagni a livello di prestazioni. Dal punto di vista di un DBA, è importante comprendere il processo e le relative limitazioni.
Esistono vari modi per recuperare un piano di esecuzione per una query:
  • Management Studio fornisce le funzionalità di visualizzazione del piano di esecuzione effettivo e del piano di esecuzione stimato, che forniscono una rappresentazione grafica del piano. Queste funzionalità offrono la soluzione più adeguata per l'esame diretto e costituiscono di gran lunga l'approccio più diffuso per visualizzare e analizzare i piani di esecuzione. In questo articolo gli esempi proposti saranno illustrati utilizzando i piani grafici generati in questo modo.
  • Varie opzioni SET, quali SHOWPLAN_XML e SHOWPLAN_ALL, restituiscono il piano di esecuzione sotto forma di documento XML che descrive il piano utilizzando uno schema speciale o un set di righe con la descrizione testuale di ciascuna delle operazioni contenute.
  • Le classi di evento di SQL Server Profiler, come Showplan XML, consentono di raggruppare piani di esecuzione delle istruzioni raccolte da una traccia.
Anche se una rappresentazione XML del piano di esecuzione può non costituire il formato di lettura più semplice, tale opzione consente di scrivere procedure e utilità in grado di analizzare i piani di esecuzione, alla ricerca di segni che indicano problemi di prestazioni e piani non ottimali. Una rappresentazione XML può anche essere salvata su un file con estensione sqlplan e poi aperta in Management Studio per produrre una rappresentazione grafica. Questi file possono anche essere salvati per analisi successive, eliminando ovviamente la necessità di riprodurre il piano di esecuzione ogni volta che si desidera analizzarlo. Ciò è particolarmente utile per confrontare i piani allo scopo di rilevarne l'evoluzione nel tempo.

Costo di esecuzione stimato
La prima cosa da comprendere dei piani di esecuzione è il modo in cui vengono generati. SQL Server utilizza uno strumento di ottimizzazione delle query basato sul costo, che tenta di generare un piano di esecuzione con il minimo costo stimato. La stima è basata sulle statistiche di distribuzione dei dati che sono disponibili per Query Optimizer quando questo valuta ogni tabella interessata dalla query. Se queste statistiche non sono disponibili o non sono aggiornate, Query Optimizer sarà privo delle informazioni necessarie per il processo di ottimizzazione della query e quindi le stime non saranno corrette. In questi casi, Query Optimizer sceglierà un piano non ottimale stimando per eccesso o per difetto i costi di esecuzione di piani diversi.
Sul costo di esecuzione stimato esistono alcune convinzioni errate. In particolare, spesso le persone presumono che il costo di esecuzione stimato sia un buon indicatore del tempo necessario per l'esecuzione della query e che questa stima consenta di distinguere i piani efficienti da quelli meno efficienti. Ovviamente si tratta di una percezione errata. Innanzitutto, le unità di misura adottate per esprimere il costo stimato sono documentate a sufficienza così come l'eventuale relazione diretta con il tempo di esecuzione. In secondo luogo, trattandosi di una stima che può quindi essere suscettibile di errore, i piani con costi più alti possono a volte essere più efficienti in termini di CPU, I/O e tempo di esecuzione, malgrado le relative stime più alte. Questo è spesso il caso delle query che coinvolgono variabili di tabella, per le quali non sono disponibili statistiche, e quindi Query Optimizer presuppone sempre che una variabile di tabella contenga solo una riga, anche se ne contiene di più. Di conseguenza, Query Optimizer sceglierà un piano basato su una stima imprecisa. Di conseguenza, quando si confrontano i piani di esecuzione delle query, non si deve fare affidamento sul solo costo stimato. È necessario includere invece nell'analisi l'output delle opzioni STATISTICS I/O e STATISTICS TIME per comprendere il costo reale di esecuzione in termini di I/O e tempo della CPU.
Vale la pena citare qui un tipo speciale di piano di esecuzione, definito piano parallelo. Se la query viene eseguita su un server con più di una CPU ed è idonea per la parallelizzazione, è possibile scegliere un piano parallelo. In generale, Query Optimizer prende in considerazione un piano parallelo per una query con un costo superiore a una determinata soglia configurabile. A causa dell'overhead legato alla gestione di più thread di esecuzione paralleli, che comporta un lavoro di distribuzione dei thread, la sincronizzazione e raccolta dei risultati, il costo di esecuzione dei piani paralleli è maggiore e questo si riflette sul relativo costo stimato. Perché quindi sono preferiti rispetto ai piani non paralleli meno costosi? Grazie all'utilizzo della potenza di elaborazione di più CPU, i piani paralleli tendono a produrre risultati più veloci rispetto ai piani standard. A seconda dello scenario specifico, comprendente variabili quali le risorse disponibili e il carico concorrente di altre query, questa situazione può rivelarsi preferibile. In tal caso, è necessario controllare quale delle query è in grado di produrre piani paralleli e il numero di CPU utilizzate da ciascuna. A tal fine, è necessario impostare l'opzione del grado massimo di parallelismo a livello di server ed eseguire l'override a livello della singola query tramite OPTION (MAXDOP n) in base alle esigenze.

Analisi di un piano di esecuzione
Ora verrà esaminata una semplice query, il relativo piano di esecuzione e alcuni metodi per migliorarne le prestazioni. Supponiamo di eseguire questa query utilizzando Management Studio con l'opzione Includi piano di esecuzione effettivo attivata nel database di esempio Adventure Works in SQL Server 2005:
SELECT c.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
JOIN Sales.Customer c ON oh.CustomerID=c.CustomerID
GROUP BY c.CustomerID
Il risultato è il piano esecuzione descritto nella Figura 1. Questa semplice query calcola l'importo totale degli ordini eseguiti da ciascun cliente di Adventure Works. Esaminando il piano di esecuzione, si può notare il modo in cui il motore di database elabora la query e produce il risultato. I piani di esecuzione grafici devono essere letti dall'alto verso il basso e da destra verso sinistra. Ogni icona rappresenta un'operazione logica e fisica eseguita e le frecce indicano il flusso dei dati tra le operazioni. Lo spessore delle frecce rappresenta il numero di righe passate tra le operazioni: più spessa è la freccia, maggiore è il numero di righe coinvolte. Se si posiziona il puntatore su una delle icone di operatore, viene visualizzata una descrizione comando, simile a quella illustrata nella Figura 2, che descrive l'operazione.
Figura 1 Piano di esecuzione di esempio
Figura 1 Piano di esecuzione di esempio
Figura 2 Dettagli di un'operazione
Figura 2 Dettagli di un'operazione
Esaminando ciascun operatore, è possibile analizzare la sequenza dei passaggi eseguiti:
  1. Il motore di database esegue un'operazione Clustered Index Scan sulla tabella Sales.Customer e restituisce la colonna CustomerID per tutte le righe nella tabella.
  2. Quindi viene eseguita un'operazione Index Scan, non Clustered Index Scan, su uno degli indici nella tabella Sales.SalesOrderHeader. Questo è un indice sulla colonna CustomerID, ma include implicitamente anche la colonna SalesOrderID, la chiave di clustering della tabella. La scansione restituisce i valori da entrambe le colonne.
  3. Viene eseguito il join dell'output di entrambe le scansioni nella colonna CustomerID utilizzando l'operatore fisico Merge Join. Questo è uno dei tre possibili metodi di esecuzione di un'operazione di join logico, veloce ma che richiede che entrambi gli input siano ordinati in una colonna di join. In questo caso, entrambe le operazioni di scansione hanno già restituito le righe ordinate su CustomerID evitando così ulteriori operazioni di ordinamento.
  4. Quindi, il motore di database esegue una scansione dell'indice cluster nella tabella Sales.SalesOrderDetail, recuperando i valori di quattro colonne (SalesOrderID, OrderQty, UnitPrice e UnitPriceDiscount) da tutte le righe nella tabella. La stima prevedeva la restituzione di 123.317 righe da questa operazione e questo è il numero effettivamente restituito, come si può notare dalle proprietà Numero stimato di righe e Numero effettivo di righe illustrate nella Figura 2, confermando che la stima era estremamente precisa.
  5. Le righe prodotte dalla scansione dell'indice cluster vengono passate al primo operatore Compute Scalar in modo che il valore della colonna calcolata LineTotal può essere calcolato per ogni riga, in base alle colonne OrderQty, UnitPrice e UnitPriceDiscount coinvolti nella formula.
  6. Il secondo operatore Compute Scalar applica la funzione ISNULL al risultato del calcolo precedente, come richiesto dalla formula della colonna calcolata. In questo modo viene completato il calcolo della colonna LineTotal e lo restituisce, insieme alla colonna SalesOrderID, all'operatore successivo.
  7. L'output dell'operatore Merge Join nel passaggio 3 viene unito con l'output dell'operatore Compute Scalar del passaggio 6, utilizzando l'operatore fisico Hash Match.
  8. Viene quindi applicato un altro operatore Hash Match per raggruppare le righe restituite da Merge Join tramite il valore della colonna CustomerID e l'aggregato SUM calcolato della colonna LineTotal.
  9. L'ultimo nodo, SELECT, non è un operatore fisico o logico ma un segnaposto che rappresenta i risultati e il costo complessivo della query.
Sul mio computer portatile, il costo stimato di questo piano di esecuzione era di 3,31365, come illustrato nella Figura 3. Eseguita con STATISTICS I/O ON, la query ha riportato l'esecuzione di un totale di 1.388 operazioni di lettura logiche tra le tre tabelle coinvolte. Le percentuali visualizzate sotto ciascuno degli operatori rappresentano il costo di ogni singolo operatore relativo al costo complessivo stimato dell'intero piano di esecuzione. Osservando il piano illustrato nella Figura 1, si può notare che la maggior parte del costo totale dell'intero piano di esecuzione è associata ai tre operatori seguenti: Clustered Index Scan della tabella Sales.SalesOrderDetail e i due operatori Hash Match. Prima di passare alla relativa ottimizzazione, vale però la pena rilevare una modifica molto semplice alla query che consentirà di eliminare del tutto due degli operatori.
Figura 3 Costo di esecuzione totale stimato della query
Figura 3 Costo di esecuzione totale stimato della query
Poiché l'unica colonna restituita dalla tabella Sales.Customer è CustomerID e questa colonna è anche inclusa come chiave esterna in Sales.SalesOrderHeaderTable, è possibile eliminare completamente la tabella Customer dalla query senza modificare il significato logico o il risultato prodotto dalla query utilizzando il codice seguente:
SELECT oh.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Questo determina un piano di esecuzione diverso, che è illustrato nella Figura 4.
Figura 4 Il piano di esecuzione dopo l'eliminazione della tabella Customer dalla query
Figura 4 Il piano di esecuzione dopo l'eliminazione della tabella Customer dalla query
Due operazioni sono state eliminate interamente, Clustered Index Scan sulla tabella Customer e Merge Join tra Customer e SalesOrderHeader, e l'operazione di join Hash Match è stata sostituita dalla più efficiente operazione Merge Join. Tuttavia, per utilizzare Merge Join tra le tabelle SalesOrderHeader e SalesOrderDetail, le righe di entrambe le tabelle dovevano essere restituite secondo l'ordine della colonna di join SalesOrderID. Per ottenere questo risultato, Query Optimizer ha deciso di eseguire un'operazione Clustered Index Scan sulla tabella SalesOrderHeader invece di Index Scan non cluster, che avrebbe comportato un costo inferiore in termini di I/O. Questo è un buon esempio del funzionamento pratico di Query Optimizer: poiché i risparmi derivanti dalla modifica del metodo fisico di esecuzione dell'operazione di join erano superiori al costo di I/O aggiuntivo generato dall'operazione Clustered Index Scan, Query Optimizer ha scelto la combinazione risultante di operatori perché fornivano il costo di esecuzione stimato più basso possibile. Sul mio computer portatile, anche se il numero di letture logiche è aumentato (fino a 1.941), il tempo di CPU utilizzato è stato effettivamente inferiore e il costo di esecuzione stimato di questa query è stato ridotto di circa il 13% (2,89548).
Supponiamo di voler migliorare ulteriormente le prestazioni di questa query. Esaminiamo quindi Clustered Index Scan della tabella SalesOrderHeader, l'operatore più dispendioso nel piano di esecuzione. Poiché per soddisfare la query sono necessarie solo due colonne di questa tabella, è possibile creare un indice non cluster che contiene solo due colonne, sostituendo la scansione dell'intera tabella con una scansione del più piccolo indice non cluster. La definizione dell'indice può essere simile alla seguente:
CREATE INDEX IDX_OrderDetail_OrderID_TotalLine
ON Sales.SalesOrderDetail (SalesOrderID) INCLUDE (LineTotal)
Si noti che l'indice creato comprende una colonna calcolata. A seconda della definizione della colonna calcolata, questo non è sempre possibile.
Dopo la creazione di questo indice e l'esecuzione della stessa query, si ottiene il nuovo piano di esecuzione illustrato nella Figura 5.
Figura 5 Piano di esecuzione ottimizzato
Figura 5 Piano di esecuzione ottimizzato
La scansione dell'indice cluster sulla tabella SalesOrderDetail è stata sostituita da una scansione dell'indice non cluster con una riduzione significativa del costo di I/O. È stato eliminato anche uno degli operatori Compute Scalar, in quanto l'indice comprende già un valore calcolato della colonna LineTotal. Il costo del piano di esecuzione stimato è ora 2,28112 e quando viene elaborata la query esegue 1.125 letture logiche.

Indice di copertura
Esercizio sulle query degli ordini clienti
D Di seguito viene proposto l'esercizio sulle query degli ordini clienti: scoprire la definizione di indice, quali colonne deve contenere per diventare l'indice di copertura di questa query e se l'ordine delle colonne nella definizione di indice comporta una differenza nelle prestazioni.
R Ho proposto di scoprire l'indice di copertura ottimale da creare nella tabella Sales.SalesOrderHeader per la query di esempio illustrata nel mio articolo. A tal fine, la prima cosa da osservare è che la query utilizza solo due colonne dalla tabella: CustomerID e SalesOrderID. Se l'articolo è stato letto con attenzione, si noterà che nel caso della tabella SalesOrderHeader, esiste già un indice che copre questa query: si tratta dell'indice su CustomerID che contiene implicitamente la colonna SalesOrderID, la chiave di clustering della tabella.
Ovviamente è stato spiegato anche perché Query Optimizer ha deciso di non utilizzare questo indice. Sì, è possibile imporre a Query Optimizer di utilizzarlo, ma la soluzione sarebbe meno efficiente rispetto al piano esistente che utilizza gli operatori Clustered Index Scan e Merge Join perché Query Optimizer verrebbe obbligato a scegliere tra l'esecuzione di un'operazione di ordinamento aggiuntiva per essere in grado di utilizzare ancora Merge Join o l'utilizzo di un'operazione Hash Join meno efficiente. Il costo di esecuzione stimato di entrambe le opzioni è maggiore rispetto al piano esistente (le prestazioni della versione con l'operazione di ordinamento sarebbero particolarmente scadenti), quindi Query Optimizer non le utilizzerà se non viene imposto diversamente. Pertanto, in questa situazione, l'unico indice che garantirà prestazioni migliori rispetto a Clustered Index Scan è un indice non cluster su SalesOrderID, CustomerID. È tuttavia importante notare che le colonne devono essere nell'ordine esatto:
CREATE INDEX IDX_OrderHeader_SalesOrderID_CustomerID
ON Sales.SalesOrderHeader (SalesOrderID, CustomerID)
Se viene creato questo indice, il piano di esecuzione conterrà l'operatore Index Scan e non Clustered Index Scan. Questa è una differenza significativa. In questo caso, l'indice non cluster contenente solo due colonne è molto più piccolo dell'intera tabella nella forma di indice cluster. Di conseguenza, richiederà un I/O inferiore per leggere i dati necessari.
Quest'esempio dimostra anche l'impatto che l'ordine delle colonne nell'indice può avere sull'utilità per Query Optimizer. Ricordarsi questo concetto quando si progettano indici su più colonne.

L'indice creato su SalesOrderDetail è un esempio del cosiddetto "indice di copertura". Si tratta di un indice non cluster che contiene tutte le colonne necessarie per soddisfare la query, eliminando l'esigenza di eseguire la scansione dell'intera tabella gli operatori Table Scan o Clustered Index Scan. L'indice è sostanzialmente una copia più piccola della tabella, contenente un sottoinsieme di colonne della tabella. Nell'indice sono incluse solo le colonne necessarie per rispondere alle query. In altre parole, l'indice contiene solo ciò che è necessario per "coprire" la query.
La creazione di indici di copertura per le query più frequenti rappresenta una delle tecniche più semplici e diffuse nell'ottimizzazione delle query. È particolarmente utile nelle situazioni in cui la tabella contiene molte colonne ma la query fa riferimento solo ad alcune di esse. Tramite la creazione di uno o più indici di copertura, è possibile migliorare notevolmente le prestazioni delle query interessate, in quanto queste accederanno a una quantità decisamente inferiore di dati con un conseguente numero inferiore di I/O. Esiste, tuttavia, un costo nascosto legato alla manutenzione di indici aggiuntivi durante le operazioni di modifica dei dati (INSERT, UPDATE e DELETE). A seconda dell'ambiente e del rapporto tra le query SELECT e le modifiche dei dati, è necessario giudicare attentamente se tale manutenzione aggiuntiva di indici viene giustificata dai miglioramenti di prestazioni della query.
Non si deve temere di creare indici con più colonne rispetto agli indici con una sola colonna. Questi tendono a essere molto più utili rispetto agli indici con una sola colonna ed è più probabile che Query Optimizer li utilizzi per coprire la query. La maggior parte degli indici di copertura sono indici con più colonne.
Nel caso della query di esempio, esiste ancora un margine di miglioramento e la query può essere ottimizzata ulteriormente inserendo un indice di copertura nella tabella SalesOrderHeader. Ciò elimina l'operatore Clustered Index Scan a favore di un Index Scan non cluster. Questo può costituire il tema di un esercizio per il lettore. Provare a scoprire la definizione di indice: quali colonne deve contenere per diventare l'indice di copertura di questa query e se l'ordine delle colonne nella definizione di indice comporta una differenza di prestazioni. La soluzione è riportata nell'intestazione laterale "Esercizio sulle query degli ordini clienti".

Viste indicizzate
Se le prestazioni della query di esempio sono molto importanti, è possibile fare un ulteriore passo avanti e creare una vista indicizzata che memorizza fisicamente i risultati della query. Esistono alcuni prerequisiti e limitazioni delle viste indicizzate, ma la possibilità di utilizzarne una consente di migliorare notevolmente le prestazioni. Tenere presente che le viste indicizzate comportano un maggiore costo di manutenzione rispetto agli indici standard. Di conseguenza, il loro utilizzo va gestito con attenzione. In tal caso, la definizione dell'indice è simile alla seguente:
CREATE VIEW vTotalCustomerOrders
WITH SCHEMABINDING
AS
SELECT oh.CustomerID, SUM(LineTotal) AS OrdersTotalAmt, COUNT_BIG(*) AS TotalOrderLines
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Si noti l'opzione WITH SCHEMABINDING, che è un prerequisito per la creazione di un indice in una vista di questo tipo, e la funzione COUNT_BIG(*), che è necessaria se la definizione dell'indice contiene una funzione di aggregazione, in questo esempio, SUM. Dopo avere creato questa vista, è possibile creare un indice al suo interno nel modo seguente:
CREATE UNIQUE CLUSTERED INDEX CIX_vTotalCustomerOrders_CustomerID
ON vTotalCustomerOrders(CustomerID)
Quando si crea questo indice, il risultato della query contenuta nella definizione della vista viene materializzato e memorizzato fisicamente su disco nell'indice. Si noti che tutte le operazioni di modifica dei dati nelle tabelle di base aggiornano quindi automaticamente i valori nella vista in base alla relativa definizione.
Se la query viene eseguita di nuovo, ciò che accadrà dipende dall'edizione di SQL Server utilizzata. Nelle edizioni Enterprise e Developer, Query Optimizer confronterà automaticamente questa query con la definizione della vista indicizzata e utilizzerà quest'ultima invece di eseguire la query delle tabelle di base coinvolte. Nella Figura 6 viene illustrato il piano di esecuzione prodotto in questo caso. È composto da una sola operazione: un'operazione Clustered Index Scan dell'indice che è stato creato nella vista. Il costo di esecuzione stimato è solo 0,09023 ed esegue solo 92 letture logiche.
Figura 6 Piano di esecuzione quando viene utilizzata la vista indicizzata
Figura 6 Piano di esecuzione quando viene utilizzata la vista indicizzata
È possibile creare e utilizzare questa vista indicizzata in altre edizioni di SQL Server, ma per ottenere lo stesso effetto è necessario modificare la query per fare riferimento alla vista direttamente utilizzando l'hint NOEXPAND, come mostrato di seguito:
SELECT CustomerID, OrdersTotalAmt
FROM vTotalCustomerOrders WITH (NOEXPAND)
Come si può vedere, se si utilizzano in modo appropriato, le viste indicizzate possono rivelarsi una funzionalità estremamente efficace. L'utilità maggiore si ha soprattutto per l'ottimizzazione delle query che eseguono aggregazioni su grandi quantità di dati. Se utilizzate nell'edizione Enterprise, possono fornire vantaggi a molte query senza richiedere modifiche al codice.

Identificazione delle query da ottimizzare
Come è possibile identificare le query che vale la pena ottimizzare? In genere è consigliabile concentrare l'attenzione alle query che vengono eseguite spesso: è possibile che il costo di una singola esecuzione non sia molto elevato, ma il costo di esecuzione aggregato può essere molto più alto rispetto a quello di una grande query che viene eseguita raramente. Ciò non vuol dire che le grandi query non devono essere ottimizzate, ma semplicemente che è opportuno concentrare l'attenzione su quelle di utilizzo più frequente. Dunque come vengono identificate queste query?
Sfortunatamente, il metodo più affidabile è un po' complicato e comporta l'esecuzione di una traccia di tutte le query eseguite sul server e il relativo raggruppamento in base alle firme, in altre parole, il testo di una query con i valori effettivi dei parametri sostituiti da segnaposti per identificare lo stesso tipo di query anche se questa è stata eseguita con parametri diversi. Questo è un processo complicato, in quanto le firme delle query sono difficili da generare. Itzik Ben-Gan descrive una soluzione che utilizza funzioni CLR definite dall'utente ed espressioni regolari nel suo libro Inside Microsoft SQL Server 2005: Query T-SQL.
Esiste anche un altro metodo molto più semplice, anche se meno affidabile. È possibile affidarsi alle statistiche che vengono conservate per tutte le query nella cache del piano di esecuzione e sottoporle a query mediante viste di gestione dinamiche. Nella Figura 7 viene illustrata una query di esempio che indica il testo e il piano di esecuzione delle 20 query nella cache con il numero maggiore di letture logiche accumulate. Questa query è estremamente utile per identificare rapidamente le query che generano il maggior numero di letture logiche, anche se vi sono però delle limitazioni. Ovvero, verranno mostrate solo le query i cui piani sono memorizzati nella cache al momento dell'esecuzione della query. Se qualcosa non è memorizzato nella cache, andrà perduto.
Figure 7 Identificazione delle prime 20 query più dispendiose in termini di I/O di lettura (Close Figure 7)
SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC
Dopo avere identificato le query con prestazioni peggiori, dare un'occhiata ai relativi piani di esecuzione e cercare dei metodi per migliorare le relative prestazioni utilizzando alcune delle tecniche di indicizzazione descritte in questo articolo. In caso di risultati positivi, sarà valsa la pena perdere tanto tempo.
Buona ottimizzazione a tutti!

Maciej Pilecki è mentore presso Solid Quality Mentors, un'organizzazione globale specializzata in attività di formazione, assistenza e consulenza. È Microsoft Certified Trainer (MCT) e SQL Server Most Valuable Professional (MVP), tiene spesso corsi e interventi a conferenze su numerosi aspetti di SQL Server e dello sviluppo di applicazioni.


 Dal redattore: Pi&#249; energia per te
Dal redattore
Più energia per te

Il problema del mese scorso ha innescato un dibattito, che si spera continui, sull'argomento dell'informatica "verde". È vero, si tratta di un argomento ancora non ben definito. In effetti, cosa significa "verde"? Se un'automobile percorre 50 km al litro, è un esempio di consumo "verde"? Non che io abbia un'automobile. Vivo a New York. Noi camminiamo.
Sembra anche che ogni azienda di valore stia cercando di applicare un contrassegno "verde" ai propri prodotti e servizi. Tuttavia c'è una buona ragione per questo. Ecco perché l'argomento è comparso il mese scorso sulla nostra copertina. Il potenziale è sorprendente!
Sappiamo tutti che questa strategia è volta ad aiutare l'ambiente quanto a generare profitti. In realtà, essere ambientalisti è diventato un must di vendita, che assicura risultati concreti "Ma è solo una questione economica, è evidente!" Se un'azienda di automobili riesce ad aumentare le vendite producendo vetture più efficienti, benissimo. Alla fine, la speranza è di godere di un'economia sana, creata su un ambiente in buona salute e sostenibile.
Come influisce tutto questo sul professionista IT? Il dott. Jonathan Koomey, uno scienziato dell'équipe del Lawrence Berkeley National Laboratory e professore consulente presso la Stanford University, di recente ha pubblicato uno studio in cui propone una stima del consumo totale di energia da parte dei server negli USA e in tutto il mondo. Nel 2005, i datacenter (ovvero i server insieme alla loro infrastruttura di supporto, ad esempio gli impianti di raffreddamento), sono stati responsabili per l'1,2% del consumo totale di energia negli USA - un valore equivalente alla produzione completa di energia di cinque impianti da 1000 Megawatt (MW), al costo di 2,7 miliardi di dollari. A livello mondiale, questo costo raggiunge i 7,2 miliardi di dollari (la produzione completa di energia di 14 impianti da 1000 MW). È possibile risparmiare molto denaro ed energia, in gran parte proprio partendo dal datacenter.
Come viene progettata la capacità del datacenter? Come è possibile regolare la capacità per soddisfare la domanda, senza dover operare al 100% delle risorse in qualsiasi momento? Suggerimento: virtualizzazione. I server vengono monitorati per la connettività di rete, l'utilizzo della memoria, e così via, ma chi fa attenzione al consumo di energia? I server meno recenti consumano molta più energia dei nuovi computer? Il maggior costo è superiore a quello di un computer sostitutivo?
Nei prossimi mesi, uno dei nostri esperti residenti, Dave Ohara (autore dell'articolo del mese scorso, ora disponibile in linea all'indirizzo technetmagazine.com), illustrerà il lavoro in corso a Microsoft con la realizzazione di nuovi datacenter "verdi" a Quincy, WA, e a San Antonio, TX, nonché le risposte ad alcune di queste domande. Sarebbe opportuno conoscere come i lettori affrontano questi problemi (o, se preferiscono non farlo, perché). Scrivere via posta elettronica all'indirizzo tnmag@microsoft.com o visitare il blog all'indirizzo blogs.technet.com/tnmag. Joshua Hoffman

Si ringraziano i seguenti esperti tecnici di Microsoft: Tim Carroll, Omesh Desai, Steve Jenness, Sam Kroonenburg, Mutlu Kurtoglu, KC Lemson, Tim Mintner, Jim Truher, Buck Woody e Sudarshan Yadav.


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

Acquisizione di schermate
My Screen Recorder Pro
deskshare.com/msrpro.aspx
Supponiamo si abbia una riunione tra 20 minuti e si debba ancora mettere insieme una presentazione sulla nuova configurazione del sistema o si debba ripetere la stessa esercitazione applicativa quasi ogni giorno con utenti diversi. Se tutto ciò suona familiare, ecco un suggerimento: dai un'occhiata a My Screen Recorder Pro di DeskShare.
Come indica il nome, questa applicazione consente di registrare le attività che vengono eseguite sul desktop sotto forma di video, offrendo un ottimo metodo per realizzare una presentazione rapida o un'esercitazione riutilizzabile per i clienti. My Screen Recorder Pro supporta anche la registrazione audio, così è possibile fornire anche un commento parlato. Suggerimento: creare uno script o una scaletta prima di iniziare la registrazione.
La creazione di un nuovo video è semplice. Scegliere l'area che si desidera registrare: l'intero desktop, un'area personalizzabile del desktop, una porzione fissa del desktop o una particolare finestra di applicazione. Quindi, scegliere il pulsante Record.
L'applicazione è in grado di registrare nei formati AVI, Windows Media® Video (WMV) o Flash, così sarà possibile distribuire i risultati in modo relativamente semplice e incorporare anche i video in pagine Web o in flussi multimediali per offrirli a un pubblico più ampio. È anche possibile creare un file eseguibile del video per riprodurlo a livello locale sulla maggior parte dei computer Windows®. Il video viene incorporato all'interno del file eseguibile, semplificando la distribuzione e rendendo la riproduzione estremamente intuitiva per gli utenti finali.
Se l'esercitazione o la presentazione si presta a essere suddivisa in più segmenti, è possibile mettere insieme varie riprese in un unico video. In alternativa, se il video deve essere modificato, è possibile suddividere o tagliare la registrazione in base alle esigenze.
Anche se per un normale utilizzo la configurazione predefinita è adeguata, l'applicazione consente di regolare la frequenza dei fotogrammi, la qualità audio e le impostazioni di compressione nel modo più adeguato a ogni ambiente. Ciò è utile per risolvere qualsiasi limitazione di dimensione o larghezza di banda che si potrebbe incontrare. È inoltre possibile creare una registrazione utilizzando una semplice modalità al rallentatore, che in effetti consente di comprimere porzioni prolungate di una registrazione, come una barra di avanzamento lenta. Un'altra funzionalità interessante è l'opzione che consente di modificare il cursore del mouse per la registrazione e aggiungere effetti del puntatore del mouse per attirare l'attenzione sull'azione in esecuzione mentre è in corso la sessione di registrazione. Ad esempio, è possibile ingrandire il puntatore o visualizzare dei cerchi nella relativa posizione quando si fa clic sul pulsante del mouse. Inoltre, è possibile aggiungere alla registrazione una didascalia e l'indicazione della data e ora a fini di archiviazione.
Per le persone puntigliose, maniache o eccessivamente prudenti, My Screen Recorder Pro consente di pianificare le registrazioni e il programma può essere eseguito dalla riga di comando, fornendo l'opzione di monitorare in modo discreto le attività in una workstation. Infine, l'applicazione è provvista di funzionalità incorporate per la pubblicazione dei video su un sito FTP. Combinata con l'utilità di pianificazione, questa opzione può essere utile a fini di verifica.

Prezzo: 99 dollari per licenza.
Creazione di una presentazione registrando ciò che accade sul desktop
Creazione di una presentazione registrando ciò che accade sul desktop

Deframmentazione del disco
PerfectDisk 8
raxco.com/products/PerfectDisk2k
La deframmentazione del disco rigido è essenziale per qualsiasi sistema Windows. Come me, tutti gli utenti aggiungono e rimuovono costantemente applicazioni, funzionalità e aggiornamenti software. Sono disponibili numerose utilità di deframmentazione del disco tra cui scegliere, infatti ne ho illustrata una anche il mese scorso. Ma la deframmentazione rappresenta un aspetto critico e vale sicuramente la pena descrivere in questa sede il programma PerfectDisk 8 di Raxaco Software. Anche se tutte le varianti di Windows contengono uno strumento di deframmentazione, a volte è necessaria un'utilità che offre un controllo più preciso su questa operazione. In questo caso, è possibile prendere in considerazione PerfectDisk.
Come ci si aspetterebbe da uno strumento di deframmentazione Windows, PerfectDisk 8 è in grado di deframmentare unità FAT16, FAT32 e NTFS nonché unità RAID. Disponibile in versioni desktop e server, PerfectDisk 8 è certificato per Windows Vista® e supporta le altre versioni di Windows, tra cui Windows Server® 2003 e Windows 2000. È disponibile anche una versione per Exchange.
L'azienda reclamizza la sua tecnologia SMARTPlacement, che consente di organizzare la struttura dei file su disco per garantire velocità di accesso più elevate. Ad esempio, sui sistemi Windows XP, la tecnologia SMARTPlacement consente di gestire i file boot e layout.ini, ordinandoli in modo tale da ridurre i tempi di ricerca su disco all'avvio del sistema. Oltre alla deframmentazione di un'intera unità, è anche possibile scegliere di deframmentare un singolo file, operazione utile dopo il download di un grande file ISO, ad esempio.
Per gestire i complessi file di sistema impossibili da toccare mentre il sistema operativo è in esecuzione, l'applicazione utilizza una modalità non in linea che può essere eseguita al successivo avvio del sistema oppure, in condizioni adatte, può tentare di smontare il disco per eseguire la deframmentazione. Un'altra funzionalità è la modalità di deframmentazione screen saver di PerfectDisk, che consente di avviare automaticamente la deframmentazione quando si attiva lo screen saver.
PerfectDisk comprende anche una versione dalla riga di comando che consente di pianificare facilmente la deframmentazione tramite l'utilità di pianificazione delle attività preferite e attiva l'esecuzione remota tramite qualsiasi agente di gestione in esecuzione sul sistema. Per grandi distribuzioni, è anche possibile scaricare gratuitamente il PerfectDisk Command Center, che consente di distribuire, aggiornare, pianificare e configurare in modalità remota l'applicazione della workstation nell'organizzazione.

Prezzo: PerfectDisk 8 Professional (per desktop) ha un prezzo di partenza di 39,99 dollari per una singola licenza. PerfectDisk 8 Server ha un prezzo di partenza di 239,99 dollari per una singola licenza.
PerfectDisk offre varie opzioni di configurazione
PerfectDisk offre varie opzioni di configurazione

Recensione
Network Warrior
oreilly.com
Se il tuo negozio preferito vende apparecchiature Cisco, è possibile trovare una copia di Network Warrior di Donahue di Gary (O'Reilly, 2007). Questo libro può rappresentare una preziosa risorsa per un'ampia gamma di lettori, da chi si affaccia per la prima volta al mondo delle reti a chi ha appena conseguito una certificazione CCNA fino agli amministratori di sistema esperti che desiderano consolidare le proprie competenze.
Personalmente apprezzo questo libro in quanto è basato sull'applicazione reale della tecnologia di rete e fornisce una guida di riferimento rapida per molte attività comuni che devono essere eseguite quotidianamente dai professionisti di rete. L'autore del libro parte da un livello di base definendo esattamente quali sono i componenti fondamentali di una rete. Fornisce in seguito una panoramica su hub, switch, VLAN, giunzione e VLAN Trunk Protocol (VTP), nonché sullo spanning di strutture tramite Spanning Tree Protocol (STP) e la tecnologia EtherChannel di Cisco System.
In Network Warrior è possibile trovare esempi di base sull'utilizzo dell'Internetwork Operating System (IOS) di Cisco e dell'interfaccia della riga di comando CatOS combinati con spiegazioni dei metodi e delle tecnologie. È interessante il quadro storico in cui si inseriscono le metodologie attuali, che contribuisce a inquadrare meglio vari aspetti, ad esempio il perché esiste ancora CatOS invece del solo IOS.
Nel libro, inoltre, viene fornita una discussione sui router e sul routing in generale dalla quale è possibile apprendere gli elementi di base del routing dalle metriche alle distanze amministrative dei diversi protocolli di routing. È inoltre possibile trovare panoramiche sui protocolli, quali Open Shortest Path First (OSPF), Border Gateway Protocol (BGP) e Routing Information Protocol (RIP).
Nella sezione dedicata a Hot Standby Router Protocol (HSRP) di Cisco, l'autore approfondisce i concetti della disponibilità dell'indirizzamento e offre alcune configurazioni di base per la protezione dai periodi di inattività nell'infrastruttura di rete. Segue una rassegna delle caratteristiche e delle funzionalità di alcuni switch multilivello di Cisco, tra cui Cisco 6500 e Catalyst 3750, e una discussione su alcune delle configurazioni di base che è possibile incontrare.
Ho trovato molto utili le informazioni riguardanti il mondo delle telecomunicazioni. Il libro contiene alcuni termini gergali comuni che possono contribuire a evitare fraintendimenti. Sarà possibile apprendere informazioni su Channel Service Unit/Data Service Unit (CSU/DSU), sulla configurazione di connessioni DS3 e sui frame relay che è attualmente possibile convertire con le tecnologie delle telecomunicazioni.
È inclusa anche un'utile sezione sulla protezione e i firewall, in cui viene illustrato come progettare e configurare gli elenchi di controllo di accesso (ACL) e vengono spiegati anche i concetti di autenticazione, DMZ e le opzioni di configurazione specifiche dei firewall PIX. Ho apprezzato la parte dedicata alla teoria dei firewall in cui vengono descritte le tecniche di rete da utilizzare, quali "nega tutto; autorizza ciò che è necessario" e "la protezione è un equilibrio tra praticità e sospetto".
Nell'ultima sezione di Network Warrior viene approfondito il tema della progettazione delle reti, con la descrizione di elementi di base dei progetti comuni di infrastruttura di rete, quali una configurazione di e-commerce su tre livelli e una rete a nucleo compresso senza livello di distribuzione, sottolineando l'importanza della documentazione e delle convenzioni di denominazione.

Prezzo: 44,99 (prezzo di listino).

Gestione dei blocchi dei file
WhoLockMe
dr-hoiby.com/WhoLockMe
Sarebbe bello se ogni applicazione chiudesse i file correttamente. Sfortunatamente, non è così. Le violazioni di condivisione possono rappresentare un problema reale e l'individuazione del processo che blocca un file può rivelarsi piuttosto difficile. Personalmente, posso dire che odio dover chiudere le applicazioni una dopo l'altra per arrivare a ottenere il controllo di un file. Fortunatamente, è disponibile una semplice estensione gratuita di Esplora risorse di nome WhoLockMe che può essere di aiuto.
Disponibile per Windows NT®, Windows 2000, Windows Server 2003 e Windows XP, questa applicazione consente di sapere quale processo sta bloccando un determinato file. È sufficiente fare clic con il pulsante destro del mouse e selezionare la voce adeguata nel menu di scelta rapida di Esplora risorse.
WhoLockMe indica il nome del processo che sta bloccando il file, il relativo identificatore di processo (PID), il percorso del file aperto, il dominio e l'utente del contesto di esecuzione del processo e il percorso completo del processo responsabile del blocco. Se necessario, è possibile scegliere di eliminare il processo direttamente dall'interfaccia utente.
Sfortunatamente, WhoLockMe non è stato aggiornato e non funziona quindi con Windows Vista. Ciononostante, se si utilizza una versione precedente di Windows, questa applicazione è uno strumento rapido ed efficace per scoprire la causa di un blocco su un file che è necessario spostare, eliminare o modificare.

Prezzo: gratuito.

Strumenti DNS
DNSStuff.com
www.dnsstuff.com
La gestione di applicazioni o reti che interagiscono direttamente con Internet dipende senza dubbio da DNS, elemento indispensabile per gestire ed eseguire correttamente queste applicazioni e reti nonché per consentire agli esterni di conoscere la posizione dell'utente e delle applicazioni. Un set di strumenti che trovo utile quando è necessario gestire problemi DNS è disponibile in DNSstuff.COM. Questa raccolta di strumenti basati sul Web può rappresentare un'ottima risorsa per risolvere i problemi e verificare le configurazioni dell'infrastruttura.
Il sito mette a disposizione strumenti per affrontare problemi relativi a domini, IP, nomi host, posta elettronica, siti Web e reti, oltre 45 strumenti di query diversi che sono in grado di fornire assistenza dalla convalida della configurazione dei server di posta al controllo della velocità dell'hosting DNS. Ovviamente, è possibile trovare equivalenti della maggior parte di questi strumenti all'interno dell'infrastruttura, ma la verifica esterna è in grado di offrire importanti informazioni per la risoluzione dei problemi. Inoltre, non sarà necessario infastidire il collega della porta accanto per eseguire una ricerca DNS inversa.
Uno degli strumenti più potenti e completi a disposizione sul sito è DNSreport. È sufficiente immettere un nome di dominio e fare clic sul pulsante per recuperare numerose informazioni sulla configurazione corrente. Ciascuna riga di test visualizza uno stato codificato a colori che è ideale per consultare rapidamente i risultati del test alla ricerca di potenziali problemi. Il report controlla le aree di appartenenza del dominio, mostrando dettagli quali i record del server dei nomi e sulla trasmissione dell'indirizzo IP e del nome host. Il report controlla anche la presenza di potenziali lacune nella protezione, verificando che i server DNS non siano server aperti, che dispongano di record NS identici e che divulghino record NS "nascosti" in richieste non NS.
È inoltre possibile ottenere informazioni sulla disponibilità della configurazione in quanto DNSreport testa più server dei nomi, associazioni IP pubbliche e server dei nomi mancanti controllando la presenza di singoli punti di errore. Inoltre, DNSreport controlla i dettagli Start Of Authority (SOA), restituendo i valori del numero di serie SOA, di aggiornamento, di scadenza, dei tentativi e TTL (Time-To-Live) oltre a eseguire un controllo sui record MNAME e RNAME.
Le verifiche del record Mail Exchange (MX) del report consentono di convalidare le voci DNS inverse e garantire che non vi siano record duplicati e che i nomi host dei record siano validi. Inoltre, lo strumento tenta di connettersi al server di posta e di verificare elementi quali la presenza dei nomi host del server di posta nei saluti, l'accettazione di messaggi provenienti da abuse@yourdomain, secondo le specifiche riportate in vari documenti RFC e l'eventuale configurazione del server SMTP come inoltro aperto, quindi come richiamo per gli spammer in circolazione. Infine, DNSreport restituisce il record www A, verifica che tutti gli IP siano pubblici e determina se la configurazione CNAME causerà un'ulteriore ricerca DNS.
Se DNSreport non è sufficiente, il sito consente anche di utilizzare uno strumento di ricerca per controllare se un server di posta è elencato in un set di database conosciuti di posta indesiderata e un altro per trovare il contatto per gli abusi di un dominio. È inoltre possibile eseguire consultazioni degli IP di origine, traceroute e ping, oltre a ricerche DNS generali e ricerche DNS memorizzati nella cache sui principali ISP. Previa sottoscrizione, è anche possibile eseguire ricerche IP NETGEO, controlli di indirizzi MAC e dump di file dell'area completi. Tutto sommato, si tratta di un set di strumenti decisamente prezioso.

Prezzo: 3 dollari al mese per l'appartenenza di un singolo utente (accesso completo e ricerche illimitate).
DNSstuff.COM fornisce un intero set di pratici strumenti di monitoraggio
DNSstuff.COM fornisce un intero set di pratici strumenti di monitoraggio

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


 Exchange Queue &amp; A: Protezione dei protocolli di posta elettronica, posta indesiderata misteriosa e altro
Exchange Queue & A
Protezione dei protocolli di posta elettronica, posta indesiderata misteriosa e altro
Nino Bilic and Scott Landry
Questo articolo si basa su una versione provvisoria di Windows Server 2008. Tutte le informazioni riportate sono soggette a modifica.

D Desidero utilizzare il protocollo SMTP protetto. Come posso configurare Exchange Server in modo che ascolti il traffico SMTP sulla porta 465?
R Purtroppo si tratta di un obiettivo irrealizzabile. Certo è possibile configurare qualsiasi server virtuale SMTP o connettore di ricezione in modo che ascolti sulla porta 465, ma il supporto del protocollo SMTP protetto (SMTPS, Simple Mail Tranfer Protocol Secure) resta escluso.
Perché? Bene, facciamo qualche passo indietro. Esistono due tipi di SSL: esplicito e implicito. Inizialmente, le connessioni SSL erano nella maggior parte implicite, cioè veniva utilizzata una porta dedicata per le comunicazioni basate su questo protocollo. Ad esempio, il traffico HTTP viene ascoltato per impostazione predefinita sulla porta 80, mentre il traffico HTTPS (HTTP con SSL) viene ascoltato sulla la porta 443. Alcuni anni fa, la community di Internet decise che non era necessaria una porta dedicata per SSL. È per questa ragione che è nato il protocollo SSL esplicito.
Netscape aveva già scelto la porta 465 come porta SMTPS, ma Exchange Server non disponeva di alcuna funzionalità SSL in SMTP. Tuttavia, il team di Exchange si rese conto del notevole vantaggio del protocollo SSL esplicito, ovvero la possibilità di essere utilizzato sia dai client che dai server, e decise di utilizzarlo per SMTP.
Nel caso di SMTP, il protocollo SSL esplicito utilizza il comando STARTTLS ESMTP per segnalare che il socket esistente sta per essere protetto. Anche la maggior parte degli altri fornitori di client e server SMTP ha scelto di implementare il comando STARTTLS, per cui non si avvertiva particolarmente l'esigenza di supportare la porta 465, che in ogni caso non era uno standard Internet ufficiale.
Fino a oggi, nessuna versione di Exchange Server supporta il protocollo SSL implicito per SMTP. La configurazione di un server virtuale SMTP o connettore di ricezione di Exchange per l'ascolto sulla porta 465 non modifica questo stato di cose. Pertanto, è necessario utilizzare un client che supporti STARTTLS sulla porta 25. Se non è possibile utilizzare tale porta, la scelta logica ricade sulla porta 587, che è la porta standard per gli invii SMTP client. Non sono molti i client moderni che non supportano STARTTLS sulla porta 25, quindi non è stato necessario aggiungere supporto per il protocollo SSL implicito.
Tra l'altro, i protocolli POP3 e IMAP4 in Exchange hanno sempre supportato SSL implicito. In Exchange Server 2007, però, è disponibile ora il supporto per SSL esplicito anche per questi due protocolli. Poiché, tuttavia, sono ancora pochi i client compatibili con questo standard più recente, il protocollo SSL implicito sarà ancora in circolazione per un bel po'.

D Mi trovo improvvisamente a dover gestire una grande quantità di posta in coda per più domini, eppure nessuno dei miei utenti ha inviato messaggi. Cosa sta succedendo e come posso evitarlo?
R Purtroppo si tratta di fenomeno frequente. In effetti, chiunque abbia un server su Internet può incorrere in questo problema. Fondamentalmente, sono due le cause possibili. È probabile che inavvertitamente sia stato aperto il server per l'inoltro (vedere support.microsoft.com/kb/304897). Naturalmente, è difficile che ciò accada. Tra l'altro, gli inoltri aperti sono stati disabilitati per impostazione predefinita a partire da Exchange Server 2000. Pertanto è più probabile che si tratti di un messaggio di posta elettronica indesiderato con rapporto di mancato recapito. Nel processo di invio di posta elettronica commerciale indesiderata, gli spammer spesso inoltrano i messaggi a indirizzi non esistenti presso il dominio preso di mira. Il server tenta di informare lo spammer che gli utenti non esistono, ma naturalmente l'indirizzo del mittente è stato falsificato. È possibile che lo spammer stia effettuando lo spoofing di un indirizzo non valido (nel qual caso il rapporto NDR rimane in sospeso per un certo periodo di tempo finché non scade) oppure è possibile che stia tentando di fare in modo che il server della vittima invii messaggi indesiderati a un altro dominio per conto suo, sotto forma di allegati del rapporto NDR generato dal server.
Per risolvere il problema, è possibile disabilitare i rapporti NDR. In tal caso, tuttavia, se un utente legittimo dovesse inavvertitamente digitare un indirizzo in modo errato, il server non lo informerebbe mai che il suo messaggio non è giunto a destinazione e potrebbero andare perdute informazioni importanti. Ecco quindi una soluzione migliore.
Per prima cosa, accertarsi che il server non sia aperto per l'inoltro (so che è ovvio, ma devo dirlo). Quindi, attivare il filtro posta indesiderata, ad esempio il filtro messaggi intelligente, il filtro contenuto di Exchange Server 2007 o la funzionalità di blocco degli indirizzi in tempo reale. Questo filtro può essere attivato sia nel ruolo Trasporto Edge che nel ruolo Trasporto Hub, purché venga fatto quanto prima perché l'attacco potrebbe estendere il suo raggio d'azione fino a investire oltre il 90% del volume dei messaggi e certo non è il caso di tenere i server occupati con una tale mole di posta indesiderata.
Infine, è necessario abilitare il filtro destinatario sul primo server Exchange che accetta posta nell'ambiente in uso. Ciò consentirà al server di rifiutare un messaggio prima che entri nella rete. Nel caso di errori nella digitazione di indirizzi legittimi, verrà comunque generato un rapporto NDR, ma in questo caso verrà generato dal server del mittente.

D Fino a qualche tempo fa, i due server di cui disponevo eseguivano rispettivamente Exchange Server 2000 ed Exchange Server 2003 ed entrambi inviavano correttamente messaggi in Internet. Dopo aver installato Exchange Server 2007, le cassette postali di entrambi i server non sono più in grado di inviare messaggi.
R Questa domanda rivela una scarsa dimestichezza con il concetto di connettori, non insolita per chi è abituato a utilizzare un solo server Exchange. I connettori di Exchange sono oggetti per la configurazione del routing logico che indicano a Exchange dove indirizzare i messaggi di posta elettronica. Quando si introduce Exchange Server 2007 in un'organizzazione esistente, per poter instradare la posta è indispensabile disporre di connettori dei gruppi di routing e di un connettore SMTP.
In questo caso specifico, sono necessari due connettori dei gruppi di routing, uno che va dal gruppo di Exchange Server 2007 a quello di Exchange Server 2003 e l'altro che procede in senso contrario. La configurazione può essere effettuata durante il processo di installazione, ma se ci si è dimenticati o non si è certi di averla eseguita, è possibile controllare utilizzando Exchange Management Shell e correggere il problema con questa shell. Se i due connettori non vengono configurati, non sarà possibile lo scambio di posta tra i server. I messaggi finiranno in code di destinazione irraggiungibili.
Per instradare la posta in Internet occorre invece un unico connettore SMTP, definito anche connettore di invio in Exchange Server 2007. Dovrebbe esserne disponibile uno in Exchange Server 2000 ed Exchange Server 2003, ma forse non ne è stato utilizzato nessuno. Lo spazio degli indirizzi deve essere SMTP:* per tutti i domini ed è possibile specificare l'utilizzo di uno smart host o di un DNS per il recapito della posta. Inoltre, è possibile impostare il server che esegue Exchange Server 2007 o il server precedente in modo che gestisca la posta Internet in uscita oppure creare un connettore in entrambi i gruppi di routing se si desidera che ogni server gestisca la propria posta. È anche possibile crearne uno come parte del processo Edgesync se è stato installato un ruolo del server Trasporto Edge.
Se precedentemente è stato impostato uno smart host sul server virtuale SMTP, adesso è possibile rimuoverlo. Lo smart host infatti deve essere configurato solo sul connettore SMTP, mai sul server virtuale in quanto danneggerebbe il connettore del gruppo di routing.
Va inoltre tenuto presente che la posta elettronica in ingresso è controllata dal record MX o dall'IP verso cui il firewall esegue l'inoltro. Il lavoro di configurazione sul lato di Exchange non è molto, ma questo documento dovrebbe essere d'aiuto in caso di problemi: msexchangeteam.com/archive/2006/11/17/431555.aspx.

D Perché ricevo più rapporti del journal per lo stesso messaggio in Exchange Server 2007?
R L'agente di journaling per il trasporto di Exchange Server 2007 inserirà i messaggi nel journal dopo la classificazione. Sono diverse le ragioni per cui il classificatore biforca un messaggio, ovvero copia il corpo del messaggio e specifica i diversi destinatari delle buste sulle copie. Ecco un esempio: poiché ora l'agente di journaling è in grado di stabilire quali erano i membri di un gruppo di distribuzione al momento dell'invio di un messaggio, la ricezione di più rapporti può verificarsi nel caso di un gruppo di distribuzione nidificato.
Questa maggiore ricchezza di informazioni nella creazione dei rapporti fa sì che si possano ricevere più copie dello stesso messaggio, ciascuna con un rapporto univoco. Non esiste un metodo infallibile per sapere se tutti i rapporti pervenuti riguardano un unico messaggio, tuttavia, se si sta effettuando l'archiviazione della posta, è consigliabile collaborare con il proprio fornitore di servizi di archiviazione per assicurarsi che sia al corrente delle modifiche.

D Non trovo la funzionalità per l'inoltro dei messaggi non risolti all'host in Exchange Server 2007? Che posso fare?
R Deve essersela mangiata il cane.
In verità, la funzionalità in questione non si è mai rivelata particolarmente efficace in situazioni in cui i server Exchange erano più di uno. In ogni caso, in Exchange era disponibile già un altro metodo, di gran lunga più valido, per eseguire la stessa operazione. Nello specifico, tale metodo consente di condividere singoli domini SMTP con altri sistemi. Pertanto, la funzionalità di inoltro dei messaggi non risolti è stata eliminata e il concetto dei domini condivisi è stato ulteriormente sviluppato e semplificato. In Exchange Server 2007, basta accedere a Organizzazione | Trasporto Hub | Domini accettati e modificare il tipo di dominio da Autorevole in Inoltro interno. In effetti, per alcuni ambienti le cose non sono proprio così semplici ed è per questo che stiamo aggiornando parte della documentazione. Ma, nel frattempo, queste indicazioni dovrebbero essere d'aiuto.

D Sto tentando di preparare il dominio radice per l'installazione di Exchange Server 2007. Sul server da cui desidero eseguire tale processo è installato il componente Gestore di sistema di Exchange di Exchange Server 2003 e l'installazione di Exchange Server 2007 ha esito negativo. Qual è il problema?
R In parole povere, l'esecuzione di qualsiasi parte dell'installazione di Exchange Server 2007 su un computer che già dispone di componenti di Exchange Server 2000 o 2003 non è supportata. In questo caso, durante il processo di installazione di Exchange Server 2007 verrà rilevata la presenza del Gestore di sistema di Exchange di Exchange Server 2003, quindi il controllo dei prerequisiti per l'installazione avrà esito negativo e verrà visualizzato il messaggio "Nel computer è già installata una versione precedente di Exchange Server. Eseguire l'installazione di Exchange 2007 da un computer diverso o rimuovere la versione precedente di Exchange Server".
Probabilmente il modo più semplice per risolvere il problema consiste nell'eseguire l'installazione di Exchange Server 2007 da un altro server del dominio radice e nel preparare il dominio a tale scopo. Se ciò non è possibile, sarà necessario disinstallare il componente di Exchange Server 2003 prima di procedere con l'installazione di Exchange Server 2007.
Si ricordi che è possibile utilizzare la versione a 32 bit di Exchange Server 2007 per preparare il dominio, quindi qualsiasi server a 32 bit del dominio radice è idoneo allo scopo. Per ulteriori informazioni in proposito, vedere technet.microsoft.com/library/bb232170.aspx.
Ciò significa, tra l'altro, che non è possibile installare i componenti Gestore di sistema di Exchange di Exchange Server 2003 ed Exchange Management Console di Exchange Server 2007 sullo stesso computer in quanto la coesistenza di strumenti di gestione di Exchange Server 2003 ed Exchange Server 2007 sullo stesso computer non è supportata. Pertanto, se si tenta di installare Exchange Server 2007 su un computer in cui sono già presenti componenti di Exchange Server 2000 o Exchange Server 2003, il processo verrà bloccato.
Infine, si tenga presente che non si deve mai tentare di installare sullo stesso computer prima gli strumenti di gestione di Exchange Server 2007 e successivamente gli strumenti di Exchange Server 2003. Questo tipo di approccio produrrà una configurazione che non è stata testata e potrebbe generare risultati imprevisti durante la gestione dei server. Se si ha la necessità di gestire entrambe le versioni server da un unico computer, è possibile utilizzare un desktop remoto per connettersi a una versione oppure utilizzare un computer virtuale per ospitare una versione differente degli strumenti di gestione in un ambiente isolato.

D Quando sarà possibile finalmente eseguire gli strumenti di gestione di Exchange Server 2007 su una workstation Windows Vista®?
R Il supporto ufficiale per gli strumenti di gestione di Exchange Server 2007 in Windows Vista verrà fornito a partire da Exchange Server 2007 SP1. Un pacchetto contenente gli strumenti di gestione di Exchange Server 2007 SP1 sarà disponibile per il download non appena Exchange Server 2007 SP1 verrà rilasciato.

D Sarà possibile anche eseguire il Gestore di sistema di Exchange di Exchange Server 2003 su Windows Vista o su Windows Server 2008?
R Sfortunatamente no. Gli strumenti di gestione relativi a qualsiasi versione di Exchange Server precedente a Exchange Server 2007 SP1 non saranno supportati né in Windows Vista né in Windows Server 2008. Ciò significa che anche dopo il rilascio di Windows Server 2008, l'installazione del Gestore di sistema di Exchange di Exchange Server 2003 non sarà supportata. La gestione dei server Exchange Server 2003 dovrà essere eseguita da workstation su cui è installato Windows Server 2003 o Windows XP o, in alternativa, sarà possibile utilizzare una connessione desktop remoto da qualsiasi sistema operativo.

D Più server Exchange Server 2003 sono in esecuzione nel mio dominio. Sarà possibile aggiornare i controller di dominio a Windows Server 2008?
R Sì, l'esecuzione di Exchange Server 2003 SP2 in un dominio che dispone di controller di dominio Windows Server 2008 è supportata. Si noti che Exchange Server non può utilizzare server di catalogo globale di sola lettura o controller di dominio di sola lettura Windows Server 2008. Se viene specificato manualmente, a livello di codice, l'utilizzo di questo tipo di server o di controller di dominio da parte di Exchange Server, potrebbe verificarsi un comportamento imprevisto.

Nino Bilic è Supportability Program Manager per Exchange Server. Nel tempo libero si dedica alla scoperta delle meraviglie delle comunicazioni tra server leggendo avidamente tonnellate di tracce Netmon prima di andare a dormire.
Scott Landryè Support Escalation Engineer per Exchange Server. Non viaggia mai senza il suo asciugamano, la sua copia della Guida e il suo fedele telefono Windows Mobile.


 Utilit&#224; in primo piano: Cmdlet SMS per Windows PowerShell
Utilità in primo piano
Cmdlet SMS per Windows PowerShell
Don Brown
Scarica il codice per questo articolo: Utility2007_11.exe (1211KB)

In passato non era possibile gestire i client di Microsoft System Management Server (SMS) 2003 dalla riga di comando. Questo problema è stato risolto da Windows PowerShell, una delle eccezionali tecnologie sviluppate di recente per semplificare agli amministratori la gestione delle complessità, delle modifiche e della configurazione.
Per sfruttare i vantaggi di questa soluzione, ho creato una piccola "utilità", SMS2003PowerShellSnapinSample, inclusa nel download di codice di questo articolo e disponibile in linea all'indirizzo technetmagazine.com/code07.aspx. L'utilità include in un unico snap-in di Windows PowerShellTM una raccolta di sei cmdlet, che consentono di configurare i criteri locali del client SMS per il computer locale o per gruppi di computer remoti tramite Windows PowerShell.
Dopo aver eseguito numerosi test sui criteri locali del client SMS, questa soluzione mi è sembrata la più appropriata. In questo modo, ho potuto anche approfondire le mie conoscenze sul funzionamento di SMS. Ho imparato che applicando accuratamente i criteri locali è possibile gestire il client SMS in un modo completamente nuovo: non è necessario che i computer in cui vengono generati report per lo stesso sito siano configurati in modo identico. Ho iniziato a elaborare diverse soluzioni, ad esempio l'impostazione di determinati computer in modo da non richiedere l'autorizzazione per il controllo remoto, la modifica della frequenza con cui il client verifica la presenza di nuovi criteri e la disabilitazione di componenti specifici in diverse ore del giorno. I criteri locali del client SMS offrono infinite possibilità. Esaminiamole nei dettagli.

Informazioni sui criteri locali del client avanzato SMS
Risorse di programmazione
  • Introduzione a Windows PowerShell Un'ottima panoramica per chi desidera iniziare a utilizzare Windows PowerShell
  • Forum di TechNet sulla personalizzazione di SMS tramite i criteri locali Applicazione basata su MOF (Managed Object Format) dei criteri locali del client avanzato SMS
  • Creazione del primo cmdlet
  • Creazione di uno snap-in di Windows PowerShell
  • Protezione accesso alla rete (NAP) per Windows Server 2008
  • Guida per programmatori di Windows PowerShell Per ulteriori informazioni sulla creazione di cmdlet, snap-in, host e altre risorse di programmazione per Windows PowerShell
  • Guide dettagliate su Windows Server 2008 Beta 3

In tutti i client avanzati di SMS 2003 sono presenti determinati criteri di configurazione, ovvero un elenco di impostazioni che regolano il funzionamento dei diversi componenti. Tutte le impostazioni relative alla distribuzione software, alla raccolta dell'inventario e al client sono incluse in questi criteri di configurazione. I criteri stessi vengono creati sul server del sito e passati al client avanzato tramite il punto di gestione SMS.
L'effettiva struttura di un criterio SMS è analoga a quella di un file MOF, poiché contiene una serie di istanze che verranno compilate nello spazio dei nomi di Strumentazione gestione Windows® (WMI) \\.\root\CCM sul client avanzato. Gli altri agenti leggeranno quindi tali impostazioni dallo spazio dei nomi \\.\root\ccm\policy\machine\requestedconfig. Se i criteri locali vengono applicati tramite file MOF, tuttavia, occorre considerare che è possibile compilare un file MOF su un unico computer ed eseguirlo localmente (ovvero quando si è connessi direttamente al computer). La natura distribuita di WMI, invece, consente l'accesso sia in locale che in remoto, pertanto offre una gamma più ampia di opzioni per gli amministratori di SMS. Ciò significa che è possibile connettersi facilmente a WMI sia su un computer remoto che sul computer locale, a condizione che si disponga dei diritti amministrativi appropriati.
I criteri client SMS sono costituiti dalle impostazioni di configurazione dei diversi componenti client, tuttavia possono includere anche istruzioni per l'esecuzione dei contenuti del pacchetto software. Analogamente ai Criteri di gruppo di Active Directory®, i criteri locali del client SMS possono avere la precedenza sui criteri del client avanzato di SMS 2003 ottenuti da un punto di gestione SMS. Anche se non è possibile sostituire tutti i componenti di un criterio, è possibile sostituire alcune proprietà interessanti. Ciò fornisce agli amministratori di SMS un livello di controllo superiore sulla configurazione e sulle operazioni del client SMS, poiché consente la presenza di eccezioni nella configurazione standard del sito SMS.
Si consideri, ad esempio, un ambiente consolidato e protetto in cui gli amministratori di SMS gestiscono sia i server che le workstation come client di un unico sito primario di SMS. In questo ambiente fittizio, un criterio di protezione potrebbe imporre che venga richiesta un'autorizzazione prima che i tecnici dell'assistenza possano ottenere il controllo remoto del computer. Tale criterio rappresenterebbe un problema, se i tecnici dell'assistenza volessero connettersi ai server utilizzando il controllo remoto: in genere, nessun utente è connesso ai server, pertanto non è necessaria alcuna autorizzazione per il controllo remoto. Ciononostante, se i criteri locali vengono applicati in modo appropriato, è possibile sostituire il requisito relativo all'autorizzazione utente su determinati client. Esistono molte altre circostanze in cui i criteri locali di SMS possono risultare utili per garantire la possibilità di un'eccezione nella configurazione di un agente specifico del client SMS.

Analisi dello snap-in di Windows PowerShell
Una volta acquisita dimestichezza con le nozioni di base di Windows PowerShell, è possibile applicarle al codice sorgente di esempio fornito in questo articolo per aumentare le operazioni che è possibile eseguire con i criteri locali del client SMS dalla riga di comando. Prima di esporre una classe a Windows PowerShell, è necessario applicarvi determinati attributi e stabilire quale funzione deve essere assegnata al cmdlet. Tale operazione è nota come coppia di verbo e sostantivo. Alcuni verbi comunemente utilizzati in Windows PowerShell includono Add, Get e Set. Nella parte relativa al sostantivo viene descritto l'oggetto su cui deve essere eseguita l'azione. In genere, i cmdlet includono parametri che vengono dichiarati in una classe Cmdlet come proprietà pubbliche di diversi tipi. La funzione ProcessRecord, infine, è il componente principale in cui verranno eseguite le operazioni. Nella Figura 1 viene illustrato un modello generico che può essere utilizzato per creare cmdlet personalizzati.
Figure 1 Modello di cmdlet (Close Figure 1)
[Cmdlet( "Verb", "Noun", SupportsShouldProcess = true )]
public class Verb_Noun : PSCmdlet
{
    [Parameter( ValueFromPipeline = true, ValueFromPipelineByPropertyName = true,
        HelpMessage = "Parameter" )]
    [ValidateNotNullOrEmpty]
    [Alias( "param" )]
    public string Parameter
    {
        get { return MyParameter; }
        set { MyParameter = value; }
    }
    private string MyParameter;

    protected override void ProcessRecord( )
    {
        //Do your stuff here!
    }
}
Dopo aver compilato lo snap-in, è necessario registrarlo con Windows PowerShell includendo nel progetto una classe in cui sia impostato l'attributo RunInstaller e siano definite alcune proprietà specifiche. Per informazioni dettagliate, vedere il codice sorgente fornito in questo articolo. Per registrare lo snap-in, è necessario utilizzare lo strumento InstallUtil.exe disponibile con Microsoft® .NET Framework. Nella Figura 2 viene illustrata la sintassi necessaria per registrare lo snap-in. In Windows Vista®, questa operazione richiede un processo di elevazione dei privilegi, pertanto sarà necessario accedere a Windows PowerShell come amministratore oppure utilizzare i PowerToy per l'elevazione dei privilegi degli script in Windows Vista (scaricabili all'indirizzo technetmagazine.com/issues/2007/06/UtilitySpotlight).
Figure 2 Installazione dello snap-in di Windows PowerShell (Close Figure 2)
PS> set-alias installutil $env:windir\Microsoft.NET\Framework\v2.0.50727\installutil
PS> installutil C:\MySMSTools\SMS2003PowerShellSnapinSample.dll
Microsoft (R) .NET Framework Installation utility Version 2.0.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Running a transacted installation.
...
The transacted install has completed.
Il passaggio successivo consiste nel verificare che il proprio snap-in venga riconosciuto da Windows PowerShell. A tal fine, è necessario utilizzare il cmdlet Get-PSsnapin con il parametro Registered. In Windows PowerShell verrà fornito un riepilogo degli snap-in attualmente caricati, seguito da un elenco di quelli registrati, che dovrebbe includere il proprio snap-in:
PS> Get-PSsnapin -registered
Sarà quindi possibile aggiungere alla shell lo snap-in di Windows PowerShell utilizzando il cmdlet Add-PSsnapin, come indicato di seguito:
PS> add-pssnapin SMS2003PowerShellSnapinSample
Se l'operazione viene eseguita correttamente, i cmdlet potranno essere eseguiti nello snap-in di Windows PowerShell.
Per visualizzare tutti i cmdlet disponibili in uno snap-in di Windows PowerShell, è sufficiente indicare lo snap-in specifico con il cmdlet Get-Command e passare il relativo nome come valore per il parametro PSsnapin. Nello snap-in di esempio fornito in questo articolo vengono visualizzati sei cmdlet, incluso il modello di cmdlet Verb-Noun, come illustrato nella Figura 3.
Figura 3 Visualizzazione dei cmdlet in uno snap-in
Figura 3 Visualizzazione dei cmdlet in uno snap-in
Nel codice sorgente di esempio, ho fornito le istruzioni solo per il cmdlet Get-SMSServerConnection, per illustrare come viene creato. Se si desidera approfondire l'argomento, verrà fornito un esempio nel file XML. Nella Figura 4 viene illustrato l'output delle istruzioni.
Figure 4 Output di esempio di Get-Help (Close Figure 4)
PS > get-help Get-SMSServerConnection

NAME
    Get-SMSServerConnection

SYNOPSIS
    This cmdlet establishes a connection to the specified SMS primary site server using your current credentials. An object of type "SMSProvider" is returned through the pipeline.

SYNTAX
    Get-SMSServerConnection [-SMSServerName] [<string>] [<CommonParameters>]

DETAILED DESCRIPTION
    This Cmdlet makes a connection to the specified SMS primary site server.  An object of type "SMSProvider" is returned. The "SMSProvider" object is not serializable and is used only to forward on through the pipeline to other cmdlets.

RELATED LINKS
Dopo aver esaminato come installare lo snap-in di Windows PowerShell, individuare i comandi presenti nello snap-in e ottenere istruzioni su un cmdlet tipico, verrà illustrato come utilizzare i cmdlet. Per visualizzare un elenco di tutte le raccolte disponibili su un server del sito primario di SMS, è possibile utilizzare il seguente comando:
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | Format-Table Name
Si osservi la pipeline, che è uno strumento molto potente, nonché un componente essenziale del funzionamento di Windows PowerShell. In Windows PowerShell è possibile impostare l'esecuzione di qualsiasi operazione in una singola riga. Il cmdlet Get-SMSServerConnection consente di stabilire una connessione con il server SMS. Poiché il cmdlet Get-Collections presenta un unico parametro di input analogo a quello restituito da Get-SMSServerConnection, è possibile passare semplicemente l'output dal cmdlet Get-SMSServerConnection al cmdlet Get-Collections. Questo passaggio di oggetti complessi tra i cmdlet è esemplificativo del funzionamento della pipeline. È anche possibile archiviare oggetti all'interno di variabili, come illustrato nel seguente script di esempio di Windows PowerShell:
$SMS = Get-SMSServerConnection
     -server MYSMSSERVER
Get-Collections -SMSServerProvider $SMS
L'output potrebbe risultare di difficile lettura in quanto privo di formattazione chiara, poiché il cmdlet Get-Collections restituisce un oggetto di tipo SMSCollections, ovvero una serie di oggetti di tipo SMSCollection. In pratica, la visualizzazione risulterà poco chiara, a meno che non venga applicato un filtro alle raccolte da visualizzare oppure non venga formattata la visualizzazione in una tabella che contiene solo le proprietà rilevanti. A tal fine, è necessario passare l'output attraverso la pipeline dal cmdlet Get-Collections al cmdlet Format-Table, che è in grado di visualizzare solo le proprietà specificate. Ad esempio, è possibile aggiungere | Format-Table Name, Members.
Tuttavia, per visualizzare tutti i membri di una determinata raccolta, la soluzione migliore è utilizzare il cmdlet Get-CollectionMembers, che restituisce una serie di stringhe indicanti il nome di ogni membro della raccolta. Come si può immaginare, questo cmdlet è un ottimo candidato per passare la pipeline al cmdlet successivo.
Finora, sono state fornite informazioni sulle connessioni al server del sito primario di SMS, sull'enumerazione delle raccolte e sui relativi membri, ma non sono ancora stati utilizzati i criteri locali del client avanzato SMS. In questo snap-in di esempio di Windows PowerShell sono inclusi altri due cmdlet, denominati rispettivamente Enable-SoftwareDistribution e Disable-SoftwareDistribution. A questo punto entrano in gioco i criteri locali del client SMS. Questi due ultimi cmdlet consentono di modificare i criteri locali del client SMS per il componente Software Distribution Client Agent nel client avanzato SMS. La sezione del cmdlet relativa al verbo, Disable, prevede la sostituzione di un criterio locale del client, nel caso specifico la disabilitazione di Software Distribution Client Agent. Analogamente, il verbo Enable prevede la rimozione di tutte le sostituzioni dei criteri locali del client, ripristinando il normale stato di Software Distribution Client Agent, come definito nei criteri SMS passati dal punto di gestione SMS. Nella Figura 5 viene illustrato un esempio di una singola riga di codice in Windows PowerShell, che prevede la sostituzione di un criterio locale del client in Software Distribution Client Agent e ne impone la disabilitazione per tutti i membri della raccolta personalizzata dei sistemi Windows Server 2003. Viene fornita inoltre la riga di codice che consente di rimuovere tutte le sostituzioni dei criteri locali del client SMS per Software Distribution Client Agent in tale raccolta. I cmdlet Disable-SoftwareDistribution ed Enable-SoftwareDistribution possono anche essere utilizzati individualmente, se si desidera modificare i criteri locali del client SMS solo in alcuni computer.
Figure 5 Esempi di assemblaggio di cmdlet (Close Figure 5)
PS >Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Disable-SoftwareDistribution
PS >
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Enable-SoftwareDistribution
PS >
PS >Disable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3
PS >
PS >Enable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3

Passaggi successivi
Il codice sorgente di esempio fornito in questo articolo offre un ottimo punto di partenza per applicare sostituzioni dei criteri locali del client SMS a gruppi di computer. Questo esempio riguarda solo Software Distribution Client Agent di SMS, in particolare la proprietà Enabled. Gli altri agenti client presentano molte altre proprietà a cui è possibile applicare sostituzioni in modo analogo. Dopo aver fornito un punto di partenza comune, il passaggio logico successivo consiste nell'esaminare altri componenti dei criteri locali del client SMS. Si considerino, ad esempio, i gruppi di sistemi gestiti a cui potrebbero essere applicate determinate sostituzioni di criteri locali del client SMS e le sostituzioni adeguate alle proprie esigenze. Infine, è utile valutare quali potrebbero essere i risultati delle proprie operazioni, verificandole accuratamente in un ambiente di lavoro.

Don Brown è Senior Premier Field Engineer presso Microsoft e da tempo offre collaborazione e supporto allo sviluppo della nuova versione di System Manager Server (SMS), ovvero System Center Configuration Manager (SCCM). È possibile contattarlo all'indirizzo donbrown@microsoft.com.


 The Cable Guy: Single Sign-On wireless
The Cable Guy
Single Sign-On wireless
Joseph Davies

Le connessioni wireless che vengono stabilite e, quindi, devono eseguire l'autenticazione con una rete privata possono complicare ulteriormente le cose agli utenti e agli amministratori. Un client wireless basato su Windows e membro di un dominio di Active Directory deve eseguire un'autenticazione basata su IEEE 802.1X per ottenere una
connessione wireless protetta e un accesso di dominio. Poiché l'autenticazione può coinvolgere le credenziali utente o computer e gli accessi di dominio dipendono dalla connettività della rete, sorgono problemi al momento di configurare l'ordine di esecuzione delle autenticazioni e specificare le credenziali appropriate. Tutto ciò può influire sugli accessi di dominio e creare situazioni in cui a un utente vengono richieste le credenziali più volte.
Fortunatamente, Single Sign-On wireless in Windows Vista® consente di specificare che l'autenticazione IEEE 802.1X per Wi-Fi Protected Access 2 (WPA2)-Enterprise e WPA-Enterprise e l'autenticazione 802.1X con Wireless Equivalency Privacy (WEP) devono aver luogo prima del processo di accesso utente. Ciò consente di risolvere i problemi di accesso di dominio in configurazioni specifiche. Single Sign-On wireless, inoltre, integra perfettamente l'autenticazione wireless con l'esperienza di accesso di Windows®, rendendo gli utenti, nel complesso, più soddisfatti. Per tali motivi, questo mese verranno esaminate le funzionalità di Single Sign-On wireless, come configurarlo e il suo funzionamento durante il processo di accesso utente.

Concetti di base di Single Sign-On
Un client wireless di Windows può eseguire l'autenticazione alla rete wireless utilizzando soltanto le credenziali computer o utente, o una loro combinazione. Quando si utilizzano solo le credenziali computer, l'autenticazione 802.1X viene eseguita prima di visualizzare la schermata di accesso di Windows. In questo modo il computer client wireless accede inizialmente a risorse di rete quali i controller di dominio di Active Directory®.
Quando si utilizzano solo le credenziali utente, in Windows senza Single Sign-On l'autenticazione 802.1X viene eseguita al termine del processo di accesso. Nella Figura 1 viene illustrata la sequenza temporale di avvio e accesso per questo scenario.
Figura 1 Sequenza temporale quando vengono utilizzate solo le credenziali utente per l'autenticazione wireless
Figura 1 Sequenza temporale quando vengono utilizzate solo le credenziali utente per l'autenticazione wireless
Se si utilizzano solo le credenziali utente per l'autenticazione wireless, l'utente non può eseguire l'accesso di dominio iniziale a un computer poiché nella cache locale non esistono credenziali per il suo account e manca la connettività al controller di dominio necessaria per autenticare le nuove credenziali di accesso. Inoltre, alcune operazioni di accesso di dominio non riusciranno, in quanto al momento non è disponibile la connettività ai controller del dominio di Active Directory. In particolare, gli script di accesso e gli aggiornamenti di Criteri di gruppo e del profilo utente non possono essere eseguiti e generano errori nel registro eventi di Windows.
Quando si utilizza una combinazione di credenziali utente e computer, l'autenticazione 802.1X viene eseguita con le credenziali computer prima di visualizzare la schermata di accesso di Windows. Dopo che l'utente ha avuto accesso, in Windows viene eseguita un'altra autenticazione 802.1X con le credenziali utente. Alcune infrastrutture di rete ricorrono a LAN virtuali (VLAN) diverse per i computer autenticati tramite le credenziali computer e per quelli in cui sono state utilizzate le credenziali utente. Se l'autenticazione alla rete wireless tramite le credenziali utente e la commutazione alla VLAN autenticata in base a queste credenziali si verificano dopo il processo di accesso utente, il client wireless Windows non potrà accedere alle risorse di rete di tale VLAN, ad esempio ai controller di dominio di Active Directory, durante il processo di accesso utente. Ancora una volta, ciò rende impossibile eseguire operazioni di accesso di dominio.
Un altro problema si verifica quando l'autenticazione wireless basata sulle credenziali utente utilizza una serie diversa di credenziali di protezione rispetto a quelle di accesso utente. Per tali configurazioni, in Windows vengono richieste credenziali utente aggiuntive all'inizio dell'autenticazione wireless, il che può confondere.
La funzionalità Single Sign-On in Windows Vista è stata sviluppata per risolvere i problemi relativi agli accessi di dominio e alla separazione delle VLAN autenticate in base alle credenziali utente e computer e per rispondere alla necessità di richiedere all'utente credenziali diverse in momenti differenti. Grazie a Single Sign-On, gli amministratori di rete possono specificare che l'autenticazione wireless tramite le credenziali utente deve aver luogo prima del processo di accesso utente. Quando le credenziali utente necessarie per l'accesso e per l'autenticazione wireless sono diverse, vengono tutte richieste e raccolte nella schermata di accesso di Windows.
Con Single Sign-On, un client wireless di Windows Vista può essere configurato per eseguire l'autenticazione di rete wireless con le credenziali utente prima del processo di accesso utente. Nella Figura 2 viene illustrata la nuova sequenza temporale di avvio e accesso.
Figura 2 Sequenza temporale quando l'autenticazione di rete wireless con le credenziali utente si verifica prima dell'accesso utente
Figura 2 Sequenza temporale quando l'autenticazione di rete wireless con le credenziali utente si verifica prima dell'accesso utente
In questo modo, le configurazioni che utilizzano solo credenziali utente o una combinazione di credenziali utente e computer con VLAN separate non perdono alcuna funzionalità. Poiché il client wireless è dotato di connettività di rete o connettività alla VLAN autenticata in base alle credenziali utente prima che inizi il processo di accesso utente, le operazioni di accesso di dominio possono essere eseguite correttamente. Per un esempio, vedere "Connessione di un client wireless Windows Vista a un dominio" all'indirizzo microsoft.com/technet/network/wifi/vista_bootstrap_wireless.mspx.
In base alla configurazione del profilo wireless, Single Sign-On consolida i campi di input per le credenziali utente per l'autenticazione wireless e li aggiunge alla schermata di accesso di Windows. Pertanto, l'utente fornisce nello stesso momento tutte le proprie credenziali, necessarie per l'accesso utente e l'autenticazione wireless basata su di esse.
I metodi Extensible Authentication Protocol (EAP) scritti per la nuova architettura EAPHost in Windows Vista possono utilizzare l'API di supporto EAP Pre-Logon Authentication Provider (PLAP) in modo da includere i campi di input necessari per l'autenticazione nella schermata di accesso di Windows. Per ulteriori informazioni, vedere l'API di SSO e PLAP all'indirizzo msdn2.microsoft.com/bb530584.
Come esempio di una sessione di Single Sign-On, considerare un client wireless di Windows Vista configurato per eseguire l'autenticazione utilizzando solo le credenziali utente e un nome utente e una password sia per l'accesso di dominio che per l'autenticazione 802.1X. Quando si preme CTRL+ALT+CANC nella schermata iniziale di Windows Vista, Single Sign-On stabilisce che l'autenticazione 802.1X deve avere luogo prima dell'accesso utente. Quando l'utente digita il nome utente e la password, Single Sign-On esegue prima l'autenticazione di rete wireless basata sulle credenziali utente, quindi visualizza un messaggio che indica che si sta connettendo alla rete wireless per nome. Dopo l'autenticazione wireless, in Windows Vista viene eseguito l'accesso utente e visualizzato il desktop dell'utente.

Configurazione di Single Sign-On
Dietro le quinte
Per comprendere meglio il processo di autenticazione wireless, è opportuno esaminare da vicino cosa accade quando l'utente cerca attivamente di accedere. Quando si preme CTRL+ALT+CANC per l'accesso utente in un client wireless dotato di Windows Vista, si verificano i passaggi seguenti.
  1. Configurazione automatica reti wireless determina il profilo di rete wireless da utilizzare. Se il client wireless ha già eseguito correttamente l'autenticazione tramite le credenziali computer, viene utilizzato il profilo di rete wireless attualmente connesso. Se il profilo wireless determinato è configurato per eseguire l'autenticazione soltanto con le credenziali computer, non è necessaria l'autenticazione wireless aggiuntiva tramite le credenziali utente. I passaggi da 2 a 6 presuppongono che il profilo wireless selezionato sia configurato per eseguire l'autenticazione con le credenziali utente, che Single Sign-On sia abilitato per tale profilo e che sia selezionata l'impostazione Esegui immediatamente prima dell'accesso utente.
  2. L'utente digita le proprie credenziali per l'accesso utente e l'autenticazione wireless (se necessario) e inizia il processo di accesso.
  3. In Windows, un messaggio informa l'utente che è in corso il tentativo di connessione al nome di rete wireless specificato.
  4. In Windows viene eseguito il tentativo di autenticare la rete wireless tramite le credenziali utente. Se è abilitata l'impostazione Consenti visualizzazione di finestre di dialogo aggiuntive durante Single Sign On e per il tipo EAP è necessario che siano visualizzate ulteriori finestre di dialogo, queste ultime sono visibili. Se l'autenticazione wireless non si verifica correttamente entro il Ritardo massimo connettività (secondi), viene abbandonata. Se è selezionata l'impostazione La rete utilizza una VLAN diversa per l'autenticazione con credenziali utente e computer, in Windows viene eseguito il rinnovo DHCP della configurazione di indirizzo IP della scheda di rete wireless, quando l'autenticazione wireless ha buon esito.
  5. In Windows viene eseguito il processo di accesso utente.
  6. In Windows viene visualizzato il desktop.
Se è selezionata l'impostazione Esegui immediatamente dopo l'accesso utente, in Windows vengono eseguiti i passaggi, nell'ordine seguente: 1, 2, 5, 3, 4, 6.

Per attivare e configurare Single Sign-On, è possibile utilizzare l'estensione dei Criteri di gruppo relativa ai criteri di rete wireless (IEEE 802.11) e configurare le impostazioni di protezione avanzate per un profilo wireless di un criterio Windows Vista. Per ulteriori informazioni sull'argomento, vedere "Impostazioni dei Criteri di gruppo wireless per Windows Vista" all'indirizzo technetmagazine.com/issues/2007/04/CableGuy .
Nella finestra di dialogo Impostazioni di protezione avanzate, selezionare l'opzione Attiva Single Sign-On per la rete e configurare le opzioni di Single Sign-On come necessario. Nella Figura 3 viene illustrato un esempio di Single Sign-On abilitato con le impostazioni predefinite.
Figura 3 Impostazioni predefinite di Single Sign-On
Figura 3 Impostazioni predefinite di Single Sign-On
Sono disponibili impostazioni di Single Sign-On per eseguire l'autenticazione wireless 802.1X immediatamente prima o dopo il processo di accesso utente e per specificare il ritardo per il completamento dell'autenticazione 802.1X prima di iniziare tale processo. È inoltre possibile indicare se visualizzare finestre di dialogo oltre al consolidamento dei campi di input nella schermata di accesso di Windows. Ad esempio, se per un tipo di EAP l'utente deve confermare il certificato inviato dal server Remote Authentication Dial-in User Service (RADIUS) durante l'autenticazione, il tipo di EAP può visualizzare la finestra di dialogo.
Inoltre è possibile specificare che il client wireless dovrebbe iniziare il rinnovo Dynamic Host Configuration Protocol (DHCP) della configurazione TCP/IP della scheda wireless dopo l'esecuzione dell'autenticazione basata sull'utente. Selezionare questa opzione se esistono VLAN separate per client wireless autenticati tramite le credenziali computer e utente e se tali VLAN sono sottoreti IPv4 o IPv6 distinte.
Una volta creato il profilo wireless contenente le impostazioni di Single Sign-On entro il criterio, è anche possibile configurare i client wireless di Windows Vista esportando il profilo come file XML, quindi importando il profilo XML nei client wireless di Windows Vista.
Per creare un profilo wireless XML di Single Sign-On, generare un profilo wireless con le impostazioni di Single Sign-On appropriate. Nella scheda Generale del criterio wireless di Windows Vista, fare clic sul profilo wireless con le impostazioni di Single Sign-On, quindi selezionare Esporta. Quando richiesto, specificare il nome file XML del profilo e il relativo percorso.
Per utilizzare il profilo XML di Single Sign-On allo scopo di configurare un altro client wireless di Windows Vista, importare il profilo XML tramite il comando:
netsh wlan add profile filename=
    "[FileName].xml"
Per stabilire se Single Sign-On è abilitato per un profilo wireless, utilizzare:
netsh wlan show profile=[ProfileName]
Le impostazioni di Single Sign-On sono elencate nella sezione "Security settings" della visualizzazione del comando netsh wlan show profile e nel testo degli eventi della connessione wireless nel registro eventi di Windows. È inoltre possibile utilizzare lo snap-in Visualizzatore eventi per esaminare gli eventi nella cartella Microsoft\Windows\WLAN-AutoConfig dei Registri applicazioni e servizi con l'origine "WLAN-AutoConfig" e gli ID di evento 13001, 13002, 13003 e 13004.
Per ulteriori informazioni, visitare la pagina Web sulle connessioni alle reti wireless all'indirizzo microsoft. com/wifi. Vedere anche l'intestazione laterale "Dietro le quinte" per ulteriori dettagli sul processo Single Sign-On.

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


 Note di ricerca: Utilizzo del calcolo ad alte prestazioni nella lotta contro l'HIV
Note di ricerca
Utilizzo del calcolo ad alte prestazioni nella lotta contro l'HIV
Kristin Firth e Mia Matusow

Pensando alle persone che conducono una ricerca medica, si immaginano sempre uomini e donne in camice bianco da laboratorio che lavorano con provette e microscopi? Forse un team di chimici all'università o presso un'azienda farmaceutica? Si tratta di immagini comuni e certamente reali di ricerca medica, ma rappresentano solo
un aspetto di un campo molto vasto. Nella realtà, alcune ricerche mediche vengono eseguite in condizioni molto diverse.
Potrebbe essere una sorpresa sapere che Microsoft Research riveste un ruolo chiave nell'impegno per sviluppare un vaccino contro il virus dell'immunodeficienza umano (HIV). Inoltre Microsoft opera senza un solo becco Bunsen. La struttura somiglia a un comune spazio per uffici, arredato con scrivanie tradizionali e molti computer.
Allora, quale ruolo svolge Microsoft nella ricerca? Le persone in camice bianco, ovvero gli scienziati nelle varie università e centri di ricerca, fra gli altri il Mass General di Boston, l'Università della British Columbia, l'Università di Washington, il Centro di ricerca sul cancro Fred Hutchinson e l'Università Murdoch in Australia, raccolgono grandi quantità di dati nei loro progetti. Il gruppo eScience presso Microsoft Research, formato da una mezza dozzina di persone, la maggior parte con base a Redmond, nello stato di Washington (e una persona in Nuovo Messico), aiuta i ricercatori a elaborare e analizzare enormi quantità di dati. Microsoft Research è stata coinvolta in questo progetto per la prima volta nel 2003 e oggi il gruppo eScience collabora con gli scienziati su un'intera gamma di progetti che affrontano i problemi della nostra società. La squadra lavora a stretto contatto con gli scienziati esterni, creando soluzioni personalizzate per i progetti, elaborando i numeri e analizzando i risultati.
In un progetto ad alta priorità, Microsoft sta contribuendo all'analisi dei dati relativi ai modelli di mutazione dell'HIV. David Heckerman, medico, Dottore di ricerca, Ricercatore senior presso Microsoft, spiega che l'HIV muta rapidamente quando viene attaccato dal sistema immunitario di un individuo infetto. "Lavoriamo su uno studio che tenta di determinare come muta l'HIV in risposta al sistema immunitario dell'ospite. A tale scopo, ricerchiamo correlazioni fra un tipo di sistema immunitario dell'individuo e le sequenze proteiche dell'HIV che lo infetta".
Gli scienziati utilizzano campioni prelevati da persone contagiate dall'HIV per determinare il loro tipo di sistema immunitario e le sequenze proteiche dell'HIV. A questo punto entra in gioco l'elaborazione dei dati. Lo studio ricerca correlazioni tra 3000 aminoacidi dell'HIV e le centinaia di tipi di sistema immunitario in molte centinaia di individui. "Abbiamo ideato test statistici che forniscono correlazioni più affidabili, con un numero ridotto di falsi positivi e negativi", afferma Carl Kadie, Dottore di ricerca, Principal Research Software Development Engineer per Microsoft. "Tuttavia quei test richiedono una grande potenza di calcolo. Inoltre più elevato è il numero di soggetti inclusi, migliori sono i risultati. L'idea è eseguire milioni di simulazioni per evidenziare le correlazioni più affidabili".

Utilizzo di HPC nella lotta contro l'HIV
Solo pochi anni fa, le limitazioni di elaborazione ostacolavano l'impegno nella ricerca. Con solo mezza dozzina di computer, i ricercatori Microsoft coinvolti in questo progetto non avevano a disposizione una potenza di elaborazione sufficiente per eseguire l'analisi in un tempo adeguato. Esaminare tutte le posizioni nel genoma virale per il vaccino e i diversi immunotipi avrebbe richiesto un intero anno per soli 200 soggetti. Anche se i ricercatori avessero avuto a disposizione 20 computer dedicati per l'analisi, avrebbero comunque dovuto affrontare il problema fondamentale di eseguire i test manualmente su 20 computer separati, ricevendo 20 serie singole di risultati, quindi sarebbe stato necessario un altro programma (e più tempo) per catalogare le serie separate di risultati. La gestione di vari lavori simultaneamente, la raccolta dei risultati parziali e tutte le altre singole attività coinvolte avrebbero richiesto troppo tempo. Pertanto si sono rivolti al gruppo High-Performance Computing (HPC) di Microsoft.
Nel 2006, i ricercatori hanno implementato Windows® Compute Cluster Server 2003. La soluzione HPC ha offerto ai ricercatori un modo semplice per convogliare la potenza di molti computer che lavorano insieme. Essenzialmente, Windows Compute Cluster Server consente di distribuire il lavoro su nodi server che funzionano in parallelo. L'attività di distribuire dati fra i nodi, gestire le informazioni e combinare i risultati è completamente automatizzata. La soluzione comprende le procedure di installazione, una suite di strumenti di gestione e un'utilità di pianificazione integrata.
Infine, con questa soluzione, erano stati superati gli ostacoli tecnici più significativi: la potenza di calcolo non era più limitata e il processo di distribuire il lavoro e gestire i dati era completamente automatizzato.

Installazione
Per Microsoft Research, l'approccio con cluster di calcolo era l'ideale. Windows Compute Cluster Server 2003 è perfetto per i progetti che coinvolgono applicazioni che eseguono la stessa operazione in continuo, ad esempio quando la risoluzione dei problemi e l'analisi possono essere accelerate procedendo in parallelo. Tuttavia la distribuzione di questa soluzione deve essere valutata con cura, poiché il calcolo ad alte prestazioni può rivelarsi dispendioso, specie in termini di alimentazione e raffreddamento. Coinvolge infatti vari server che spesso utilizzano la CPU al 100% per settimane.
Nei passaggi successivi viene illustrato come determinare le dimensioni del cluster appropriate per l'organizzazione e dove poterlo conservare. Se si tratta di un ambiente già basato su Windows con Active Directory® attivo, gli amministratori dispongono dell'infrastruttura necessaria per installare, distribuire e supportare un cluster. Negli ambienti dove Active Directory non è in uso, sono richiesti alcuni passaggi di configurazione aggiuntivi.
È inoltre necessario decidere come fornire nodi al cluster di calcolo, ovvero scegliere se utilizzare gli strumenti in dotazione con Windows Compute Cluster Server 2003 o ricorrere a tecniche di distribuzione interne. È necessario distribuire Windows Compute Cluster Server 2003 insieme alle applicazioni software che si desidera eseguire sul cluster. Devono essere stabiliti i criteri di accesso utente al cluster, in modo che gli utenti siano in grado di connettersi al cluster e inviare i lavori, tramite l'interfaccia utente grafica o mediante interfacce della riga di comando.
Windows Compute Cluster Server 2003 è un sistema operativo a 64 bit (l'architettura tipica di un ambiente Windows Compute Cluster Server 2003 è illustrata nella Figura 1). Al momento della redazione del presente articolo (giugno 2007), Microsoft Research eseguiva una varietà di applicazioni diverse su un cluster creato con 25 eServer 326 IBM. Ciascuno di questi server è dotato di 2 processori Opteron AMD a 2,6 GHz.
Figura 1 Ottimizzazione della potenza con Windows Compute Cluster Server 2003
Figura 1 Ottimizzazione della potenza con Windows Compute Cluster Server 2003
Una volta distribuito Windows Compute Cluster Server, il gruppo ha aggiornato l'applicazione utilizzata per eseguire la correlazione genetica sul cluster. La distribuzione delle applicazioni nei cluster di calcolo può variare per complessità. L'entità della programmazione richiesta dipende dalle applicazioni stesse.
Inizialmente il gruppo ha utilizzato gli strumenti integrati in Windows Compute Cluster Server per definire in modo rapido un'interfaccia utente generica. Si trattava di una misura provvisoria. Infatti poco dopo il gruppo ha creato la propria applicazione Web personalizzata, che assicura una maggiore flessibilità e supporta l'opzione di esporre alcuni dei nodi cluster agli scienziati esterni a Microsoft. Microsoft fa parte dell'Open Grid Forum e alcuni dei cluster di Microsoft Research vengono quindi messi a disposizione degli utenti di altre università nel mondo, consentendo ai ricercatori di collaborare e condividere il carico di lavoro.
Oltre alle interfacce utente grafiche, in Windows Compute Cluster Server sono supportate le operazioni da riga di comando e gli utenti possono creare script. Inoltre sono disponibili API di alto livello per scrivere programmi che interagiscono direttamente con Windows Compute Cluster Job Scheduler, una tecnica che Microsoft Research ha scelto di utilizzare.

Conseguimento dei risultati
Grazie all'utilizzo del calcolo ad alte prestazioni, il gruppo eScience di Microsoft Research ha compiuto grandi progressi verso lo sviluppo di un vaccino per l'HIV. "Con il calcolo ad alte prestazioni, siamo riusciti ad approfondire le nostre conoscenze più rapidamente", afferma Heckerman. "Diversi dei gruppi esterni con cui collaboriamo adesso utilizzano le nostre tecniche statistiche e condividono le loro scoperte. Di conseguenza, gli scienziati si presentano da noi già con le nuove ipotesi da verificare. In precedenza, ottenere i risultati avrebbe richiesto un anno per ciascun passaggio del processo. Ora è sufficiente un solo giorno".
Prima di Windows Compute Cluster Server, i metodi utilizzati da Microsoft Research non sarebbero stati adeguati, a causa del tempo necessario per eseguire l'analisi. "Con Windows Compute Cluster Server," dichiara Kadie, "possiamo eseguire 50 lavori di 200.000 elementi ciascuno nello stesso tempo utilizzato per portare a termine 1 lavoro".
Ora che il gruppo eScience dispone di enormi funzionalità di calcolo, può condurre test con molte elaborazioni su dati simulati. Le elaborazioni su dati simulati consentono di individuare quali risultati sui dati reali possono rivelarsi interessanti. Più simulazioni vengono eseguite, maggiore sarà l'affidabilità dei risultati.

Esperienze acquisite
Microsoft Research ha ricavato ovvi benefici dall'uso di Windows Compute Cluster Server, ma si tratta di una relazione di natura simbiotica. Gli sviluppatori del gruppo High-Performance Computing, impegnati su una seconda versione di Windows Compute Cluster Server, continuano ad aumentare le proprie conoscenze grazie a commenti e suggerimenti forniti dal gruppo eScience.
In particolare, il gruppo HPC ha acquisito una grande esperienza nell'allocazione delle risorse monitorando e analizzando il comportamento del cluster di Microsoft Research per determinare il modo migliore di bilanciare le risorse del cluster fra i vari utenti. Ad esempio, su questo progetto, un utente crea in genere un lavoro per volta con una media di 50 attività associate a ciascun lavoro. L'utente invia il lavoro e Windows Compute Cluster Job Manager assegna risorse sufficienti per gestire tutte le 50 attività. A tale scopo, vengono immediatamente richiesti tutti i nodi disponibili sul cluster per lavorare sulle attività. Questo scenario non sarebbe problematico in un ambiente a singolo utente, ma lo diventa in un'impostazione multiutente dove è molto importante che i progetti avanzino simultaneamente.
Al momento, quando 10 delle 50 attività sono state completate, non vengono liberati 10 server. Job Manager attende finché tutte le 50 attività del lavoro non vengono completate prima di liberare i server e affrontare un altro lavoro. Gli sviluppatori HPC ora sono impegnati a trovare un modo per riallocare le risorse al completamento di ciascuna attività, senza dover attendere il completamento dell'intero lavoro.
Microsoft Research ha richiesto il supporto del gruppo HPC anche per risolvere problemi specifici riguardo al modo in cui i ricercatori desideravano utilizzare Windows Compute Cluster Server. Nello specifico, i ricercatori desideravano impostare la protezione in modo che le credenziali utente si propagassero automaticamente dal front-end Web al cluster di calcolo. La soluzione era utilizzare Microsoft® .NET Framework ed estendere l'autenticazione di moduli ASP.NET in modo che l'applicazione Web potesse fornire ai nodi cluster le credenziali utente complete ogni volta un utente inviava un lavoro.
Ora i componenti del team eScience presso Microsoft Research e i loro colleghi di tutto il mondo possono concentrarsi sulle parti più importanti del lavoro e lasciare ai computer tutte le attività coinvolte nell'elaborazione e nella gestione dei dati. "Di conseguenza, possiamo procedere come una squadra", afferma Heckerman. "Ci stiamo spingendo oltre i limiti della conoscenza sull'HIV, con grandi progressi nella lotta contro la malattia."

Kristin Firth e Mia Matusowentrambe di Blue Line Writing & Editing, hanno trascorso gli ultimi dieci anni creando contenuto strategico per le aziende e le organizzazioni nei settori pubblici e privati in tre continenti.


 Windows PowerShell: Scrittura di espressioni regolari
Windows PowerShell
Scrittura di espressioni regolari
Don Jones

192.168.4.5. \\Server57\Share. johnd@contoso.com. Sono certo che i lettori riconosceranno immediatamente queste tre stringhe, identificandone i formati come corrispondenti, nell'ordine, a un indirizzo IP, a un percorso UNC (Universal Naming Convention) e a un indirizzo di posta elettronica. I quattro gruppi di cifre, le barre rovesciate, il simbolo @ e altri elementi indicano chiaramente il tipo di dati rappresentato da queste
stringhe di caratteri. Sarà sufficiente appena qualche attimo di riflessione per mettere a fuoco che in realtà 192.168.4.5 non è un indirizzo IP valido, così come \\Server57\Share non è un percorso UNC valido e johnd@contoso.com non è un indirizzo di posta elettronica valido.
I computer, purtroppo, devono sforzarsi un po' di più per "riconoscere" formati complicati come questi. Ed ecco dove entrano in gioco le espressioni regolari. Un'espressione regolare è una stringa scritta con l'ausilio di uno speciale linguaggio, che aiuta un computer a identificare altre stringhe di un particolare formato, ad esempio indirizzi IP, UNC o indirizzi di posta elettronica. Se scritta in modo appropriato, un'espressione regolare consente a uno script di Windows PowerShellTM di accettare in quanto validi o rifiutare in quanto non validi i dati immessi a seconda che siano conformi o meno al formato specificato.

Corrispondenze semplici
L'operatore –match di Windows PowerShell confronta una stringa con un'espressione regolare e restituisce True o False a seconda che la stringa corrisponda o meno all'espressione in questione. Nel caso di espressioni regolari molto semplici, non è necessaria nemmeno una sintassi speciale. È sufficiente infatti che vengano utilizzati caratteri letterali. Ad esempio:
"Microsoft" –match "soft"
"Software" –match "soft"
"Computers" –match "soft"
Se eseguite in Windows PowerShell, le prime due espressioni restituiscono True mentre la terza restituisce False. In ciascuna di esse, una stringa è seguita da un operatore –match, che a sua volta è seguito da un'espressione regolare. Per impostazione predefinita, un espressione regolare scorre la stringa di input per trovare una corrispondenza. La sequenza di caratteri "soft" è presente sia in Software che in Microsoft, sebbene in posizioni differenti. Si tenga presente inoltre che, per impostazione predefinita, un'espressione regolare non è sensibile alla distinzione tra maiuscole e minuscole: la sequenza di caratteri "soft" viene trovata infatti in "Software" nonostante la lettera maiuscola S.
Tuttavia, se necessario, un operatore differente, –cmatch, consente di confrontare espressioni regolari tenendo conto della distinzione tra maiuscole e minuscole, come nell'esempio seguente:
"Software" –cmatch "soft"
Questa espressione restituisce False poiché non viene individuata alcuna corrispondenza tra "soft" e "Software" in un confronto che rileva la distinzione tra maiuscole e minuscole. Si noti che l'operatore –imatch è disponibile anche come opzione esplicita per un confronto senza distinzione tra maiuscole e minuscole, sebbene questo sia il comportamento predefinito di –match.

Caratteri jolly e ripetitori
Un'espressione regolare può contenere un numero limitato di caratteri jolly. Un punto, ad esempio, corrisponde a un'istanza di qualsiasi carattere, mentre un punto interrogativo corrisponde a zero o a un'istanza di qualsiasi carattere. Ecco di seguito qualche esempio:
"Don" –match "D.n" (True)
"Dn" –match "D.n" (False)
"Don" –match "D?n" (True)
"Dn" –match "D?n" (True)
Nella prima espressione, il punto sostituisce esattamente un carattere, quindi la corrispondenza è True. Nella seconda espressione, invece, il punto non trova il singolo carattere necessario da includere, pertanto la corrispondenza è False. Il punto interrogativo, come mostrato nella terza e nella quarta espressione, può corrispondere a un unico carattere sconosciuto o a nessun carattere. Quindi nel quarto esempio la corrispondenza è True in quanto vengono trovati sia "D" che "n" senza un carattere che li separi. In sostanza, dunque, si può dire che il punto interrogativo rappresenti un carattere facoltativo, per cui la corrispondenza risulta True anche se in quella data posizione non vi è alcun carattere.
Un'espressione regolare è in grado di riconoscere anche i simboli * e + come ripetitori. Questi simboli devono seguire uno o più caratteri. In particolare, il simbolo * corrisponde a zero o più caratteri specificati, mentre il simbolo + corrisponde a uno o più caratteri specificati. Ecco alcuni esempi:
"DoDon" –match "Do*n" (True)
"Dn" -match "Do*n" (True)
"DoDon" -match "Do+n" (True)
"Dn" -match "Do+n" (False)
Si noti che sia il simbolo * che il simbolo + corrispondono alla stringa "Do", non semplicemente al carattere "o". Questi ripetitori infatti sono stati progettati per corrispondere a una serie di caratteri e non a uno solo.
Ecco come bisogna procedere se si desidera cercare le corrispondenze del punto e dei simboli *, ? o +. È sufficiente farli precedere da una barra rovesciata, che è il carattere escape delle espressioni regolari:
"D.n" -match "D\.n" (True)
Come si può notare, questo carattere differisce dal carattere escape di Windows PowerShell, ovvero l'apostrofo inverso, ma segue la sintassi delle espressioni regolari standard del settore.

Classi di caratteri
Una classe di caratteri è una forma più estesa di carattere jolly e rappresenta un intero gruppo di caratteri. Windows PowerShell riconosce solo un numero limitato di classi di questo tipo, ad esempio:
  • \w corrisponde a un qualsiasi carattere alfanumerico, ovvero lettere e numeri.
  • \s corrisponde a un qualsiasi carattere che rappresenti uno spazio bianco, ad esempio una tabulazione, uno spazio e così via.
  • \d corrisponde a una qualsiasi carattere numerico.
Esistono anche classi di caratteri negativi: \W corrisponde a un qualsiasi carattere non alfanumerico, \S a un qualsiasi carattere che non sia uno spazio bianco e \D a un qualsiasi carattere che non sia una numero. Queste classi possono essere seguite dai simboli * o + per indicare che sono ammesse più corrispondenze. Ecco alcuni esempi:
"Shell" -match "\w" (True)
"Shell" -match "\w*" (True)
Cmdlet del mese
Il cmdlet Write-Debug è molto utile per la scrittura di oggetti, come stringhe di testo, nella pipeline Debug. Tuttavia, l'utilizzo di questo cmdlet nella shell può risultare piuttosto deludente, in quanto sembra che non produca alcun effetto.
Il trucco è che la pipeline Debug è disattivata per impostazione predefinita: la variabile $DebugPreference è infatti impostata su "SilentlyContinue". Sarà sufficiente impostarla su "Continue" e tutti i dati trasmessi con Write-Debug verranno visualizzati nella console sotto forma di testo di colore giallo. Si tratta di un metodo ideale per aggiungere codice traccia ai propri script, con la possibilità di seguire l'esecuzione di uno script complesso. Il colore giallo aiuta a distinguere il codice traccia dal normale output dello script ed è possibile disattivare i messaggi di debug in qualsiasi momento senza dover rimuovere tutte le istruzioni Write-Debug. Basta impostare nuovamente $DebugPreference su "SilentlyContinue" e il testo relativo al debug verrà eliminato.

Sebbene entrambe le espressioni restituiscano True, in realtà le corrispondenze nei due casi differiscono considerevolmente. Fortunatamente, esiste un modo per capire il procedimento logico applicato dall'operatore –match: ogni volta che viene trovata una corrispondenza, una variabile speciale denominata $matches viene popolata con i relativi risultati, ovvero tutti i caratteri della stringa per cui l'operatore ha individuato una corrispondenza in base all'espressione regolare. La variabile $matches conserva i risultati finché non viene eseguito un nuovo confronto con esito positivo mediante l'operatore –match. Nella Figura 1 viene illustrata la differenza tra le due espressioni che ho appena descritto. Come si può osservare, \w trova la corrispondenza di "S" in "Shell", mentre \w* trova la corrispondenza dell'intera parola.
Figura 1 La semplice aggiunta di un simbolo * può essere determinante.
Figura 1 La semplice aggiunta di un simbolo * può essere determinante.

Gruppi, intervalli e dimensioni di caratteri
Un'espressione regolare può contenere anche gruppi o intervalli di caratteri, racchiusi tra parentesi quadre. Ad esempio, [aeiou] indica che qualsiasi carattere tra quelli specificati tra parentesi, ovvero a, e, i, o, u, è una corrispondenza accettabile. [a-zA-Z] indica invece che qualsiasi lettera compresa nell'intervallo a-z o A-Z è accettabile, sebbene, se si utilizza l'operatore –match che non è sensibile alla distinzione tra maiuscole e minuscole, è sufficiente specificare semplicemente a-z o A-Z. Ecco un esempio:
"Jeff" -match "J[aeiou]ff" (True)
"Jeeeeeeeeeeff" -match "J[aeiou]ff" (False)
Con l'ausilio delle parentesi graffe, è anche possibile specificare un numero minimo e un numero massimo di caratteri. {3} indica, ad esempio, che si desidera trovare tre occorrenze, {3,} indica invece che si desidera trovare almeno tre occorrenze e {3,4}, infine, che si desidera trovare almeno tre ma non più di quattro occorrenze del carattere specificato. Quella appena illustrata rappresenta un'ottima soluzione per creare espressioni regolari per gli indirizzi IP:
"192.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
L'espressione regolare sopra riportata richiede quattro gruppi contenenti ciascuno da uno a tre numeri, separati da un punto letterale. Ma si consideri ora l'esempio seguente:
"300.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
Appaiono qui evidenti i limiti di un'espressione regolare. Sebbene infatti il formato di questa stringa sia simile a quello di un indirizzo IP, è chiaro tuttavia che non si tratta di un indirizzo IP valido. Un'espressione regolare non è in grado di determinare la validità dei dati ma solo la correttezza del formato.

Come rendere le espressioni di tipo non-float
La risoluzione dei problemi correlati alle espressioni regolari può essere difficoltosa. Ad esempio, di seguito è riportata un'espressione la cui finalità è quella di testare un percorso UNC nel formato \\Server2\Share:
"\\Server2\Share" -match "\\\\\w+\\\w+" (True)
In questo caso, l'espressione regolare è di per sé difficile da leggere in quanto ogni barra rovesciata letterale da testare deve essere preceduta dal carattere escape, ovvero da una seconda barra rovesciata. Sebbene tutto sembri funzionare correttamente, in realtà non è così:
"57\\Server2\Share" -match "\\\\\w+\\\w+" (True)
Il percorso di questo secondo esempio è, almeno per me, ma non per l'espressione regolare, palesemente un percorso UNC non valido. Perché? Si ricordi che, per impostazione predefinita, un'espressione regolare è di tipo float. Questa espressione regolare si limita a ricercare due barre rovesciate, uno o più caratteri alfanumerici, una nuova barra rovesciata e altri caratteri alfanumerici. Tale schema è effettivamente presente nella stringa di input, ma sono anche presenti alcune cifre supplementari, che rendono il percorso UNC non valido. La soluzione in questo caso consiste nel fare in modo che l'espressione regolare inizi a ricercare le corrispondenze a partire dall'inizio della stringa. A tale scopo, è possibile procedere nel modo seguente:
"57\\Server2\Share" -match "^\\\\\w+\\\w+" (False)
Il carattere ^ indica l'inizio della stringa. Aggiungendo questo carattere, il percorso UNC non valido ha esito negativo in quanto l'espressione regolare ricerca come primi due caratteri della stringa due barre rovesciate e, in questo caso, non le trova.
Analogamente, il simbolo $ può essere utilizzato per indicare la fine di una stringa. Nel caso specifico di un percorso UNC, tuttavia, non risulterebbe di grande utilità poiché questo tipo di percorso può contenere segmenti aggiuntivi, ad esempio \\Server2\Share\Folder\File. Sono certo però che esistono molte situazioni in cui può essere necessario specificare la fine di una stringa.

Supporto per l'utilizzo delle espressioni regolari
In Windows PowerShell, l'argomento della Guida dedicato alle espressioni regolari offre assistenza sulla sintassi di base per il linguaggio di questo tipo di espressioni, ma le risorse in linea forniscono una quantità maggiore di informazioni. Ad esempio, in uno dei miei siti Web preferiti, www.RegExLib.com, è disponibile una libreria gratuita di espressioni regolari scritte per svariati scopi con il contributo degli utenti. È possibile eseguire ricerche sulla base di parole chiave, ad esempio "e-mail" o "UNC", per individuare rapidamente un'espressione regolare che può soddisfare le proprie esigenze o rappresentare un buon punto di partenza. Se si riesce a creare una buona espressione regolare, è possibile aggiungerla alla libreria in modo da renderla disponibile anche per altri utenti.
Un altro sito che trovo molto utile è RegexBuddy (www.RegexBuddy.com). Questo sito fornisce un economico editor grafico per le espressioni regolari. RegexBuddy semplifica l'assemblaggio di un'espressione regolare complessa e consente di testare facilmente qualsiasi espressione di questo tipo per verificare che accetti solo le stringhe valide, rifiutando invece quelle non valide. Anche altri sviluppatori software hanno creato editor e tester di espressioni regolari, disponibili in versione gratuita, shareware o commerciale, che gli utenti troveranno senz'altro interessanti.

Utilizzo delle espressioni regolari
Forse i lettori si staranno chiedendo il motivo per il quale dovrebbero utilizzare le espressioni regolari nella vita reale. Immaginiamo di dover leggere informazioni da un file CSV e di doverle utilizzarle per creare nuovi utenti in Active Directory®. Se il file CSV è stato generato da qualcun altro, con ogni probabilità si vorrà verificare che i dati all'interno siano corretti. Un'espressione regolare è la soluzione ideale per questo tipo di attività. Un'espressione regolare semplice come \w+, ad esempio, è in grado di controllare che i nomi e i cognomi non contengano simboli o caratteri speciali, mentre un 'espressione più complessa consente di controllare che gli indirizzi di posta elettronica siano conformi allo standard aziendale. Ad esempio, si potrebbe utilizzare l'espressione seguente:
"^[a-z]+\.[a-z]+@contoso.com$"
Questa espressione regolare richiede un indirizzo di posta elettronica nel formato don.jones@contoso.com, in cui il nome e il cognome possono contenere solo lettere e devono essere separati da un punto. Gli indirizzi di posta elettronica, tra l'altro, sono tra le cose più complicate per cui scrivere un'espressione regolare. Se si è in grado di restringere l'ambito a uno specifico standard aziendale, sarà molto più facile raggiungere l'obiettivo.
Non vanno dimenticati i simboli di inizio e fine (^ e $), che garantiscono che nulla segua contoso.com e che nulla preceda i caratteri che compongono il nome dell'utente.
In effetti l'utilizzo di questa espressione regolare in Windows PowerShell è piuttosto semplice. Se si presume che la variabile $email contenga l'indirizzo di posta elettronica letto dal file CSV, un'espressione simile alla seguente consentirà di verificare se l'indirizzo è valido:
$regex = "^[a-z]+\.[a-z]+@contoso.com$"
If ($email –notmatch $regex) {
  Write-Error "Invalid e-mail address $email"
}
In questo esempio viene introdotto anche un nuovo operatore: -notmatch restituisce True se la stringa non corrisponde all'espressione regolare fornita (esiste anche un operatore –cnotmatch per i confronti con distinzione tra maiuscole e minuscole).
Sono ancora molti gli argomenti da trattare in merito alle espressioni regolari che non mi è stato possibile affrontare in questa sede, ad esempio le classi di caratteri aggiuntive, le operazioni più avanzate, altri operatori e naturalmente il tipo di oggetto [regex] supportato da Windows PowerShell. Tuttavia, quanto ho illustrato in questa rapida panoramica sulla sintassi delle espressioni regolari dovrebbe essere sufficiente per iniziare. Chiunque abbia bisogno di aiuto per districarsi con un'espressione regolare particolarmente complessa, può contattarmi in qualsiasi momento sul sito Web www.ScriptingAnswers.com.

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


 Hey, Scripting Guy!: Gestione desktop dall'aldil&#224;
Hey, Scripting Guy!
Gestione desktop dall'aldilà
Gli Scripting Guy di Microsoft
Scarica il codice per questo articolo: HeyScriptingGuy2007_11.exe (151KB)

A causa della domanda travolgente, si è pensato di fare qualcosa di diverso questo mese: anziché iniziare parlando della creazione degli script di amministrazione del sistema, si comincerà (riprodurre la musica lugubre) raccontando una storia di fantasmi!
Nota: OK, tecnicamente, se davvero questo mese si volesse fare qualcosa di diverso, si dovrebbe iniziare subito a parlare della creazione degli script di amministrazione del sistema. Ma si può giocare un po' insieme, no? Grazie!
Molti anni fa, una delle bis-bis-bis-bisnonne degli Scripting Guy morì. Poco dopo la sua sepoltura, in una semplice bara di legno, il marito iniziò ad avere dei terribili incubi, nei quali la sua amata moglie cercava disperatamente di scavare una via d'uscita dalla fossa. Dopo vari incubi, e varie implorazioni, il marito riuscì finalmente a convincere le autorità locali a riesumare il corpo. Quando la bara venne aperta, con orrore tutti constatarono che le unghie della moglie si erano incurvate all'indietro e l'interno della bara era ricoperto di graffi!
OK, questa storia potrebbe non essere completamente vera; in effetti, a pensarci bene, sembra proprio che non lo sia per niente. Tuttavia, la storia ha una lezione importante da insegnare. Non è chiaro quale sia, ma da qualche parte c'è una lezione.
Ah, un secondo, eccola qua: originariamente, le bare erano concepite per proteggere il deceduto dagli elementi e aiutare a impedire la decomposizione del corpo. Purtroppo però hanno avuto una conseguenza involontaria: consentono, almeno in teoria, di seppellire una persona viva e assicurarsi che non riesca a uscire. Come dimostra chiaramente la storia della bis-bis-bis-bisnonna degli Scripting Guy, anche i piani meglio preordinati da uomini e mouse possono causare disastri e persone sepolte vive (riprodurre un'altra volta la musica lugubre)!
Nota: a meno che, naturalmente, non si preferisca la bara inventata da Franz Vester negli anni '60 del 1800. Si trattava di una versione migliorata, contenente una cordicella collegata a una campana, che rimaneva in superficie; nel caso di una sepoltura prematura, il "deceduto" poteva semplicemente far suonare la campana per chiedere aiuto. La bara migliorata comprendeva anche una scala pieghevole, benché non sia ovvio come tale dispositivo possa aiutare a uscire da una bara sepolta due metri sottoterra. Certo, se capitava di essere seppelliti sul tetto di un garage, una scala pieghevole poteva essere utile. In caso contrario...
La stessa cosa (ovvero il fatto che i piani meglio preordinati possano condurre a disastri) è vera per i firewall di Internet (almeno in un certo senso). Originariamente, i firewall erano concepiti per impedire l'accesso ai malintenzionati: bloccano il traffico di rete in entrata, contribuendo a tenere hacker e intrusi lontani dai computer. Ciò è molto positivo ma, come per il problema di essere seppelliti vivi, implica una conseguenza involontaria: il firewall può escludere anche gli utenti con buone intenzioni. Questo è vero soprattutto nel caso di Strumentazione gestione Windows®, che si affida a DCOM per eseguire attività amministrative sui computer remoti. I firewall tendono a bloccare tutto il traffico DCOM in entrata, il che rende estremamente difficile (se non impossibile) gestire i computer su Internet a livello di programmazione. In effetti, senza aprire porte aggiuntive sul firewall, diventando in tal modo più vulnerabili per hacker e cracker, ciò è impossibile. A meno che, ovviamente, non si scelga WinRM: Gestione remota Windows (la scala pieghevole non è inclusa).

Cos'è Gestione remota Windows?
Secondo WinRM SDK (msdn2.microsoft.com/aa384426), Gestione remota Windows è l'implementazione Microsoft del protocollo WS-Management, un protocollo standard, basato su SOAP, di facile integrazione con i firewall, che consente all'hardware e ai sistemi operativi di diversi fornitori di interoperare. Notevole, no? Non verranno discussi i dettagli del protocollo WS-Management nell'articolo di questo mese, quindi per tali informazioni si consiglia di leggere WinRM SDK. Per il momento, è importante sapere che WinRM è disponibile in Windows Server® 2003 R2, Windows Vista® e Windows Server 2008 e che consente di gestire i computer su Internet. WinRM opera tramite la porta 80, una porta per servizi Internet standard che la maggior parte dei firewall lascia aperta (comunque la porta utilizzata da WinRM e dal metodo di trasporto predefinito, HTTP, può essere modificata come necessario).
Inoltre, nell'articolo di questo mese, non verrà illustrato come installare e configurare WinRM. A tale scopo, sono già disponibili informazioni abbondanti (msdn2.microsoft.com/aa384372). Tuttavia, è necessario dedicare un momento per sottolineare un punto importante: se si desidera utilizzare WinRM per recuperare informazioni da un computer remoto (il che, naturalmente, è il motivo principale per ricorrere a WinRM), sia il computer locale che quello remoto devono eseguire WinRM.
Cosa significa? Beh, significa che se non è ancora stato eseguito l'aggiornamento dei computer client a Windows Vista (ma non è così, vero?) o dei server a Windows Server 2003 R2 o a Windows Server 2008, WinRM non sarà molto utile, almeno non oggi. Inutile dire, comunque, che probabilmente non sarà così domani (e certo, supponendo che il firewall lo consenta, è sempre possibile utilizzare WinRM e DCOM per gestire i computer remoti).

Restituzione di tutte le proprietà e istanze di una classe
Ma a chi interessano le avvertenze e le dichiarazioni di non responsabilità? Invece di perdere tempo con discorsi inutili e confusi, è il momento di provare a escogitare un modo per scrivere uno script che sia in grado di avvantaggiarsi di WinRM. Per iniziare, ecco un piccolo, semplice script che, utilizzando il protocollo HTTP e la porta 80, si connette a un computer denominato atl-fs-01.fabrikam.com e restituisce informazioni complete su tutti i servizi installati in tale sistema. Vedere la Figura 1 per lo script in tutta la sua gloria.
Figure 1 Componenti del progetto Silverlight (Close Figure 1)

File | Descrizione
CreateSilverlight.js | È uno script JScript (nella versione iniziale Silverlight supporta solo script JScript) utilizzato per specificare le impostazioni di avvio iniziali di Silverlight, compreso il file XAML utilizzato per configurare l'interfaccia utente e gli oggetti grafici.
SampleProject.js | Un file vuoto in cui è possibile inserire le funzioni JScript.
Silverlight.js | Questo file viene utilizzato per inizializzare il controllo Silverlight.
SampleProject.html | Il file che contiene la parte più divertente. SampleProject.html è semplicemente un file HTML che include codice per la lettura dei tre file js. Contiene inoltre il codice per la creazione dell'istanza del controllo Silverlight.
SampleProject.xaml | A che serve questo file? Per scoprirlo, è necessario tornare al testo principale dell'articolo.
Figure 1 Elenco dei servizi su un computer remoto (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service"

Set objResponse = objSession.Enumerate(strResource)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
Come si può notare, all'inizio il nome DNS del computer (atl-fs-01.fabrikam.com) è stato assegnato a una variabile denominata strComputer. In alternativa, è possibile stabilire la connessione utilizzando l'indirizzo IP del computer (o persino il suo indirizzo IPv6). Ad esempio:
strComputer = "192.168.1.1"
Dopo l'assegnazione di un valore a strComputer, si crea un'istanza dell'oggetto WSMan.Automation, quindi viene richiamato il metodo CreateSession per connettersi al computer remoto, in questo caso utilizzando il protocollo HTTP (proprio come era stato anticipato):
Set objSession = objWRM.CreateSession _
    ("http://" & strComputer)
Come si è notato, si desidera che vengano restituite informazioni relative ai servizi installati nel computer remoto. Inoltre, e almeno per questo primo esempio, si desiderano informazioni su tutte le proprietà di tutti i servizi. Che cosa significa tutto questo? Significa che è necessario specificare una Risorsa URI che vincoli alla classe Win32_Service sul computer remoto:
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2" & _
  "/Win32_Service"
Effettivamente non è l'URI più bello in circolazione (ma, d'altronde, riflettendoci, non è detto che esistano URI belli). Fortunatamente, tuttavia, la maggior parte dell'URI è standard; l'unico punto importante è il percorso WMI alla fine:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service
Dovrebbe essere piuttosto semplice. E se si desiderasse connettersi alla classe root/cimv2/Win32_Process? Beh, in tal caso sarebbe sufficiente modificare il percorso URI di conseguenza:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process
Si è interessati alla classe root/default/SystemRestore? Ancora una volta, è sufficiente modificare la classe URI, facendo attenzione a specificare lo spazio dei nomi predefinito (anziché lo spazio dei nomi cimv2):
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/default/SystemRestore
E così via... È un po' un peccato dover includere anche la parte dell'URI http://schemas.microsoft.com/wbem/wsman/1/wmi, ma...
A questo punto si è pronti per ottenere alcuni dati. A tale scopo, è sufficiente richiamare il metodo Enumerate, passando la variabile strResource quale unico parametro corrispondente:
Set objResponse = _
  objSession.Enumerate(strResource)
La riga di codice popolerà effettivamente objResponse con informazioni relative ai servizi installati sul computer atl-fs-01? Lo farà senz'altro. Tuttavia, a differenza degli script WMI standard, non viene restituita una serie di oggetti, ciascuno con le sue proprietà e metodi di proprietà. Invece, si otterrà una grande, tipica massa XML che assomiglia un po' a quella riportata nella Figura 2.
Figure 2 Possibili colori da utilizzare (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>
Figure 2 Grande, tipica massa XML (Close Figure 2)
<p:Win32_Service xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service" xmlns:ci
m="http://schemas.dmtf.org/wbem/wscim/1/common" xsi:type="p:Win32_Service_Type"
xml:lang="en-US"><p:AcceptPause>false</p:AcceptPause><p:AcceptStop>false</p:Acce
ptStop><p:Caption>Windows Media Center Service Launcher</p:Caption><p:CheckPoint
>0</p:CheckPoint><p:CreationClassName>Win32_Service</p:CreationClassName><p:Desc
ription>Starts Windows Media Center Scheduler and Windows Media Center Receiver
services at startup if TV is enabled within Windows Media Center.</p:Description
><p:DesktopInteract>false</p:DesktopInteract><p:DisplayName>Windows Media Center
Per gli esperti di XML non è una novità: chiunque conosca l'XML dovrebbe essere in grado di analizzare e generare queste informazioni senza troppe difficoltà (benché, secondo WinRM SDK, questi dati non siano espressi in "formato leggibile" dagli esseri umani). Ma per chi non conosce l'XML? In tal caso sono disponibili due scelte. La prima è aspettare il mese prossimo, quando verranno illustrati alcuni trucchi per operare con l'XML di WinRM. La seconda è ripetere quanto è stato fatto nello script di esempio: utilizzare la trasformazione XSL installata unitamente a WinRM.

La trasformazione XSL?
Una trasformazione XSL è semplicemente un modello che descrive come dovrebbe essere visualizzato un file XML. Una discussione completa dei file XSL non rientra nell'ambito dell'articolo di questo mese. Del resto, anche una discussione superficiale dei file XSL andrebbe oltre i limiti del presente articolo. Pertanto non si cercherà di spiegare come funziona effettivamente WsmTxt.xsl (il nome della trasformazione incorporata). Al contrario, verrà illustrato soltanto come utilizzare la trasformazione negli script.
Quando viene richiamato il metodo Enumerate, WinRM restituisce un flusso di dati XML. Il modo più facile per operare con questi dati è impostare un ciclo Do Until che continua a essere eseguito finché non si raggiunge la fine del flusso di dati. Ecco come si procede:
Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop
Come si può notare, nel ciclo viene richiamata una sottoroutine denominata DiplayOutput. Al momento di richiamare la sottoroutine, viene passato il valore del metodo ReadItem del flusso, come parametro corrispondente (come implica l'intero approccio, il flusso XML viene rinviato in porzioni separate, anziché in un'unica grande massa di dati; lo script, a sua volta, legge i dati XML in singole porzioni, o elementi).
Nel frattempo, la sottoroutine DisplayOutput assume l'aspetto seguente:
Sub DisplayOutput(strWinRMXml)
  Set xmlFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  Set xslFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  xmlFile.LoadXml(strWinRMXml)
  xslFile.Load("WsmTxt.xsl")
  Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
In breve, si inizia creando due istanze dell'oggetto MSXml2.DOMDocument.3.0. Prima viene caricato il flusso di dati XML (strWinRMXML) in un oggetto, quindi il file XSL (WsmTxt.xsl) nell'altro oggetto. A questo punto viene richiamato il metodo TransformNode per utilizzare le informazioni nel file XSL allo scopo di formattare e visualizzare i dati raccolti dal flusso XML.
È vero, tutto questo può confondere. Ma almeno è un po' più facile leggere l'output (per quanto imperfetto) (vedere la Figura 3).
Figure 3 Applicazione di colori al testo (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>
Figure 3 Una versione più ordinata dell'XML (Close Figure 3)
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
    Description = This service is responsible for loading and unloading user profiles. If this service is stopped or disabled, users will no longer be able to successfully logon or logoff, applications may have problems getting to users' data, and components registered to receive profile event notifications will not receive them.
Come si è detto, i risultati sono soddisfacenti, ma non straordinari. Proprio per questo è opportuno tornare il mese prossimo, quando verranno illustrati vari modi per manipolare l'output XML da soli.

Restituzione di istanze e proprietà selezionate di una classe
Inutile a dirsi, tutto ciò è molto interessante, tranne per un aspetto: potrebbe non riflettere completamente il tipico modo di operare del lettore. A volte si può desiderare che vengano restituite tutte le proprietà di tutte le istanze di una classe, ma altre volte, forse più spesso, è sufficiente ottenere solo proprietà o istanze selezionate di una classe. Ad esempio, potrebbe essere opportuno solo ricevere informazioni sui servizi in esecuzione. Ciò è possibile utilizzando uno script WMI regolare simile al seguente:
Set colItems = objWMIService.ExecQuery _
  ("Select * From Win32_Service " & _
   "Where State = 'Running'")
Funziona. Ma come sarà mai possibile modificare la stringa Resource per renderla equivalente?
Beh, per essere sinceri, la stringa Resource non deve essere modificata per renderla equivalente all'istruzione ExecQuery. È certamente necessario modificare la stringa Resource, ma devono essere effettuate anche altre operazioni.
Ricordando questi presupposti, si consideri la Figura 4. Si tratta di uno script WinRM che restituisce informazioni sui servizi in esecuzione su un computer (invece che su tutti i servizi installati in tale computer).
Figure 4 Suggerimenti di TextBlock (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
Figure 4 Individuazione dei servizi in esecuzione (Close Figure 4)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"
strFilter = "Select * From Win32_Service Where State = 'Running'"
strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
A un primo sguardo, potrebbe sembrare identico al primo script WinRM illustrato, ma esistono alcune differenze molto importanti. Innanzitutto, si consideri il valore assegnato alla stringa Resource:
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2/*"
Si noti che, nella scrittura di una query filtrata, non viene specificato il nome effettivo della classe (Win32_Service) con cui si desidera operare; al contrario, ci si connette semplicemente allo spazio dei nomi (root/cimv2) dove risiede tale classe. È importante ricordare di aggiungere l'asterisco (*) alla fine. In caso contrario lo script non riesce e un messaggio indica che il nome della classe deve essere '*' (stella), ovvero che è necessario creare il nome della classe *.
Inoltre devono essere definiti un Filtro e un Tipo:
strFilter = _
  "Select * From Win32_Service " & _
  "Where State = 'Running'"
strDialect = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/WQL"
Non dovrebbe essere difficile individuare il Filtro: si trova nel punto di inserimento della query Windows Management Instrumentation Query Language (WQL) ("Select * From Win32_Service Where State = 'Running'"). Il Tipo, d'altra parte, è il linguaggio di query utilizzato per la creazione del Filtro. Attualmente è consentito solo un linguaggio di query: WQL. Tuttavia, è necessario specificare il Tipo, altrimenti lo script non riesce e viene visualizzata la nota "il tipo di filtro... non è supportato".
Nota: il messaggio di errore suggerisce di rimuovere il Tipo quando viene richiamato il metodo Enumerate. Tuttavia è consigliabile non seguire tale raccomandazione. Quando viene eseguita una query filtrata, è necessario specificare il Tipo, che deve essere WQL. Tutto qui.
L'unica altra modifica richiesta ha luogo quando viene richiamato il metodo Enumerate. A questo punto, è necessario passare le variabili che rappresentano il Filtro (strFilter) e il Tipo (strDialect), nonché la variabile della Risorsa (strResource) :
Set objResponse = _
  objSession.Enumerate _
  (strResource, strFilter, strDialect)
Provare e verificare il risultato.
Ma come restituire solo le proprietà selezionate di una classe? Ad esempio, si supponga di essere interessati a ottenere solo le proprietà Name e DisplayName di tutti i servizi in esecuzione su un computer. Cosa accadrebbe?
In un caso del genere si può provare a manipolare l'XML in modo da visualizzare solo Name e DisplayName. Ciò è possibile, ma indubbiamente non facile. Un modo più semplice per conseguire questo risultato è specificare solo le proprietà desiderate al momento di assegnare il Filtro:
strFilter = _
  "Select Name, DisplayName " & _
  "From Win32_Service " & _
  "Where State = 'Running'"
Fatto questo, si otterranno solo le proprietà Name e DisplayName per ciascun servizio:
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
È vero, la formattazione è un po' particolare (ad esempio, cosa c'entra la parte XmlFragment?). Ragione di più per tornare il mese prossimo.

In attesa
Con un po' di fortuna, quanto è stato illustrato dovrebbe essere sufficiente per iniziare a cimentarsi con il mondo selvaggio e meraviglioso di WinRM. Certo, non è possibile concludere un articolo su WinRM senza citare gli "obitori di attesa", un tempo molto diffusi in Germania. Nelle città con gli obitori di attesa, i cadaveri non venivano seppelliti subito. Al contrario, venivano collocati in sale riscaldate con numerose cordicelle e fili collegati alle dita delle mani e dei piedi. Il presupposto era, naturalmente, che il più lieve movimento avrebbe attivato un allarme e fatto intervenire il personale. I corpi venivano tenuti negli obitori di attesa finché non era chiaro che queste persone erano veramente senza speranza e non si sarebbero più mosse.
A pensarci bene, essere ricoverati in un obitorio di attesa è molto simile a far parte del team degli Scripting Guy, no? Certo, nessuno è mai ritornato in vita in un obitorio di attesa, mentre chi è stato assegnato al team degli Scripting Guy...

Il rompicapo di script del Dottor Scripto.
A giugno 2007, gli Scripting Guy hanno assistito alla conferenza Tech•Ed 2007 di Orlando, Florida. Non contenti di assistere semplicemente alla conferenza, hanno deciso di divertirsi. Non solo, hanno pensato che sarebbe piaciuto anche ad altri. Pensando a questo, hanno trovato il Fun Book del Dottor Scripto, un opuscolo pieno di puzzle correlati agli script e varie altre informazioni. Di conseguenza si sono alleati con il team di TechNet Magazine, ovvero li hanno convinti a ospitarli in un angolo del loro stand nella sala dell'esposizione, da dove hanno distribuito copie del Fun Book ai visitatori.
Il Fun Book ha riscosso un grande successo (forse non paragonabile a quello delle bambole bobblehead del Dottor Scripto, ma abbastanza simile). I gentili e opportunisti rappresentanti di TechNet Magazine, notando un altro modo per approfittare del successo degli Scripting Guy (che peraltro non sembrano mai capaci di avvantaggiarsene loro stessi), hanno chiesto loro di creare dei puzzle. Quando la Scripting Guy Jean Ross ha voltato le spalle per un attimo, lo Scripting Guy Greg Stemp ha detto: "Certo, lo faremo!". Ed ecco il risultato: il rompicapo di script del Dottor Scripto. Buon lavoro.

Creazione di uno script rilasciando caratteri
Per risolvere il puzzle, riordinare tutte le lettere nella sezione superiore in modo da creare uno script (in VBScript). Niente paura: non è necessario riordinare lo script tutto insieme, è sufficiente procedere una colonna per volta. Le lettere in ogni colonna della sezione superiore devono riempire gli spazi della stessa colonna nella sezione inferiore. Ecco un esempio:
Come si può vedere, nella colonna 1 sono incluse le lettere S, C e T. Queste tre lettere appartengono alla griglia sottostante, in un ordine sconosciuto. Ma quando tutte le lettere vengono rilasciate nella sezione inferiore secondo l'ordine appropriato, la griglia in basso, letta da sinistra a destra, mostra una stringa logica. Uno sguardo alla soluzione:
Le lettere S, C e T nella colonna 1 si spostano in basso nell'ordine T, S e C. Queste lettere sono le iniziali delle parole "The Script Center". Il puzzle vero e proprio è un po' più difficile: in primo luogo è più lungo e poi il risultato finale è un script completo.
Suggerimento: lo script finale inizia con un percorso completo a un file, quindi lo isola e visualizza solo il nome del file.
Buona fortuna!

Il rompicapo di script del Dottor Scripto.
Risposta: Creazione di uno script rilasciando caratteri, novembre 2007
In questo puzzle, è necessario rilasciare i caratteri di una colonna inserendoli nelle caselle sottostanti, in modo da creare uno script nelle righe inferiori. Ecco lo script completo:
name = "C:\Scripts\Test.txt"
arr = Split(name, "\")
index = Ubound(arr)
Wscript.Echo "Filename: " _
& arr(index)
Aspetto dello script nella griglia del puzzle:

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


 Controllo della protezione: Protezione dell'accesso da postazioni remote
Controllo della protezione
Protezione dell'accesso da postazioni remote
John Morello

Un'innegabile tendenza dell'attuale mercato tecnologico è il costante aumento della connettività e della mobilità della forza lavoro. Il personale di molte organizzazioni lavora in uffici dislocati, da casa o viaggia di frequente per incontrare i clienti. Una soluzione ottimale per aumentare la produttività consiste pertanto nel fornire agli utenti la possibilità di accedere ad applicazioni e dati in modo facile e
indipendentemente da dove si trovino. Tuttavia, fino a poco tempo fa, l'attivazione dell'accesso protetto da postazioni remote comportava l'installazione di software client, l'immissione di comandi sconosciuti e lunghi tempi di connessione.
Nel corso degli ultimi anni, sono stati sviluppati numerosi approcci per semplificare e rendere più accessibile la tecnologia per l'accesso remoto. Ad esempio, Outlook® Web Access (OWA) fornisce un metodo semplice e basato su browser per accedere alla posta elettronica, al calendario e ai contatti, senza le complessità associate a una rete privata virtuale (VPN) di livello 3. Anche se le tecnologie come OWA possono rappresentare un componente importante per soluzioni di "accesso da postazioni remote", la maggior parte delle organizzazioni dispone di molte applicazioni importanti che non consentono di utilizzare lo stesso tipo di browser integrato. In questi casi, soluzioni quali i Servizi terminal offrono un metodo efficace per consentire agli utenti di accedere alle applicazioni da qualsiasi luogo in cui si trovano.
In Microsoft Windows Server® 2008, sono stati apportati notevoli miglioramenti all'insieme di funzionalità incorporate nei Servizi terminal, che includono una finestra intuitiva, una funzionalità di pubblicazione per applicazione denominata RemoteApp, una funzionalità del driver di stampa universale denominata EasyPrint e un portale basato su browser denominato Accesso Web di Servizi terminal. Inoltre, Windows Server 2008 include il componente Gateway di Servizi terminal che, oltre a essere fondamentale per scenari di accesso da postazioni remote, fornisce l'incapsulamento SSL per il protocollo RDP (Remote Desktop Protocol), che potrà quindi attraversare in modo semplice e protetto i firewall e i dispositivi NAT (Network Address Translation). La funzionalità Gateway di Servizi terminal si integra anche con un'altra tecnologia innovativa di Windows Server 2008, ovvero Protezione accesso alla rete (NAP), per fornire il controllo dell'integrità dell'endpoint del client. Se vengono integrati tutti questi componenti, le organizzazioni potranno creare soluzioni che consentono agli utenti di accedere in modo semplice e protetto alle applicazioni e ai dati da postazioni remote.
Questo articolo è incentrato sugli aspetti relativi alla progettazione della protezione e della rete per una soluzione di accesso da postazioni remote e non sulla gestione dei componenti dei Servizi terminal. Verranno descritti i metodi e le procedure consigliate per creare tale soluzione utilizzando le tecnologie incluse in Windows Server 2008.

Il problema delle reti VPN di livello 3
Quando si valuta l'implementazione di una nuova tecnologia, è importante considerarne i vantaggi rispetto alle soluzioni correnti, in modo da poter determinare in modo accurato il valore reale del nuovo modello. Nel caso di una classica rete VPN di livello 3, in genere, è necessario risolvere due principali problemi: la protezione e la facilità di utilizzo.
Potrebbe sembrare illogico elencare la protezione tra i problemi di molte reti VPN di livello 3 attualmente in uso, considerando il fatto che lo scopo primario di una rete VPN consiste nel fornire un tunnel di rete protetto attraverso Internet. Per comprendere questo aspetto, occorre esaminare in modo più approfondito ciò che in genere viene considerata una minaccia VPN. I dati trasportati sulle reti VPN non sono necessariamente soggetti a intercettazioni o manomissioni. La maggior parte delle reti VPN moderne di livello 3 forniscono un eccellente meccanismo di crittografia del flusso di dati. Si considerino, ad esempio, le minacce rappresentate da computer remoti a cui viene fornito l'accesso completo a "tutte le porte e tutti i protocolli" sulla rete dell'organizzazione. Il problema non consiste nei flussi di dati sottoposti a crittografia e trasportati dalla rete VPN di livello 3, bensì nei client remoti che vengono connessi tramite questi tunnel aumentando i rischi per la rete interna. Si tenga presente che la maggior parte delle organizzazioni che ha subito attacchi di malware, ad esempio Slammer o Blaster, non è stata infettata dai computer della rete interna o da utenti malintenzionati che hanno violato i firewall. Al contrario, l'infezione è stata causata da lavoratori non in sede che si sono connessi alle reti tramite VPN da computer infetti. Se tali reti VPN creano connessioni completamente instradate di livello 3, il computer remoto potrà spesso accedere alle risorse interne come un normale computer del centro dati.
Inoltre, le reti VPN di livello 3 sono in genere piuttosto costose, poiché l'installazione e la configurazione del software vengono effettuate in computer che non sono gestiti dal gruppo IT dell'organizzazione. Ad esempio, l'installazione di un client VPN nel computer di casa di un utente può richiedere la creazione di pacchetti di installazione personalizzati e di istruzioni di installazione dettagliate, nonché la risoluzione dei conflitti con le applicazioni presenti sul computer dell'utente. Inoltre, i costi di gestione possono essere elevati se è necessario distribuire nuove versioni del client o se vengono modificati i dati di configurazione, ad esempio tramite l'aggiunta di un nuovo endpoint VPN. Per quanto riguarda l'utente, l'utilizzo di una rete VPN risulta spesso poco intuitivo. Poiché fornisce solo la connessione di livello 3, i dati e le applicazioni aziendali dell'utente non sono facilmente accessibili e visibili.

Risoluzione dei problemi tramite i Servizi terminal
I Servizi terminal e altre tecnologie VPN a livello di applicazione o livello 7 consentono di risolvere i due problemi menzionati in precedenza offrendo agli utenti un controllo di qualità superiore delle risorse e dei protocolli, nonché semplificando e rendendo estremamente intuitiva l'esperienza utente.
Dal punto di vista della protezione, la caratteristica più importante che distingue l'approccio di una VPN di livello 3 da quello in cui vengono utilizzati i Servizi terminal e il Gateway di Servizi terminal consiste nel fatto che, nel secondo caso, la connessione alla rete interna non è rappresentata da una pipeline completamente aperta. Nello specifico, mentre l'approccio della VPN di livello 3 consente di creare un'interfaccia virtuale sul computer locale con funzionalità di routing complete nella rete interna, l'approccio del Gateway di Servizi terminal consente solo l'accesso alla rete interna da parte di pacchetti basati su RDP. Pertanto, la superficie di attacco complessiva risulta estremamente ridotta ed è possibile applicare controlli più granulari all'interno del protocollo RDP. Ad esempio, mentre RDP fornisce il supporto nativo per il reindirizzamento delle unità, le organizzazioni potrebbero configurare i propri Gateway di Servizi terminal per l'integrazione di Protezione accesso alla rete e non abilitare il reindirizzamento a meno non venga dimostrato che il software antivirus del computer è aggiornato.
Per gli utenti finali, la differenza più evidente tra l'approccio della VPN di livello 3 e quello basato sui Servizi terminal è rappresentata da una procedura di installazione molto più semplice (se non del tutto assente) e da un accesso molto più facile e intuitivo alle applicazioni e ai dati. Poiché il client di Connessione desktop remoto è integrato in Windows (e viene aggiornato tramite tecnologie di manutenzione standard quali Windows® Update), in genere non è richiesta alcuna installazione di software. Inoltre, grazie ad Accesso Web di Servizi terminal, è possibile utilizzare un singolo URL per accedere ad applicazioni e dati. È sufficiente fare clic sull'applicazione appropriata per avviare il tunneling protetto della connessione su Internet tramite Gateway di Servizi terminal e per ottenere l'accesso all'applicazione dal proprio desktop. In altre parole, l'applicazione avrà lo stesso aspetto e comportamento che avrebbe se fosse installata localmente, incluse le funzionalità di copia e incolla e di riduzione a icona sulla barra delle applicazioni. Grazie a una maggiore facilità di individuazione di applicazioni e dati e a un'installazione più rapida, l'approccio basato sui Servizi terminal per l'accesso remoto consente di soddisfare le esigenze dell'utente e a ridurre i costi di supporto.

Opzioni per l'architettura di rete
Esistono due approcci di base alla progettazione della rete, che possono essere utilizzati per rendere accessibile il server Gateway di Servizi terminal tramite Internet. Il primo inserisce il Gateway di Servizi terminal nella rete perimetrale tra due firewall di livello 3/4. Il secondo mantiene il Gateway di Servizi terminal nella rete interna e utilizza un firewall a livello di applicazione (ad esempio Microsoft® ISA Server, Microsoft Intelligent Application Gateway o una soluzione di terzi) per accedere alla rete perimetrale e controllare i frame HTTPS in ingresso. Solo una volta terminata l'analisi delle sessioni in ingresso, i pacchetti vengono inoltrati al server Gateway di Servizi terminal.
Se un'organizzazione dispone unicamente di firewall di livello 3/4 con un controllo di base dello stato dei pacchetti, il dispositivo Gateway di Servizi terminal può essere posizionato direttamente sulla rete perimetrale, come illustrato nella Figura 1. In questo esempio di progettazione, il firewall Internet limita la connettività al Gateway di Servizi terminal per consentirne l'accesso solo al traffico HTTPS proveniente da Internet. Tuttavia, il firewall non esegue il controllo del traffico a livello di applicazione, ma inoltra semplicemente il traffico al Gateway di Servizi terminal, che estrae quindi i frame RDP dai pacchetti HTTPS e li inoltra al server back-end appropriato. Questi server back-end vengono spesso isolati dalla rete perimetrale tramite un ulteriore firewall, configurato per consentire ai frame RDP provenienti dal Gateway di Servizi terminal di raggiungere i server interni appropriati.
Figura 1 Con un firewall di livello 3/4, il Gateway di Servizi terminal viene posizionato sulla rete perimetrale
Figura 1 Con un firewall di livello 3/4, il Gateway di Servizi terminal viene posizionato sulla rete perimetrale
Sebbene sia completamente supportato e possa risultare utile in molte organizzazioni, questo scenario presenta due principali svantaggi. Innanzitutto, poiché riceve il traffico direttamente da Internet, il Gateway di Servizi terminal è esposto a rischi maggiori di attacchi esterni da parte di utenti malintenzionati. Dal momento che il firewall front-end controlla solo le intestazioni e non i payload delle sessioni, tali utenti potrebbero facilmente accedere al gateway tramite una sessione SSL e queste sessioni potrebbero raggiungere il gateway. Ciò non significa che il Gateway di Servizi terminal sia un componente vulnerabile, poiché è stato sottoposto agli stessi rigorosi metodi di progettazione e test di protezione utilizzati per tutti i componenti di Windows Server 2008. Tuttavia, in questo scenario il rischio relativo è superiore perché verrebbe gestito traffico non filtrato che proviene direttamente da Internet. Il secondo svantaggio consiste nell'aumento di traffico richiesto tra il gateway e il firewall back-end. Per eseguire l'autenticazione degli utenti, è necessaria la comunicazione tra il Gateway di Servizi terminal e Active Directory®. A questo scopo, il firewall back-end deve disporre di eccezioni per una gamma molto più ampia di porte e protocolli, anziché semplicemente per il protocollo HTTPS. Anche in questo caso, l'aumento del livello di comunicazione implica un aumento del rischio relativo nella soluzione di progettazione.
Un approccio migliore per l'esposizione a Internet di un Gateway di Servizi terminal consiste nell'utilizzo di un firewall a livello di applicazione (livello 7) per gestire le sessioni HTTPS in ingresso prima che possano accedere al gateway (vedere la Figura 2). Anche questa soluzione di progettazione può includere i tradizionali firewall di livello 3/4 sulla rete perimetrale, con la differenza che il Gateway di Servizi terminal viene sostituito dal firewall di livello 7. Nel firewall esterno, vengono filtrati tutti gli elementi di traffico, eccetto i frame HTTPS, che vengono quindi inoltrati al firewall di livello 7. Quest'ultimo terminerà la sessione SSL, controllerà i contenuti non crittografati nel flusso di dati, bloccherà il traffico dannoso e invierà i frame RDP al Gateway di Servizi terminal attraverso il firewall back-end. Se lo si desidera, è possibile impostare il firewall di livello 7 in modo che i frame vengano nuovamente crittografati prima di essere inviati al Gateway di Servizi terminal. Questo approccio potrebbe non essere necessario nella rete privata di un'organizzazione, tuttavia può risultare molto utile nei centri dati ospitati o nelle reti condivise.
Figura 2 Utilizzo di un firewall a livello di applicazione con un dispositivo Gateway di Servizi terminal
Figura 2 Utilizzo di un firewall a livello di applicazione con un dispositivo Gateway di Servizi terminal
Questa soluzione di progettazione consente di eliminare entrambi gli svantaggi della soluzione precedente. Poiché il server Gateway di Servizi terminal riceve solo traffico controllato dal firewall di livello 7, il rischio di attacchi provenienti da Internet è minore. Il firewall di livello 7 dovrebbe infatti filtrare tali attacchi e inviare al gateway solo traffico controllato e ripulito.
Un ulteriore vantaggio di questa soluzione consiste nel posizionamento del gateway in base alla rete interna. Poiché il traffico proveniente da Internet viene controllato dal firewall di livello 7 prima di raggiungere il gateway, quest'ultimo può rimanere nella rete interna e accedere direttamente ai controller di dominio per l'autenticazione e agli host RDP per le sessioni dell'utente. Inoltre, è possibile impostare nel firewall back-end criteri più restrittivi. Invece di consentire sia il traffico di autenticazione delle directory che quello di RDP, è possibile semplicemente consentire il passaggio delle sessioni RDP dal firewall di livello 7 al Gateway di Servizi terminal. L'utilizzo di un firewall di livello 7 per la distribuzione del Gateway di Servizi terminal offre una soluzione più protetta e più semplice da gestire, senza richiedere una riprogettazione della rete perimetrale esistente.

Integrazione con NAP
Risorse dei Servizi terminal
  • Servizi terminal in Windows Server 2008
  • Forum di TechNet sui Servizi terminal in Windows Server 2008
  • Blog del team sui Servizi terminal
  • Microsoft Intelligent Application Gateway 2007
  • Protezione accesso alla rete (NAP) per Windows Server 2008
  • Blog sulla Protezione accesso alla rete
  • Guide dettagliate su Windows Server 2008 Beta 3

Anche se una progettazione valida della rete perimetrale è un elemento importante per la soluzione di accesso da postazioni remote, è altrettanto importante garantire la conformità e la protezione dei dispositivi endpoint. Poiché RDP è un protocollo completo che consente il reindirizzamento di diversi tipi di dispositivi, ad esempio stampanti e sessioni RDP, è di importanza fondamentale che i client connessi alla rete soddisfino i criteri di protezione dell'organizzazione. Ad esempio, anche con una topologia di rete protetta, basata su procedure consigliate come quelle illustrate in precedenza, la connessione a un server terminal da un computer non protetto può comunque comportare la perdita di dati riservati o l'introduzione di file dannosi nel server terminal. Sebbene il livello di connettività e il potenziale di danneggiamento siano estremamente minori rispetto a una connessione tramite reti VPN di livello 3, è importante gestire il rischio associato alla perdita di dati e garantire la conformità con i criteri IT.
Protezione accesso alla rete è una nuova tecnologia di Windows Server 2008 che consente di controllare non solo gli utenti che possono connettersi alla rete, ma anche i tipi di sistemi da cui viene effettuata la connessione. Ad esempio, è possibile utilizzare Protezione accesso alla rete per garantire che le connessioni siano consentite solo da computer che dispongono di firewall e aggiornamenti antivirus. Protezione accesso alla rete è una soluzione estendibile non solo per la rete interna dell'organizzazione ma anche per gli utenti remoti, inclusi quelli connessi tramite VPN di livello 3 e quelli connessi tramite Gateway di Servizi terminal. Con l'integrazione di Protezione accesso alla rete nella soluzione di progettazione del Gateway di Servizi terminal, è possibile garantire che solo i sistemi che soddisfano i criteri di protezione specificati siano in grado di connettersi alla rete. Per ulteriori dettagli su Protezione accesso alla rete, è possibile consultare il mio articolo Controllo della protezione nel numero di maggio 2007 di TechNet Magazine, disponibile in linea all'indirizzo technetmagazine.com/issues/2007/05/SecurityWatch.
L'integrazione di Protezione accesso alla rete in una distribuzione di Gateway di Servizi terminal è un processo semplice che comporta l'aggiunta di un unico servizio alla soluzione di progettazione. Si tratta del servizio Server dei criteri di rete, che può essere installato nel server Gateway di Servizi terminal oppure in un'istanza separata del sistema operativo. Microsoft Management Console (MMC) del Gateway di Servizi terminal verrà quindi utilizzato per creare criteri di autorizzazione delle connessioni che definiscano le funzionalità RDP consentite per un determinato stato di integrità. Il server Gateway di Servizi terminal è configurato per verificare ogni tentativo di connessione e inoltrare il relativo rapporto di integrità al servizio Server dei criteri di rete, che confronterà il rapporto di integrità con i propri criteri e segnalerà al Gateway di Servizi terminal se la connessione è consentita o meno in base allo stato del client.
Come illustrato nella Figura 3, se un sistema non conforme non è configurato per utilizzare Windows Update, ma i criteri di protezione dell'organizzazione richiedono l'attivazione degli aggiornamenti automatici, se si esegue un tentativo di connessione al Gateway di Servizi terminal, verrà generato e inoltrato un rapporto di integrità. Tale rapporto potrebbe indicare, ad esempio, che il firewall è attivo, che l'antivirus è aggiornato ma che gli aggiornamenti automatici sono disabilitati. Non disponendo della logica per decodificare autonomamente il rapporto, il Gateway di Servizi terminal lo inoltrerebbe al servizio Server dei criteri di rete che lo confronterebbe con i criteri definiti dall'amministratore. Poiché gli aggiornamenti automatici risulterebbero disabilitati, il servizio Server dei criteri di rete rileverebbe lo stato di non conformità e segnalerebbe al Gateway Servizi terminal di non consentire la connessione. La connessione verrebbe annullata e all'utente verrebbe notificato che il computer non è conforme ai criteri di protezione dell'organizzazione. L'utente potrebbe quindi adottare tutte le azioni di correzione necessarie (in questo caso, abilitando gli aggiornamenti automatici) ed effettuare un altro tentativo di connessione. Di conseguenza, verrebbe generato un nuovo rapporto di integrità, il servizio Server dei criteri di rete rileverebbe lo stato di conformità e il Gateway di Servizi terminal consentirebbe la connessione.
Figura 3 La connessione può essere effettuata solo da sistemi conformi
Figura 3 La connessione può essere effettuata solo da sistemi conformi

Conclusioni
Windows Server 2008 include gli elementi di base necessari per la creazione di una soluzione di accesso protetto da postazioni remote. Il Gateway di Servizi terminal offre un metodo protetto per eseguire il tunneling delle sessioni desktop remote su Internet e fornisce alle organizzazioni un'ampia gamma di opzioni di integrazione sulle reti esistenti. Tali opzioni includono il posizionamento del Gateway di Servizi terminal direttamente sulla rete perimetrale oppure l'utilizzo di un firewall di livello 7, ad esempio ISA Server o Intelligent Application Gateway, davanti al gateway. È possibile integrare Protezione accesso alla rete al Gateway di Servizi terminal per aggiungere alla soluzione funzionalità di controllo dell'integrità dell'endpoint. I controlli dell'endpoint consentono alle organizzazioni di verificare che le connessioni vengano effettuate non solo da utenti autorizzati, ma anche da computer conformi ai criteri di protezione IT. Se integrate, queste tecnologie forniscono alle organizzazioni funzionalità di accesso remoto più protette ed efficienti a livello operativo e che offrono un miglior servizio all'utente finale. Per ulteriori informazioni, è possibile consultare i siti elencati nell'intestazione laterale "Risorse dei Servizi terminal".

John Morello lavora in Microsoft dal 2000. Come consulente senior ha progettato soluzioni di protezione per le prime 100 aziende di Fortune nonché per clienti della difesa e civili. Attualmente è Senior Program Manager presso il gruppo Windows Server e si dedica alle tecnologie di accesso da postazioni remote. È possibile consultare il blog del suo team all'indirizzo blogs.technet.com/WinCAT.


 Desktop file: La verit&#224; sulla deframmentazione
Desktop file
La verità sulla deframmentazione
Wes Miller

La frammentazione del disco esiste da quando sono nati i dischi rigidi. Se si è preoccupati per il proprio sistema, è opportuno deframmentarlo regolarmente. Ciò probabilmente ricorda la tipica conversazione annuale con il dentista sull'uso del filo interdentale: bene, la deframmentazione è altrettanto importante.
A meno che non si tenga il computer sempre spento in un angolo, la frammentazione aumenta giorno per giorno. Fra un attimo si vedrà perché, ma prima è opportuno esaminare rapidamente la storia della deframmentazione.

Deframmentazione e Windows NT
Windows NT® non includeva un'utilità di deframmentazione incorporata che peraltro, secondo l'opinione del periodo, non era ritenuta necessaria. Dopotutto, NTFS era stato creato nell'obiettivo dell'ottimizzazione e non era vulnerabile alla frammentazione nella stessa misura di un volume FAT paragonabile. Ma, con il tempo, anche le prestazioni di NTFS possono risentire del posizionamento non ottimale dei file. Da questa situazione si è sviluppato un mercato fiorente di strumenti di deframmentazione di terze parti. Uno dei prodotti più popolari fra i professionisti IT era Diskeeper di Executive Software (oggi Diskeeper Corporation). Quando Windows 2000 ha integrato la funzionalità di deframmentazione, Microsoft ha ottenuto in licenza la tecnologia di Executive Software. In Windows® 2000 la funzionalità di deframmentazione era disponibile nello snap-in integrato Microsoft® Management Console (dfrg.msc), che poteva essere richiamato facendo clic su un volume o eseguendo manualmente defrag.exe dalla riga di comando. Benché non esistesse alcuna pianificazione e si potesse utilizzare solo una riga di comando con vincoli, molti professionisti IT hanno creato script funzionali per automatizzare la deframmentazione ricorrendo a tale versione incorporata. Defrag.exe in Windows XP e Windows Server® 2003 ha apportato un certo miglioramento alla versione precedente, ma offriva solo un'automazione limitata: era ancora necessario creare degli script.
Alcuni fornitori, incluso Winternals Software (il mio datore di lavoro precedente), producevano software per lo spazio di deframmentazione delle aziende. La maggior parte di questi prodotti funziona allo stesso modo, con una console centralizzata, un agente di qualche genere che risiede sui sistemi client (a volte in permanenza, altre volte solo su richiesta) e una struttura per determinare quando e come eseguire un'attività di deframmentazione.
Windows Vista® tende a continuare la tendenza di deframmentazione dei sistemi singoli, pur ottimizzando l'utilità e aggiungendo opzioni quali la deframmentazione dei piccoli frammenti dei file (di 64 MB o meno), che accelera il processo ma lascia molti frammenti di file più grandi sparsi sul disco. Lo stesso motore di deframmentazione è più potente in Windows Vista e Windows Server 2008 che nelle precedenti versioni di Windows. Inoltre viene eseguito automaticamente e non richiede pianificazione manuale. Ma se si gestisce una grande organizzazione e si desidera ottimizzare i sistemi in modalità diverse da quelle predefinite, può ancora essere necessario ottenere la licenza di software di terze parti. E, come nelle versioni precedenti, può risultare difficile deframmentare un volume in cui la compressione NTFS è abilitata e largamente utilizzata. Anche in questo scenario, potrebbe essere utile uno strumento di terze parti.

Come mai si verifica la frammentazione?
La frammentazione è dovuta al fatto che i file tendono a cambiare nel tempo. In linea di principio, i file di Windows di per sé non cambiano. O almeno non cambiano molto spesso: in effetti, ciò accade solo con le installazioni dei service pack e degli aggiornamenti software. Altrimenti i file di sistema rimangono abbastanza costanti. Dopo un aggiornamento di grandi proporzioni, come ad esempio l'installazione di un service pack, la frammentazione si verifica naturalmente, poiché i file che vengono aggiornati di solito non possono essere sovrascritti nelle posizioni che occupano sul disco (e potrebbe essere necessario un riavvio per aggiornali), il che determina un'ulteriore frammentazione.
D'altra parte i file e i dati dell'utente (nonché il Registro di sistema di Windows) sono soggetti a modifica costante. Operazioni continue di lettura, scrittura, modifica, copia ed eliminazione di file causano una notevole frammentazione, soprattutto quando la capacità dell'unità è esaurita.
Per visualizzare questa situazione, si pensi a un disco perfettamente ordinato, nel quale i file occupano lo spazio in modo contiguo, senza vuoti fra loro. Si supponga di aprire un file e modificarlo, quindi di cercare di salvarlo. Se le dimensioni del file sono aumentate, Windows deve salvare il file nel suo complesso in un'altra posizione del disco (ad esempio dopo il file N) oppure memorizzare i dati più recenti dopo il file N. Ciò significa che il file 2 ora è frammentato. Se a questo punto il file 1 viene modificato, si avranno due file frammentati. Ripetendo tali operazioni nel tempo, alla fine il sistema diventa molto frammentato, al punto che l'unità deve eseguire ricerche in varie posizioni per accedere a un file singolo. Con i grandi file di database, i file estesi dei dischi rigidi per le tecnologie di elaborazione virtuali e le abbondanti quantità di contenuti audio e video memorizzati su dischi di medie dimensioni, la frammentazione è abbastanza comune. Ovviamente, le dimensioni sempre maggiori dei dischi rigidi attuali rendono la frammentazione un problema meno importante, ma non lo risolvono. Inoltre i computer portatili meno recenti con dischi rigidi più piccoli perdono progressivamente sensibilità, diventano più lenti da avviare e richiedono più tempo per l'apertura e il salvataggio dei file.
L'aspetto chiave non è necessariamente il grado di frammentazione del sistema, ma quello dei singoli file. Da quando le prime utilità di deframmentazione si sono presentate sulla scena con elementi visivi multicolori, gli utenti li hanno esaminati e hanno pensato: "Voglio una barra di un solo colore". Ma in realtà questa è l'ultima cosa da desiderare. Alcuni prodotti cercano di mostrare i dischi come due blocchi: uno colorato (dati dei file) e l'altro solitamente bianco (spazio libero). Purtroppo, imporre una divisione di questo tipo è la cosa peggiore per un disco, se l'intenzione è ridurre al minimo la frequenza e il costo della deframmentazione. Se tutti i file dei dati sono stati compressi in modo aggressivo nella zona anteriore del disco, rimuovendo gran parte dello spazio libero, quando si modifica ulteriormente un file, le modifiche vengono scritte alla fine dei dati del file. Pertanto una deframmentazione di questo tipo in realtà è causa di frammentazione, a partire dalla successiva modifica del file. Anziché due blocchi di dati dei file organizzati con ordine, una buona deframmentazione crea un'immagine non necessariamente perfetta. Per un esempio, vedere la Figura 1 per il sistema di prova, prima della deframmentazione. Osservare quindi la Figura 2, in cui viene illustrato lo stesso sistema dopo che la deframmentazione di Windows è stata completata.
Figura 1 L'unità prima della deframmentazione
Figura 1 L'unità prima della deframmentazione
Figura 2 L'unità dopo la deframmentazione
Figura 2 L'unità dopo la deframmentazione
È importante notare che in Windows non ci si concentra sulla frammentazione dei file attraverso il disco, ma su quella dei file singoli (vedere la Figura 3 per la sezione del rapporto di deframmentazione sui file più frammentati, prima che il sistema venisse deframmentato).
Figura 3 Rapporto di deframmentazione
Figura 3 Rapporto di deframmentazione
Di conseguenza, anche dopo la deframmentazione, in Windows non sarà visibile una serie completamente compattata di dati dei file, nella zona anteriore del disco. Si noti inoltre l'ampia sezione di dati verdi nelle Figure 1 e 2. Si tratta del file di paging di Windows, che verrà descritto fra breve. Se nel sistema Windows in uso è abilitata la sospensione, il file di paging avrà un aspetto analogo in una deframmentazione.

Una deframmentazione regolare è essenziale
Come nel caso della pulizia dei denti con il filo interdentale, è determinante ricordarsi di procedere alla deframmentazione con periodicità. Diventa anche più importante eseguire la deframmentazione frequentemente nei sistemi a utilizzo intensivo come i server, poiché se si attende, il processo potrebbe richiedere troppo tempo e lasciare il server non disponibile o impossibilitato a rispondere (in quanto può essere necessario molto tempo e certe fasi, inoltre, potrebbero imporre un carico di elaborazione elevato sulla CPU).
Persino le migliori utilità di deframmentazione in linea non sono in grado di deframmentare tutto. Ad esempio, non è sempre possibile deframmentare i file aperti o bloccati (ad esempio il file di paging o quelli del Registro di sistema) ed è necessario aggirare il file di sospensione, se esistente (che presenta dimensioni equivalenti a quelle della RAM in uso nel sistema). Per sapere come ottimizzare i file bloccati, vedere la sezione successiva sui trucchi di deframmentazione.
È sicuramente importante distinguere i miti dai fatti associati alla deframmentazione. La Figura 4 e la Figura 5 elencano alcuni argomenti comuni nelle discussioni sulla deframmentazione e spiegano le possibilità concrete che si verifichino tali problemi.
Figure 5 Miti sulla deframmentazione (Close Figure 5)

Mito | Probabilità
I sistemi si arresteranno. | Improbabile: l'arresto del sistema normalmente avviene a causa di problemi hardware o dei driver (danneggiamento della memoria, problemi di surriscaldamento che provocano il riavvio, guasto del disco dovuto ad abuso termico).
Le applicazioni si arresteranno. | Improbabile: come nel caso di un intero sistema, un'applicazione progettata correttamente non dovrebbe arrestarsi per effetto della frammentazione; pertanto, a meno che non si stabilisca con certezza che la frammentazione è la causa del malfunzionamento, si dovrebbero evitare supposizioni in tal senso.
Il Registro di sistema verrà danneggiato. | Improbabile (vedere sopra): la frammentazione non causa o conduce al danneggiamento del Registro di sistema.
La deframmentazione, una volta completata, dovrebbe corrispondere a una barra uniforme in qualsiasi rappresentazione visiva del disco. | Improbabile: è preferibile non raggruppare troppo tutti i file nel sistema, a meno che non si stia pianificando specificamente di creare un'immagine del sistema con un apposito strumento, basato sui settori, che non esclude lo spazio libero o riduce o divide le partizioni. È necessario spostare i file nella zona anteriore del disco; in caso contrario, un consolidamento del file aggressivo crea soltanto un'ulteriore frammentazione.
Figure 4 Comuni preoccupazioni sulla deframmentazione (Close Figure 4)

Preoccupazione | Probabilità
Le prestazioni del sistema risultano compromesse. | Elevata: dipende specificamente dall'uso del sistema.
Potrebbe diventare difficile o impossibile ripristinare i file eliminati involontariamente. | Elevata: la maggior parte degli strumenti di ripristino dipende dall'euristica (per stabilire il tipo di dati) e dalla prossimità dei cluster di file. I file dispersi rendono le operazioni di ripristino più complesse o impossibili.
Deframmentare il sistema sarà costoso. | Media: esiste una correlazione diretta fra quanto il sistema viene utilizzato e quanto cambiano i file nel sistema, nel tempo. Se gli utenti apportano numerose modifiche ai file ma li salvano solo nelle condivisioni del server, ad esempio, non si verifica una notevole degradazione nel tempo.
Si vericheranno guasti del disco. | Bassa: non realmente probabile. Di nuovo, la probabilità aumenta in caso di abuso del sistema (se lo si lascia acceso con i dischi sempre alimentati e vengono modificati o eliminati file di continuo). Tuttavia, con l'hardware attuale, ciò non dovrebbe accadere se ci si limita a modificare i file.

Deframmentazione come parte dell'infrastruttura
È opportuno considerare seriamente l'esecuzione di un'utilità di deframmentazione a intervalli regolari su tutti i sistemi utilizzati. È possibile scegliere se ricorrere all'utilità di deframmentazione integrata in Windows oppure cercare opzioni di terze parti. Il criterio di scelta è fondamentalmente l'entità del lavoro preparatorio che si è disposti a sostenere. In Windows XP e nelle versioni successive è possibile semplicemente aggiungere defrag.exe come attività pianificata. Per ulteriori informazioni sulla procedura, vedere l'articolo della Knowledge Base all'indirizzo support.microsoft.com/kb/555098. Si noti che la deframmentazione dei computer portatili implica alcune considerazioni particolari. Ad esempio, si supponga di voler deframmentare il sistema di un utente mentre è acceso, preferibilmente tramite l'alimentazione CA, ma senza impegnare cicli del disco o della CPU quando un utente mobile cerca di lavorare. Purtroppo, tuttavia, quando un utente mobile non lavora, è probabile che il sistema sia scollegato dall'alimentazione CA e si trovi in modalità stand-by o sospensione (ovvero sia spento, dal punto di vista del risparmio energia e delle attività pianificate). A Winternals (come probabilmente ovunque), è stato dedicato molto tempo al tentativo di progettare lo scenario ideale per gli utenti mobili. Windows Vista, una soluzione che presenta un'utilità di deframmentazione integrata, ricorre alle attività pianificate ed è molto più attenta al consumo delle versioni precedenti, sembra una scelta più che soddisfacente. In caso contrario, potrebbe essere necessaria una soluzione di terze parti concepita per i sistemi mobili. Alcuni di questi prodotti avviano effettivamente un'attività di deframmentazione, informano gli utenti sul fatto che è stata eseguita, quando (e con quale frequenza) e quanto tempo ha richiesto.
Oltre agli scenari mobili, può essere importante considerare la frammentazione del file system. Di solito questo aspetto non richiede attenzione nei sistemi desktop o mobili, ma con i server, Microsoft Exchange, SQL ServerTM o altri archivi dati potrebbe essere necessario procedere alla deframmentazione. In tali casi si dovrà decidere se effettuarla prima o dopo aver deframmentato il file system.
Se si ricorre a un'utilità di deframmentazione di terze parti, è consigliabile assicurarsi che venga utilizzata l'API di deframmentazione di Windows. A partire da Windows NT 4.0, nel sistema operativo è inclusa un'API di deframmentazione, al fine di prevenire la perdita improvvisa dei dati. Ad esempio, se durante il trasferimento di un file il computer si blocca per un'interruzione di alimentazione, è essenziale evitare uno spostamento dei frammenti incompleto, che potrebbe causare la perdita di dati e persino rendere impossibile l'avvio del sistema.
Infine, se si utilizza una tecnologia di elaborazione virtuale, è opportuno considerare come gestire anche la deframmentazione dei dischi virtuali. Questi ultimi sono soggetti alla frammentazione proprio come i dischi fisici, anzi in molti casi anche in misura maggiore, a causa dei vincoli dimensionali. Inoltre, se la soluzione di virtualizzazione in uso consente di ridurre dischi o partizioni, per liberare spazio può essere necessario eseguire una deframmentazione preliminare (o, come minimo, limitare il tempo richiesto da un'operazione di riduzione).

Strumenti aggiuntivi
A questo punto, è evidente che la deframmentazione è una funzione utile e importante. Anche se non si ricorre a un'utilità di terze parti per la deframmentazione vera e propria, può essere opportuno considerare uno strumento di Mark Russinovich denominato PageDefrag, disponibile presso il sito degli strumenti Sysinternals di Microsoft (vedere microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx). Come si è detto in precedenza, non è possibile deframmentare il file di paging di Windows mentre il sistema operativo è in linea. In realtà, ciò riguarda anche i file del Registro di sistema di Windows e i registri eventi. PageDefrag consente di deframmentare questi file prima che Windows abbia completato l'avvio e li abbia bloccati, grazie a un piccolo driver. Per utilizzarlo, è sufficiente eseguire PageDefrag e impostarlo per l'esecuzione al riavvio successivo o ad ogni riavvio. Quando il sistema si riavvia (nel punto del processo di avvio in cui in precedenza si potrebbe aver notato l'esecuzione di una verifica del disco), i file specificati nell'elenco vengono deframmentati (vedere la Figura 6).
Figura 6 File da deframmentare in PageDefrag
Figura 6 File da deframmentare in PageDefrag
Quando PageDefrag ha completato l'operazione, il processo di avvio viene concluso normalmente dal sistema. Se si desiderano ulteriori informazioni su PageDefrag, Lance Whitney ne ha parlato nell'installazione di settembre di Utilità in primo piano (vedere technetmagazine.com/issues/2007/09/UtilitySpotlight). Si noti che PageDefrag è supportato in Windows NT 4.0, Windows 2000, Windows XP e Windows Server 2003, ma attualmente non in Windows Vista.
Oltre a PageDefrag, è disponibile un altro strumento di Sysinternals, denominato Contig, che consente di deframmentare manualmente un file specifico (vedere microsoft.com/technet/sysinternals/FileAndDisk/Contig.mspx). Contig può essere utile se non è stato possibile deframmentare un file specifico mediante una normale attività di deframmentazione oppure se un file è diventato frammentato in un momento successivo (ma la parte rimanente del volume non è altrettanto frammentata).
Inoltre Contig è in grado di deframmentare un'intera directory o varie sottodirectory, se si utilizzano caratteri jolly. Il codice seguente permette di deframmentare tutti i file nella directory di Windows, indipendentemente dalla loro posizione.
Contig –s c:\Windows\*.*
Applicando l'opzione -v la procedura viene riportata in modo dettagliato, con l'opzione -q l'esecuzione si mantiene sullo sfondo.

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


 Taccuino: Il dentice di condotta
Taccuino
Il dentice di condotta
Betsy Aoki

A volte la soluzione potrebbe non essere un server più potente o una base di utenti più educata, che si trattenga dal chiedere assistenza proprio quando si sta per uscire dall'ufficio in anticipo per il week-end. Talvolta il problema non è gestire il codice; basterebbe avere un grande pesce.
Circa un anno fa, lavoravo alla creazione di report sugli abusi per il sito Live QnA (qna.live.com). Ci occupavamo di cancellare il materiale indesiderato e monitorare il sito contro gli attacchi fini a se stessi e il cattivo comportamento degli utenti. Utilizzavamo strumenti interni. Facevamo riferimento a criteri esterni. Abbiamo dovuto combattere contro un paio di pazzoidi che hanno tentato di sabotare le domande utilizzando contenuto inappropriato.
Nel frattempo, ero sempre più impaziente. Dopotutto, la mia missione era salvaguardare la salute della community del sito. Ero stata la principale artefice del codice di condotta che aveva definito il tono del sito. Avevo l'incarico di sorvegliare gli accessi e mi ripromettevo che tutti si sarebbero comportati BENE.
Purtroppo la realtà era ben diversa. Le persone sono tutte uguali, capaci della peggiore perfidia e di bontà estrema e ciò che desideravo non teneva conto dell'effettiva interazione fra gli utenti.
Ma un sabato, seduta in cucina, pensavo al codice di condotta che stavo difendendo. Mentre scarabocchiavo con la penna, mi ha colpito all'improvviso un'illuminazione: e se non si fosse trattato di un codice di condotta, ma di un "dentice" di condotta? In tal caso, come si sarebbe presentato e come avrebbe agito il pesce? Beh, sono cresciuta in New England, mangiando dentice. Dentice bianco, squamoso e spinoso. Volevo poter rimproverare e persuadere i membri di QnA con il tono realistico e sarcastico di un dentice. Invece della pressione punitiva del pulsante CANC, che stavo utilizzando troppo ultimamente, volevo rispondere con arguzia, facendo ridere gli utenti persino quando promettevano di non oltrepassare più il limite. Così è nato Norbert, il "dentice di condotta". Ho immaginato di mettergli una pipa in bocca, ma poi ho concluso che una cravatta a farfalla fosse sufficiente.
Il dentice di condotta
Il dentice di condotta
Ho caricato il mio disegno del pesce su un nuovo LiveID, gli ho assegnato un nome utente QnA e Norbert, il dentice di condotta di QnA era pronto per intervenire. Dietro Norbert non c'ero sempre io, comunque. A volte subentrava un altro membro del team e, assunto l'aspetto di Norbert, rimproverava gli utenti maleducati. Chi è il dentice di condotta? Vedere go.microsoft.com/fwlink/?LinkId=99044. Il dentice di condotta ferisce i sentimenti delle persone? Vedere go.microsoft.com/fwlink/?LinkId=99045.
I membri della community hanno accettato Norbert con la stessa naturalezza con cui un pesce vive nell'acqua. Hanno scherzato con lui, lo hanno convocato, si sono innervositi nei suoi confronti. Norbert ha educato i nuovi arrivati, ha rimproverato gli utenti che credevamo potessero essere condotti dall'oscurità alla luce e ha offerto un modo spensierato di guardare alle regole, ben diverso dal limitarsi a leggere una pagina Web piena di complesse frasi pseudo-legali.
Le regole, che siano politiche aziendali, legge tribale o ordine gerarchico in un campo da gioco, dipendono tutte dalla buona volontà delle persone sottoposte agli effetti della loro applicazione. Come i tecnici IT o gli sviluppatori del sito Web della comunità, è possibile creare strumenti che facilitano l'applicazione delle regole, ma talvolta lo strumento ideale nasce dalla personalità individuale o dal senso di umanità collettivo della tribù. Invece dell'ingegneria tecnica, un tocco rifinito di social engineering può dimostrarsi particolarmente efficace. O forse, nel nostro caso, un tocco, una rifinitura e un pesce.

Betsy Aoki è un Community Program Manager per Microsoft nel team Xbox. Le sue leggere nevrosi vengono avidamente espresse nei suoi messaggi di posta elettronica, nei post sui blog e, si spera, sul framework XNA.


 Windows Confidential: Il paradosso del file system
Windows Confidential
Il paradosso del file system
Raymond Chen

Se si esamina il contenuto del disco rigido, probabilmente si noterà che un certo numero di file del sistema operativo si trova nella directory principale dell'unità di avvio. A uno sguardo ravvicinato, si potrebbe notare un tema: boot.ini, NTLDR e NTDETECT.COM sono file di avvio critici e hiberfil.sys è il file di sospensione. Tutti questi file sono coinvolti nelle prime fasi cruciali di avvio del sistema operativo oppure, nel caso di hiberfil.sys, nella riattivazione dalla sospensione e devono trovarsi nella directory principale dell'unità di avvio. Perché non è possibile spostarli altrove?
Adrian Oney, collega di Chen, ha spiegato: per leggere i file di avvio dal disco, è necessario il driver del file system. Ma quest'ultimo si trova sul disco, che non è leggibile se prima non viene caricato il driver del file system. Oh no, è un vicolo cieco!
Niente paura: la soluzione consiste nell'integrare un driver del file system in miniatura nei file di avvio critici. Questo driver in miniatura riesce appena a individuare i file nella directory principale e a caricarli in memoria. I file, a loro volta, possono iniziare ad avviare il sistema operativo, dopo di che subentra il vero driver del file system che cerca i file necessari in posizioni più appropriate, come le sottodirectory.
La sospensione segue un modello simile. Sospendere il sistema operativo significa eseguire il dump dell'intero contenuto della memoria nel file di sospensione. Il ripristino dalla sospensione consiste nel recuperare tale file nella memoria facendo finta che non sia successo niente. Di nuovo, è come chiedersi se sia nato prima l'uovo o la gallina: per caricare il file di sospensione è necessario il driver del file system, ma quest'ultimo è incluso nel file di sospensione. Se il file di sospensione viene conservato nella directory principale dell'unità di avvio, al suo posto è possibile utilizzare il driver del file system in miniatura.
Chi ha utilizzato versioni precedenti di MS-DOS® è ben consapevole di questo limite relativo alla posizione dei file di avvio del sistema operativo. Il vecchio comando SYS ha trasformato il tradizionale, noioso disco floppy in un magico supporto avviabile. Tuttavia, se tale comando veniva eseguito su un disco floppy già contenente dei dati, era probabile che la conversione non riuscisse, in quanto nelle prime versioni di MS-DOS i file di avvio dovevano occupare posizioni specifiche del fisco floppy, affinché il settore di avvio potesse individuarli. Con le versioni successive di MS-DOS questi requisiti sono diventati più flessibili, grazie ai miglioramenti apportati al caricatore di avvio. Comunque, anche con la versione migliorata, i file di sistema devono risiedere nella directory principale.
Un cliente ha chiesto: "Posso spostare il file di sospensione in una sottodirectory?" Dopotutto, che importanza ha la posizione del file? Gli ACL sul file rimangono invariati, indipendentemente dalla posizione del file. Ma per il cliente era importante che il file risiedesse in un'unità diversa da quella di avvio, nonostante fosse stato avvertito del fatto che ciò non era possibile. Non avendo capito effettivamente il motivo di questa restrizione, il cliente ha tentato un'esecuzione finale, pensando: "Beh, se posso spostarlo in una sottodirectory, posso anche creare una directory che funga da giunzione per il percorso dove desidero che risieda realmente il file di sospensione. Ecco fatto: sono riuscito a trasferire il file di sospensione!".
Naturalmente, il driver del file system in miniatura non riconosce i punti di montaggio, che implicano il dialogo con il servizio di gestione disco. Al momento dell'avvio del sistema, il computer non ha ancora caricato il sistema operativo, tantomeno un servizio elaborato avanzato che sa come mappare le lettere di unità in riferimento ai percorsi ARC. Inoltre, se in qualche modo si riuscisse ad avviare il servizio, sarebbe comunque necessario individuare i driver di periferica per le altre unità disco e caricare i driver del file system corrispondenti.
È solo una questione di tempo, prima che qualcuno chieda come posizionare il file di sospensione su una giunzione DFS.

Raymond Chen, The Old New Thing, così come nel suo libro che porta lo stesso titolo (Addison-Wesley, 2007), vengono illustrate la storia di Windows e la programmazione in Win32. Il suo nome Web 2.0 è Raymond, o forse Chester.