 TechNet Magazine October 2007

TechNet Magazine October 2007

Informatica ecocompatibile: Riduzione dell'impatto ecologico dei datacenter

Le aziende di tutto il mondo hanno iniziato a pensare al modo per risparmiare energia e abbattere i costi ma, prima di iniziare a intraprendere delle azioni in questo senso, è opportuno documentarsi. Una possibile risorsa è questa introduzione alla pianificazione, progettazione e implementazione di un datacenter ecocompatibile nella propria organizzazione.

Dave Ohara Amministrazione di Windows: Guida alla replica di Active Directory

Active Directory fornisce una notevole flessibilità per il supporto di ambienti di grandi dimensioni o decentralizzati, ma garantire l'integrità dei dati può essere un compito alquanto impegnativo. La replica di Active Directory consente di definire il modo in cui gli aggiornamenti vengono comunicati nell'intero ambiente e il modo in cui vengono risolti gli eventuali conflitti. Ecco tutte le informazioni necessarie per affrontare questa sfida.

Laura E. Hunter System Center: Nuovi strumenti di gestione degli aggiornamenti software

System Center Configuration Manager 2007 è un meccanismo completamente nuovo per la gestione degli aggiornamenti, che garantisce una migliore conformità e applicazione su ciascun client. Di seguito si illustrerà come questo approccio consenta di aggiornare tutti i computer disponibili.

Steve Rachui Comunicazioni: Server Trasporto Edge di Microsoft Exchange

In che modo Microsoft garantisce la distribuzione di messaggi legittimi ai dipendenti continuando a proteggere l'ambiente di messaggistica da contenuti dannosi? Un metodo consiste nel distribuire i server Trasporto Edge di Exchange Server 2007 e Forefront Security per Exchange Server. Scopri in che modo queste tecnologie possono proteggere la tua organizzazione.

Kay Unkroth SQL Server: Ottimizzazione delle prestazioni della CPU in SQL Server

La chiave per un "sano" utilizzo della CPU sul server di database consiste nel creare tutte le condizioni necessarie perché la CPU possa elaborare esclusivamente i processi specificati anziché sprecare cicli su codice scritto in modo approssimativo o hardware lento. Di seguito sono riportati alcuni suggerimenti per sfruttare al massimo le potenzialità di SQL Server e dell'hardware in uso.

Zach Nichter Dal redattore: Il meglio deve ancora venire

Joshua Hoffman Casella degli strumenti: Nuovi prodotti per professionisti IT

Greg Steen SQL: domande e risposte: Trigger di accesso, deframmentazione dei file di dati e altro ancora

Edited by Nancy Michell Utilità in primo piano: Virtual Machine Remote Control Plus

Matthijs ten Seldam L'azienda IT: Calcolo del valore dell'infrastruttura IT nell'amministrazione pubblica

Acer Maamoun The Cable Guy: Authenticated Internet Protocol

Joseph Davies Windows PowerShell: Lavorare senza script

Don Jones Hey, Scripting Guy!: La tecnologia Silverlight

The Microsoft Scripting Guys Controllo della protezione: BitLocker e le complessità dei rapporti di fiducia

Justin Troutman Desktop file: Guida per utenti esperti su WIM e ImageX

Wes Miller Taccuino: Riciclaggio dei computer

Jim Lynch Windows Confidential: Quando arriva il Dr. Watson

Raymond Chen


 Informatica ecocompatibile: Riduzione dell'impatto ecologico dei datacenter
Informatica ecocompatibile Dave Ohara

Riduzione dell'impatto ecologico dei datacenter
Panoramica:
  • Sistemi per il controllo dei consumi energetici
  • I tratti essenziali di un datacenter ecocompatibile
  • Gli effetti della H.R. 5646
  • Procedure consigliate per avviare un progetto di riduzione dell'impatto ecologico

L'ecologia è un argomento molto sentito in questi giorni che inizia a sortire degli effetti sul modo in cui si pensa ai datacenter. Aziende di tutto il mondo annunciano nuovi modi per risparmiare energia e ridurre
i costi acquistando nuovi hardware e servizi. È tuttavia necessario prendere in considerazione alcuni aspetti del problema prima di intraprendere delle azioni per controllare i costi dell'energia. In passato l'elettricità è stata trattata come un costo operativo, allo stesso modo dello spazio occupato. Ma con l'aumento dei costi dell'energia e l'aggravarsi dei problemi di affidabilità, approvvigionamento e capacità, ora è necessario adottare strategie specifiche per l'elettricità.
I progetti per l'ottimizzazione delle prestazioni e la riduzione dei costi fanno parte delle procedure consigliate quotidiane in quasi tutti i settori. Perché, quindi, non trattare i costi per l'energia allo stesso modo?
I professionisti dell'IT prendono decisioni sulla configurazione e installazione di server, sulle specifiche dei dispositivi acquistati dalle organizzazioni di appartenenza e sui requisiti per la creazione e l'aggiornamento dei datacenter. Forniscono addirittura indicazioni nella fase di progettazione dello sviluppo delle applicazioni. Progetti di questo tipo rappresentano, ovviamente, opportunità irripetibili per incidere sull'efficienza energetica di qualsiasi datacenter.
Il primo passo di una qualsivoglia strategia consiste nell'acquisire i dati del consumo energetico attuale. È necessario sapere dove viene utilizzata l'energia e da quale specifica apparecchiatura, oltre a individuare gli utilizzi efficienti e gli sprechi all'interno del datacenter. Purtroppo, sono rari i casi in cui sia già stato implementato un sistema di misurazione del consumo di energia in grado di fornire dati disaggregati in cui leggere i risultati delle azioni intraprese. Nella maggior parte delle organizzazioni le informazioni disponibili sono limitate a una fattura mensile o bimestrale che riepiloga i consumi globali dell'organizzazione in un unico totale. L'incentivo al risparmio energetico in questo caso è minimo, poiché i responsabili e gli addetti non possono mai apprezzare l'impatto delle proprie decisioni e non è possibile provare in alcun modo che le modifiche apportate hanno consentito di risparmiare energia.
Uno dei primi problemi da affrontare è la disponibilità di supporto esecutivo nella realizzazione di un'iniziativa di datacenter ecocompatibile. Ai fini dell'articolo, si presupporrà che la risposta a questa domanda sia "non ancora". Il supporto esecutivo richiede un impegno serio, che garantisca risorse e budget per l'iniziativa. Se da un lato si parla molto di datacenter ecocompatibili, dall'altro spesso manca un supporto serio a livello esecutivo. Chi ha già ottenuto un supporto esecutivo, ha di certo già realizzato un progetto di datacenter ecocompatibile.
Tuttavia, anche in assenza del supporto necessario, è possibile intraprendere una grande varietà di iniziative per affermare l'idea di un datacenter ecocompatibile. Come si possono quindi individuare delle azioni efficaci da intraprendere per conseguire questo scopo? Per fortuna, l'efficienza energetica non è un concetto nuovo e i professionisti IT hanno molto da imparare dagli altri settori.

Una valutazione oggettiva dei consumi energetici
Il problema tipico da risolvere quando si scrive su questo argomento consiste nell'interpretare in modo corretto l'ampia gamma dei dati forniti da fonti diverse. Alcuni studi suggeriscono che nei datacenter si utilizza tra 1,2 e 2,0% dell'elettricità consumata negli Stati Uniti. Secondo alcune stime, se si considerano i datacenter come un settore di attività a se stante, negli Stati Uniti il settore dei datacenter si colloca a ridosso delle prime 5 industrie del paese per consumi energetici. Inoltre, nel datacenter di un'impresa degli Stati Uniti l'elettricità può rappresentare una quota compresa tra 15 e 20% dei costi operativi.
Uno studio dei Lawrence Berkeley National Laboratories, svolto su incarico dell'American Council for an Energy-Efficient Economy, ha evidenziato che i datacenter possono far registrare consumi energetici fino a 40 volte maggiori rispetto ad altri edifici adibiti a uffici convenzionali. Nello studio si analizzano nel dettaglio le possibili azioni da intraprendere per migliorare l'efficienza energetica dal punto di vista degli edifici (vedere eetd.lbl.gov/emills/PUBS/PDF/ACEEE-datacenters.pdf). Una buona base di partenza è determinare fino a che punto nel proprio datacenter si applicano le procedure consigliate proposte in questo studio.
Esistono, senza dubbio, molti punti di vista, molti studi e molti dati relativi al consumo di energia. Un tema che resta costante, tuttavia, è che gli sprechi pesano molto sulle bollette energetiche. Basta pensare a quanti server sono stati acquistati con l'intento di ottenere il massimo delle prestazioni per l'investimento sopportato. Questo significa che si è sempre acquistato il massimo consentito dal budget in termini di potenza di calcolo, memoria, archiviazione e gruppi di continuità ridondanti. Negli ultimi 3 - 5 anni molti di quei server hanno continuato a funzionare al 10 - 15% delle potenzialità. Molti si concentrano sui processori, ma anche gli altri componenti assumono un ruolo importante in questo caso: memoria, dischi e interfacce di rete vengono tutti alimentati e, considerati nel complesso, consumano più del processore.
La capacità in eccesso dell'hardware, dai processori ai gruppi di continuità ridondanti, può produrre uno spreco significativo. Data l'avversione culturale al rischio coltivata nella maggior parte dei reparti IT, l'eccesso di capacità è la norma. La decisione che offre maggiori garanzie consiste nel mettere a disposizione del datacenter capacità hardware in eccesso, anche quando non è la migliore opzione finanziaria possibile. Sebbene sia un fattore chiave, l'energia viene in genere trascurata durante il calcolo dei costi del ciclo di vita. Purtroppo, non sono previsti incentivi per l'acquisto di soluzioni efficienti, come non esistono benefici in termini di costo per i decisori dopo la messa in opera.
Esiste tuttavia un valore medio da raggiungere. I responsabili tendono a vedere le cose in altro modo quando capiscono quanto sia poco sfruttata la capacità dell'hardware dei datacenter e a considerare il consolidamento dei server come un modo per ridurre i costi. È molto più facile acquistare fin da subito server dimensionati in modo corretto piuttosto che tentare di consolidare in un secondo momento dei server già operativi.
La maggiore maturità del settore IT impone di considerare prioritaria l'ottimizzazione con la riduzione dei costi. Il consumo di energia è un indicatore che i responsabili possono utilizzare per valutare l'efficacia delle decisioni prese sul ciclo di vita dell'hardware informatico. AMD, Intel e gli OEM di server e componenti fanno tutti riferimento a valori di "prestazioni per watt" delle piattaforme proposte. È possibile utilizzare i valori di prestazioni per watt per calcolare un costo operativo utilizzando la formula inversa: watt per unità di prestazione. Considerata l'ampia gamma di persone coinvolte nello sviluppo di soluzioni IT (gestione delle sedi, sviluppo di applicazioni, architetti, operazioni e business unit), i valori delle prestazioni per watt rispondono alla domanda "cosa si ottiene in cambio" e consentono di mettere a confronto le soluzioni in termini di efficienza energetica.
Perché è pratica comune ignorare i costi energetici e trascurare le decisioni che influiscono su costi operativi e di gestione delle sedi? Quanti datacenter esistono che hanno già raggiunto la capacità massima a causa delle limitazioni in termini di alimentazione e raffreddamento? Un tempo il problema principale era poter disporre di spazio fisico sufficiente per il datacenter. Oggi, invece, il problema è la disponibilità di capacità sufficiente ad alimentare e raffreddare tutti i dispositivi e quando tale capacità diventerà insufficiente.

Importanza dei sistemi di controllo dei consumi energetici
Non è facile misurare con precisione il consumo di energia. Come già anticipato, la maggior parte delle aziende tende ad aggregare tutti i dati relativi ai costi dell'energia in un totale complessivo piuttosto che a suddividere i consumi tra le diverse unità. Questo modo di trattare il consumo di energia come un costo operativo induce la percezione che tali costi siano indipendenti dalla volontà e dal controllo della business unit. Ovviamente si tratta di una percezione errata.
Un datacenter può consumare quantità di energia per metro quadrato superiori anche di decine di volte rispetto a un ufficio convenzionale, quindi nei datacenter anche recuperi di efficienza di minore entità possono condurre a risparmi notevoli. Non sorprende che la ragione primaria a spingere i datacenter a implementare programmi di risparmio energetico sia la riduzione dei costi. In genere viene implementato proprio il metodo dal costo più basso per la fatturazione del consumo energetico che prevede l'aggregazione dei costi dell'intera sede su base mensile o bimestrale. I costi vengono quindi allocati ai gruppi in base allo spazio che occupano e/o alla connessione. Un approccio molto lontano dal livello di dettaglio necessario per valutare quanto costa, in termini di consumi energetici, far funzionare un singolo dispositivo del datacenter.
Sono rare le organizzazioni che hanno adottato una soluzione di misurazione che consenta di valutare il consumo reale dei singoli dispositivi del datacenter. Ciò dipende in larga misura dal fatto che l'installazione di un sistema di misurazione dei consumi energetici richiede un investimento significativo nell'immediato. Tuttavia, un investimento di questo tipo può produrre risparmi importanti in tempi ragionevoli.
Un sistema di monitoraggio del consumo non è certo sufficiente. È necessario pianificare l'utilizzo che si intende fare dei dati raccolti, per gestire nel migliore dei modi il consumo di energia e ottenere in definitiva un ritorno sull'investimento sostenuto. Si consideri il caso dell'azienda canadese Abitibi Consolidated, il maggior produttore del mondo di giornali e carta. Nel 2001, quando il mercato della corrente elettrica in Ontario stava per essere liberalizzato, l'Abitibi Consolidated era esposta alle fluttuazioni del mercato in termini di prezzi e disponibilità. Per ottimizzare gli acquisti di energia, l'azienda ha implementato un sistema di controllo e misurazione. I costi sostenuti per il nuovo sistema sono stati recuperati nel giro di pochi mesi, grazie a un risparmio pari al 1% realizzato con il semplice acquisto efficiente dell'energia.
Quanta energia si deve risparmiare per giustificare l'investimento in un sistema di monitoraggio dei consumi di un datacenter? Bill Laing, General Manager per lo sviluppo di Windows Server® 2008 in Microsoft, ha affermato in una recente intervista che la nuova versione di Windows Server con le impostazioni di risparmio energetico predefinite attivate consente di ridurre il consumo energetico fino al 20%, un risparmio notevole. Nella Figura 1 sono illustrate alcune delle Opzioni risparmio energia disponibili nella versione beta 3 di Windows Server 2008. È opportuno sottolineare, tuttavia, che i risparmi non possono essere calcolati come riduzione diretta del costo dell'energia utilizzata. I fattori da considerare per il calcolo del risparmio sono molti, come i costi per la creazione di un nuovo datacenter e il numero di altri sistemi che attualmente supportano configurazioni meno efficienti.
Figura 1 Opzioni risparmio energia della versione beta 3 di Windows Server 2008
Figura 1 Opzioni risparmio energia della versione beta 3 di Windows Server 2008
Già adesso è possibile scegliere l'opzione Energia processore e prestazioni bilanciate server in Windows Server 2003 SP1. Senza l'adozione un sistema di misurazione, non sarà possibile quantificare i risparmi o qualunque altro fattore coinvolto a supporto di questa modifica.
È anche importante sottolineare che, per molti datacenter, il consumo di energia fluttua in genere solo di un 4% durante qualunque periodo di 24 ore, a dimostrare che il consumo di energia non dipende dai carichi di lavoro. Le recenti innovazioni dei produttori di hardware consentono di modificare questi risultati per i nuovi dispositivi, con consumi ridotti nei momenti di minore carico.

Definizione di datacenter ecocompatibile
Si potrebbe continuare per intere pagine a elencare i criteri o i tratti distintivi di un datacenter ecocompatibile. Lo spazio dedicato a questo articolo impedisce di esaminarne tutti gli aspetti, ma è opportuno evidenziare alcune caratteristiche principali di cui tenere conto quando si intende implementare un datacenter ecocompatibile. L'elenco può essere utilizzato anche nella fase di pianificazione, per determinare il posizionamento corrente del proprio datacenter:
  1. Per ripartire l'uso di energia al livello dei singoli componenti (come un server 2U, un server 4U, uno switch, una SAN e un gruppo di continuità) e individuare le business unit a cui addebitare l'energia consumata da tali componenti, si devono utilizzare delle misurazioni.
  2. Per determinare i picchi e i punti più bassi della richiesta di energia, l'uso di energia deve essere continuamente monitorato.
  3. Le capacità di energia devono essere monitorate dal livello complessivo dell'intero datacenter fino ai singoli circuiti, per accertarsi che tutti i circuiti siano entro limiti accettabili.
  4. Il piano di risparmio energetico deve essere documentato e prevedere delle ricompense.
  5. Il piano di risparmio energetico deve essere riesaminato a scadenze regolari e devono essere intraprese azioni correttive per risolvere gli eventuali problemi.
  6. Per modellare i comportamenti, incoraggiando il risparmio di energia fra business unit indipendenti, è necessario determinare come vengono addebitati i costi alle business unit. Questo punto deve essere gestito a livello dirigenziale.
  7. È necessario attivare le funzionalità di rallentamento della CPU sui server e in un laboratorio delle prestazioni deve essere misurata la gamma dei consumi energetici sotto varie condizioni di carico.
  8. È necessario individuare i punti caldi e di raffreddamento eccessivo definendo i profili termici del datacenter.
  9. Tra i criteri di valutazione delle prestazioni dell'IT deve essere inclusa l'efficienza nei consumi energetici.
  10. Le singole organizzazioni devono poter accedere ai propri dati per reagire in modo immediato e appropriato (California ISO giunge a rendere disponibili i dati in tempo reale al pubblico sul proprio sito Web, come illustrato nella Figura 2).
Figura 2 Il sito Web di California ISO fornisce delle snapshot con la domanda corrente e il livello di risparmio richiesto ai clienti
Figura 2 Il sito Web di California ISO fornisce delle snapshot con la domanda corrente e il livello di risparmio richiesto ai clienti
Maggiore è il numero di queste misure già adottate, minore è la distanza che separa dalla costituzione di un sistema di controllo avanzato del consumo di energia. È incluso uno schema (vedere la Figura 3) con otto domande che è possibile porsi per valutare il livello raggiunto dal proprio datacenter: base, medio o avanzato.
Figure 3 Quanto è ecocompatibile il datacenter? (Close Figure 3)

Livello | Procedure adottate
Base | Analisi mensile della bolletta
Controllo periodico dei dispositivi elettrici per la pianificazione della capacità
Medio | Automazione delle misurazioni e della produzione di report su carico e consumo dei circuiti elettrici
Analisi dell'efficienza energetica dei dispositivi al momento dell'acquisto
Avanzato | Monitoraggio del consumo di energia per rack, dispositivo e circuito
Analisi dei dati cronologici di monitoraggi e report
Utilizzo di report in tempo reale sui consumi di energia per i reparti, per diffondere informazioni sugli impatti di modifiche e nuovi sistemi adottati
Utilizzo dei dati per la negoziazione di tariffe più vantaggiose con la società di fornitura elettrica

Sapere è potere
Un altro problema da affrontare è la standardizzazione all'interno dell'organizzazione. Per un cambiamento come quello descritto nell'articolo (con nuovi paradigmi per la misurazione del consumo di energia e la partecipazione delle business unit in ogni parte dell'organizzazione) è necessario l'allineamento tra i gruppi di più datacenter che interagiscono con un gruppo ancora più ampio di organizzazioni IT. Problemi organizzativi di queste proporzioni rappresentano i principali ostacoli sulla strada della realizzazione di un programma di risparmio energetico.
È importante incaricare una sola persona o un singolo team di definire e comprendere le caratteristiche del consumo energetico nei diversi datacenter. Questo centro di conoscenza (assente nella maggior parte delle aziende per quanto riguarda il consumo di energia) è essenziale. È inoltre importante che gli strumenti utilizzati raccolgano i dati dalle diverse sedi in modo uniforme e producano risultati coerenti per tutte le business unit (nella Figura 4 si illustra un pannello di esempio per i dati da raccogliere).
Figura 4 Pannello di esempio per il monitoraggio dei dati globali (fornito da OSIsoft)
Figura 4 Pannello di esempio per il monitoraggio dei dati globali (fornito da OSIsoft)
Senza gli strumenti giusti, non si riuscirà a ottenere informazioni sull'efficacia della azioni intraprese a livello centrale e le singole business unit non potranno apprezzare i risultati dei propri sforzi. Per incidere davvero sui comportamenti delle persone, è necessario fornire agli utenti informazioni in tempo reale con le tendenze e i dati cronologici, in modo che si possano visualizzare i risultati delle proprie azioni. Non è possibile ricompensare in modo efficace i gruppi per il conseguimento di una maggiore efficienza energetica se ciascuna business unit utilizza per i propri risultati un sistema diverso, con una serie di strumenti diversa e unità di misura diverse.

La forza del sistema
Non è il caso di sentirsi soli sulla difficile strada dell'ecocompatibilità. Le aziende leader di altri mercati, da Boeing e Toyota agli enti pubblici come lo Stato della California, operano investimenti seri in operazioni e prodotti per un utilizzo più efficiente dell'energia.
Quanto al mondo dell'IT, nel 2006 il parlamento degli Stati Uniti ha emanato una norma (H.R. 5646, ora legge 109-431) con cui si richiede alla EPA (Environmental Protection Agency) di raccogliere dati sui costi energetici e sul consumo di elettricità dei server e dei datacenter e sui potenziali effetti del passaggio a sistemi più efficienti. Lo studio, eseguito dalla ENERGY STAR, un programma della EPA, ha prodotto una proiezione dell'aumento dei consumi a breve termine dei server e dei datacenter negli Stati Uniti, una valutazione dei costi e dei benefici potenziali ottenibili con i risparmi conseguenti all'adozione nei datacenter di sistemi più efficienti e una valutazione dei potenziali incentivi e programmi volontari per promuovere server e datacenter più efficienti sul piano dei consumi energetici. I risultati finali dello studio sono stati presentati al Congresso nell'agosto 2007. È possibile ottenere ulteriori informazioni sullo studio visitando il sito energystar.gov.
Sono inoltre stati sviluppati nuovi standard di costruzione per gli edifici ecocompatibili. Questi standard utilizzano criteri come funzionalità di misurazione orarie per i circuiti che dipendono da scopo e consumo di energia, adozione di strumenti di misurazione che comunichino i dati di consumo energetico a un sistema di gestione dei dati di misurazione e sistemi di gestione dei dati di misurazione con cui memorizzare i dati e produrre report per gli utenti in cui si illustri il consumo di energia calcolato per ora, giorno, mese e anno per ciascun parametro preso in considerazione. Molti di questi criteri sono obbligatori per la conformità dei sistemi quando si aderisce a dei programmi di risparmio di energia in cui è richiesto di provare che le modifiche apportate hanno prodotto risultati apprezzabili (ad esempio, i crediti di energia rinnovabile, i crediti di biossido di carbonio e i programmi di riduzione dei consumi).
Alcuni utenti hanno richiesto dei test per le specifiche, ma è difficile rappresentare l'intero spettro di utilizzi possibili. Sono in corso dei tentativi per la standardizzazione dei test, ma questi ultimi, come la maggior parte dei test delle prestazioni, possono essere utilizzati per ottimizzare i risultati "percepiti", che non rappresentano l'utilizzo effettivo. Si può prendere ad esempio la misurazione dei chilometri al litro. Ai fini delle valutazioni degli organi competenti, si stimano i chilometri che un automobilista tipico dovrebbe percorrere per ogni litro di carburante sotto condizioni standard di guida in città e in autostrada. Tuttavia, la maggior parte degli automobilisti e degli ambienti in cui si guida non sono tipici né standard e i fattori che influiscono sull'efficienza del carburante possono variare in modo considerevole. Lo stesso ragionamento può essere applicato ai risparmi di energia nei datacenter. I soli risultati validi per la propria organizzazione si ottengono misurando i risparmi di energia all'interno dell'organizzazione.

Definizione di risparmio
È necessario tenere conto di molti fattori quando si intende determinare il risparmio energetico. Si conoscono i costi che comporta l'aggiunta di ulteriore energia in una determinata area? Si è stabilita una strategia per minimizzare le limitazioni di energia erogata? È possibile risolvere il problema trasferendo i datacenter in un luogo in cui l'energia costa meno? È preferibile concentrarsi sul miglioramento dei sistemi attuali?
Per alcune aziende, il modo migliore per ridurre i costi può consistere nel trasferire i datacenter in aree in cui l'energia costa meno. La virtualizzazione dei server è un ulteriore approccio alla riduzione del consumo di energia. Infatti, alcune aziende che operano nel campo della fornitura energetica (PG&E, SoCal Edison e SDG&E, per citarne solo qualcuna) offrono incentivi finanziari ai clienti che adottano progetti di virtualizzazione dei server che comportino una riduzione dei dispositivi server fisici.
Ma è possibile operare in modo più semplice e meno drastico. Nella maggior parte dei reparti IT semplicemente si ignorano i consumi dei sistemi utilizzati e questo significa che esistono opportunità di risparmio energetico enormi. Una prima fase potrebbe consistere nell'analizzare il consumo di energia associato ai singoli dispositivi e apportare delle modifiche in relazione al singolo dispositivo. Tante piccole modifiche possono produrre risparmi sostanziali.
Come paragone, è possibile pensare a un'abitazione tipica il cui proprietario non ha idea di quanta energia consumi ciascun elettrodomestico utilizzato, limitandosi a pagare il totale della bolletta bimestrale. È possibile acquistare un dispositivo semplice e poco costoso, come un Kill A Watt, per misurare il consumo di energia dei singoli dispositivi. Quanto si spende per tenere acceso il forno a microonde anche quando non lo si utilizza? Quanta corrente si consuma quando si dimentica il caricabatterie del telefono inserito nella presa? Con questo stesso approccio, si possono aggiungere dei misuratori ai rack e raccogliere dati dai vari dispositivi. È possibile utilizzare degli strumenti di gestione per raccogliere i dati direttamente da alcuni server con trap SNMP per il consumo di energia.

Per iniziare
Nella Figura 5 è riportato uno schema con le procedure consigliate che è possibile applicare per avviare un progetto di risparmio energetico. È importante comprendere che in questa fase la scelta non è limitata tra i due estremi. Si può optare per un approccio più bilanciato, probabilmente anche più realistico. Avviare un'opera di selezione, per identificare i colleghi all'interno dell'azienda che mostrano maggior interesse alle tematiche del risparmio energetico. Iniziare a misurare i consumi di alcuni dispositivi in una business unit, per garantire visibilità all'operazione. Può giovare all'adozione del piano il supporto che si ottiene quando si illustrano dei risultati concreti e quantificabili dell'investimento aziendale nell'ecocompatibilità.
Figure 5 Chiavi per l'adozione di un progetto di risparmio energetico (Close Figure 5)

Raccogliere manualmente i dati per la determinazione dello stato attuale dei sistemi utilizzati. Determinare i consumi di energia in base a dispositivi e applicazioni, quindi ripartire i costi.
Creare un sistema di feedback a circuito chiuso per misurare l'efficacia delle modifiche apportate.
Accertarsi che il monitoraggio dei consumi elettrici avvenga nei luoghi e al livello appropriati (per dispositivo, organizzazione IT, business unit, applicazione e così via).
Creare un fondo per i progetti di risparmio energetico per i finanziamenti necessari.
Individuare all'interno dell'organizzazione e coinvolgere le persone che possono collaborare a diffondere la cultura dell'efficienza energetica.
Chi sono le persone incaricate di rendere l'azienda più efficiente dal punto di vista energetico? Sono dirigenti di alto livello, quadri intermedi o persone che hanno semplicemente a cuore l'impatto che l'azienda ha sull'ambiente. In tutte le aziende è possibile trovare degli entusiasti. Una delle prime decisioni da prendere riguarda il possibile coinvolgimento delle persone selezionate in base a questo criterio.
In definitiva, qualunque sia la direzione scelta, la progettazione di un programma per la maggiore efficienza energetica del proprio datacenter richiede la collaborazione di tutti i gruppi dell'IT. Fino a poco tempo fa, l'approccio tipico alla pianificazione delle soluzioni IT non teneva in alcun conto i costi energetici durante la fase di progettazione, concentrando piuttosto l'attenzione sull'hardware e sul software da acquistare e sui costi di personale e dislocazione della soluzione. Quando i consumi energetici sono nascosti nei costi operativi delle soluzioni adottate per un datacenter, all'efficienza energetica viene attribuita una priorità molto bassa. L'esposizione dei consumi effettivi delle soluzioni è la fase fondamentale per avviare un cambiamento nei comportamenti dell'organizzazione.

Dave Ohara ha accumulato 26 anni di esperienza in ambito tecnologico, lavorando per aziende come Microsoft, Apple e Hewlett-Packard. In questi anni si è occupato di sviluppo del prodotto, marketing, divulgazione tecnologica, architettura delle infrastrutture, ingegnerizzazione dei processi, affidabilità degli apparati tecnologici e logistica della distribuzione. Ora Dave collabora con molte aziende implementando iniziative ecologiche
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 Amministrazione di Windows: Guida alla replica di Active Directory
Amministrazione di Windows Laura E. Hunter

Guida alla replica di Active Directory
Panoramica:
  • Transizione ad Active Directory
  • Gestione della coerenza
  • Gestione della risoluzione dei conflitti
  • Modifiche in Windows Server 2008

Prima dell'introduzione di Windows 2000 Server e Active Directory, molti ambienti aziendali si basavano su Windows NT per l'infrastruttura server e la gestione delle identità e degli
accessi. Dopo la sua implementazione, Windows NT® 4.0 rappresentava una soluzione solida nello spazio del sistema operativo di rete (NOS), ma presentava diversi limiti che ne rendevano difficoltosa la distribuzione in un'azienda di grandi dimensioni.
Per i principianti, Windows NT utilizzava uno spazio dei nomi piatto per memorizzare le risorse di rete, il che significava che non esisteva un metodo valido per separare le risorse in sottoinsiemi più piccoli o per configurare qualsiasi tipo di amministrazione granulare. Ad esempio, non era possibile configurare un contenitore di reparto per le risorse presenti nel reparto marketing o configurare un amministratore locale che disponesse dei diritti per reimpostare le password solo per gli utenti di quel settore. In questo modo, il concetto di sicurezza di Windows NT poteva essere riassunto nella frase "tutto o niente". Se si intendeva delegare le attività amministrative a un responsabile del supporto desktop, si era costretti a concedere più autorizzazioni di quelle concesse altrimenti.
Inoltre, Windows NT memorizzava tutte le informazioni in un database Gestione account di protezione (SAM) che non era in grado di supportare più di 40 MB. Se il database SAM superava il limite massimo consigliato (ciò si verificava con circa 25.000-40.000 oggetti, a seconda della configurazione), era necessario suddividere l'ambiente in più domini separati, il che complicava sia la gestione della rete sia l'accesso alle risorse da parte degli utenti. Ogni dominio NT conteneva un solo controller di dominio primario (PDC) che conteneva l'unica copia in lettura/scrittura del database SAM. Nonostante fosse possibile distribuire uno o più controller di dominio di backup (BDC) per fornire la tolleranza di errore, tali controller erano di sola lettura e non potevano eseguire alcun aggiornamento che richiedesse un'operazione di scrittura, come la modifica della password dell'utente.
Infine, Windows NT si basava sulla risoluzione dei nomi NetBIOS, che era basata su broadcast e che spesso generava una grande quantità di traffico dato che gli utenti ricercavano risorse di rete, in particolare se tali ricerche venivano effettuate tramite un collegamento WAN lento o utilizzato di frequente.

La nascita di un nuovo modello
Nel 2000 Microsoft ha rilasciato Windows® 2000, che comprendeva una sostanziale revisione delle precedenti soluzioni del sistema operativo di rete (NOS). Il nuovo servizio NOS, Active Directory®, era molto diverso da Windows NT. Active Directory non era basato su uno spazio dei nomi piatto, ma creato sul modello X.500 standard, che ha prodotto una struttura organizzativa gerarchica. Attualmente è possibile organizzare le risorse in più unità organizzative all'interno di un singolo dominio e delegare la gestione di ciascuna unità a un livello basato sulle attività.
Un'altra innovazione importante di Windows NT era rappresentata dal nuovo modello di replica multimaster. Il singolo controller di dominio primario e i relativi PDC erano ormai obsoleti. In Active Directory, ciascun controller di dominio aveva la possibilità di scrivere nel database di Active Directory.
Tuttavia, nonostante ciò creasse maggiore flessibilità poiché supportava ambienti di grandi dimensioni e/o decentralizzati, generava anche nuove sfide per la gestione dell'integrità di Active Directory. Se John Smith e Jane Dow apportano una modifica allo stesso oggetto in uffici situati agli angoli opposti del paese, cosa accade se tali modifiche entrano in conflitto? Il modello di replica di Active Directory stabilisce il modo in cui gli aggiornamenti vengono comunicati a tutti i controller di dominio di un ambiente, nonché il modo in cui gestire i conflitti risultanti dalla capacità multimaster di apportare modifiche praticamente da qualsiasi luogo.

I meccanismi della replica di Active Directory
Ai fini di questi esempi, discuteremo solo della replica tra siti. Fondamentalmente, la replica tra siti è stata progettata per replicare rapidamente le modifiche ai controller di dominio all'interno dello stesso sito e viene eseguita utilizzando la notifica delle modifiche. Nel caso di replica tra siti DC1 informerà DC2 che dispone delle modifiche da replicare e DC2 richiamerà tali modifiche da DC1. Allo stesso modo, DC2 informerà DC1 quando dispone di alcune modifiche e DC1 richiamerà tali modifiche da DC2. Come si può notare, tutta la replica di Active Directory ha luogo nelle operazioni pull e non push.
Poiché Active Directory è in grado di garantire una scalabilità che consente di supportare centinaia di migliaia o persino di milioni di oggetti, è necessario suddividere il database di Active Directory in sezioni, definite contesti di denominazione. Ogni controller di dominio memorizza minimo tre contesti dei nomi nella copia locale del database di Active Directory.
Contesto dei nomi dello schema Questo contesto dei nomi viene replicato in tutti gli altri controller di dominio nell'insieme di strutture e contiene informazioni sullo schema di Active Directory, che a sua volta definisce diverse classi e attributi dell'oggetto in Active Directory.
Contesto dei nomi della configurazione Replicato anche in qualsiasi altro controller di dominio nell'insieme di strutture, questo contesto dei nomi contiene informazioni sulla configurazione a livello dell'insieme di strutture relative al layout fisico di Active Directory, nonché informazioni sugli identificatori di visualizzazione e sulle quote di Active Directory a livello dell'insieme di strutture.
Contesto dei nomi del dominio Questo contesto dei nomi viene replicato in tutti gli altri controller di dominio all'interno di un solo dominio di Active Directory. Si tratta del contesto dei nomi che contiene i dati di Active Directory utilizzati più di frequente: utenti, gruppi, computer correnti, nonché altri oggetti che si trovano all'interno di un determinato dominio di Active Directory.
Per ottimizzare al meglio il traffico di replica, i contesti dei nomi vengono replicati separatamente in modo che un contesto dei nomi che si modifica raramente, come il contesto dei nomi dello schema, non sottragga la larghezza di banda necessaria per il contesto dei nomi del dominio, che sembra cambiare più frequentemente.
Poiché è possibile apportate modifiche alla directory da qualsiasi controller di dominio di Active Directory, sono disponibili due operazioni di scrittura delle quali la replica di Active Directory deve tenere traccia. Un tipo è rappresentato dalle scritture di origine, ovvero quando una particolare modifica è stata apportata direttamente in un controller di dominio particolare. Ad esempio, se si effettua la connessione a DC1 e si modifica la password di un utente, tale modifica viene considerata una scrittura di origine su DC1. È necessario, inoltre, che Active Directory tenga traccia delle scritture replicate. Come è possibile immaginare, ciò significa che una particolare modifica è stata replicata da un altro controller di dominio. La modifica considerata come scrittura di origine in DC1 verrà considerata una scrittura replicata nel momento in cui tale modifica viene replicata in DC2, DC3 e in qualunque altro controller di dominio all'interno del dominio.
I controller di dominio di Active Directory gestiscono la trasmissione delle modifiche alla directory attraverso l'uso di metadati di replica. Ciò significa che, oltre a comunicare i dati reali che sono stati modificati da un controller di dominio in un altro (la carica di John Smith è stata modificata in "Direttore delle risorse umane"), Active Directory trasmette anche altre informazioni su tale modifica per consentire ai controller di dominio di gestire la replica nel modo più efficiente possibile, ad esempio il controller di dominio da cui ha avuto origine la modifica, l'ora in cui è avvenuta la modifica e altre informazioni essenziali.
Il primo elemento dei metadati della replica che verrà affrontato è il numero di sequenza di aggiornamento (USN, Update Sequence Number). Ogni controller di dominio gestisce un USN specifico per quel controller di dominio. Ogni volta che viene apportata una modifica ad Active Directory da quel controller di dominio, il numero di sequenza di aggiornamento subisce un incremento di 1. Pertanto, se un controller di dominio dispone di un USN pari a 1000 alle 11.00 e 1005 alle 11.30, è chiaro che sono state apportate 5 modifiche al database di Active Directory in quel controller di dominio. Conoscere esattamente queste modifiche non ha alcuna importanza per quanto concerne l'USN. È possibile che siano stati modificati, creati o eliminati 5 oggetti differenti o qualsiasi combinazione, l'USN del controller di dominio crescerà sempre di 5 punti. Inoltre, i numeri di sequenza di aggiornamento sono interni a un solo controller di dominio specifico e non hanno alcuna importanza se paragonati con altri controller di dominio. Un controller di dominio in un dominio potrebbe effettuare una modifica alle 11.30 che prevede l'assegnazione di un USN di 1051, mentre un secondo controller di dominio nello stesso dominio potrebbe apportare esattamente nello stesso momento una modifica che prevede l'assegnazione di un USN di 5084. Nonostante questi due controller di dominio abbiano chiaramente USN completamente differenti a causa di una modifica apportata quasi contemporaneamente, ciò non ha alcun rilievo sulla modalità con cui tali modifiche vengono replicate; il numero di sequenza di aggiornamento di un controller di dominio non ha alcun significato per altri controller di dominio se le due modifiche vengono messe a confronto.
Ma questo non è l'unico modo in cui l'USN di un controller di dominio viene incrementato. Si tenga presente che una modifica al database di Active Directory può comportare una scrittura di origine o una scrittura replicata. Il numero di sequenza dell'aggiornamento in un controller di dominio viene incrementato da entrambi i tipi di operazioni di scrittura, il che significa che viene incrementato ogni volta che avviene la replica di una modifica in un altro controller di dominio. A questo punto è chiaro che ciascun controller di dominio necessita di un metodo per tenere traccia delle modifiche già replicate, altrimenti a ogni replica potrebbe trovarsi a inviare l'intero database di Active Directory tramite cavo. Per evitare che ciò si verifichi, ogni controller di dominio di Active Directory mantiene un valore definito vettore limite massimo (HWMV) per gli altri controller di dominio con cui esegue la replica. Ogni controller di dominio assocerà questo valore all'identificatore univoco globale (GUID) del controller di dominio remoto, per evitare qualunque confusione nel caso in cui un controller di dominio remoto venga ridenominato o rimosso dalla directory.
Iniziamo con un semplice esempio, in cui due controller di dominio sono stati configurati nel dominio contoso.com, dc1.contoso.com e dc2.contoso.com. Poiché sono presenti soltanto due controller di dominio nel dominio contoso.com, DC1 e DC2 si replicano a vicenda. Si noti che si tratta di un esempio semplificato che non indica ancora l'intera storia della replica di Active Directory. Ulteriori dettagli verranno aggiunti più avanti.
Ipotizziamo inoltre che l'attuale USN del DC1 sia 3000, che l'USN del DC2 sia 4500 e che, nel momento in cui cominciamo l'esempio questi due controller di dominio siano completamente aggiornati tra loro:
Passaggio 1: DC1 e DC2 sono aggiornati con i rispettivi dati. DC1 presenta un vettore limite massimo per DC2 di 4500, mentre DC2 presenta un vettore limite massimo per DC1 di 3000, come illustrato nella Figura 1.
Figura 1 Stato attuale dei due controller di dominio
Figura 1 Stato attuale dei due controller di dominio
Passaggio 2: Un amministratore crea un nuovo oggetto nel DC1 e l'USN del DC1 viene incrementato a 3001, come illustrato nella Figura 2. Si noti che il vettore HWMV del DC1 non è cambiato in DC2, perché DC1 non ha ancora informato DC2 che è in attesa di modifiche.
Figura 2 Viene aggiunto un nuovo oggetto
Figura 2 Viene aggiunto un nuovo oggetto
Passaggio 3: DC1 informa DC2 che sono disponibili alcune modifiche. DC2 inizia la replica con DC1 per richiedere tutti gli aggiornamenti disponibili. Nella stessa richiesta, DC2 invia a DC1 il vettore limite massimo che viene memorizzato per DC1, come illustrato nella Figura 3.
Figura 3 Notifica delle modifiche
Figura 3 Notifica delle modifiche
Passaggio 4: DC1 invia a DC2 la modifica che corrisponde a USN 3001, ovvero, l'oggetto creato su DC1 nel Passaggio 2. DC2 aggiorna il proprio USN a 4501 e il relativo HWMV per DC1 a 3001, come illustrato nella Figura 4.
Figura 4 Modifiche e aggiornamenti
Figura 4 Modifiche e aggiornamenti
Fin qui tutto bene. Ma ecco presentarsi un problema. DC2 dispone di una modifica da replicare. Se le uniche cose da portare avanti erano gli USN e i vettori limite massimo, a questo punto DC2 dovrebbe contattare DC1 per replicare la stessa modifica appena replicata da DC1 a DC2, il che creerebbe un ciclo di replica infinito e consumerebbe progressivamente sempre più larghezza di banda. Per evitare ciò, sono necessari alcuni pezzi del puzzle, il primo del quale è il vettore di aggiornamento (vettore UTD o semplicemente UTDV).
L'UTDV è un altro pezzo dei metadati di replica che viene utilizzato per il blocco della propagazione; il suo scopo è evitare che la stessa modifica sprechi larghezza di banda mediante la replica ripetuta attraverso la rete. Ogni controller di dominio conserva una tabella UTDV per qualsiasi altro controller di dominio che memorizza una copia del contesto dei nomi in questione. Per il contesto dei nomi del dominio, ogni controller di dominio in un dominio conserva un UTDV per ciascun controller di dominio nel dominio; per il contesto dei nomi della configurazione e dello schema, viene mantenuto per ogni controller di dominio nell'insieme di strutture. La tabella UTDV tiene traccia non solo dell'USN più alto che ogni controller di dominio ha ricevuto dai partner di replica, ma anche il valore USN più alto che ha ricevuto da ciascun controller di dominio che esegue la replica di un determinato contesto dei nomi. Per tenerne conto, ogni modifica replicata contiene anche le seguenti informazioni:
  • Il GUID del controller di dominio che replica la modifica. Potrebbe trattarsi di una modifica che viene replicata come una scrittura di origine o come una scrittura replicata.
  • L'USN del controller di dominio che replica la modifica. Ancora una volta, ciò può avvenire da una scrittura di origine o replicata.
  • Il GUID del controller di dominio che ha dato origine alla modifica. Se questo GUID è uguale al GUID del controller di dominio che replica la modifica, si tratta di una scrittura di origine. Altrimenti, entra in gioco la tabella UTDV.
  • L'USN del controller di dominio che ha dato origine alla modifica. Ancora una volta, se questo USN è uguale all'USN del controller di dominio che replica la modifica, si tratta di una scrittura di origine. In caso contrario, non entra in gioco la tabella UTDV.
Per illustrare meglio questo processo, renderemo più complesso l'esempio aggiungendo un terzo controller di dominio, DC3. In questo esempio, DC1, DC2 e DC3 sono tutti partner di replica reciproci; DC1 si replica con DC2 e DC3, DC2 con DC1 e DC3, infine DC3 con DC1 e DC2:
Passaggio 1: DC1, DC2 e DC3 sono aggiornati l'uno con i dati degli altri.
Passaggio 2: DC3 esegue una singola operazione di scrittura di origine reimpostando la password per l'account utente jsmith. DC3 informa DC1 e DC2 che sono disponibili alcune modifiche. DC1 e DC2 contengono la scrittura di origine di DC3 e aggiornano le tabelle HWMV e UTDV per DC3, come illustrato nella Figura 5.
Figura 5 Aggiornamento delle tabelle HWMV e UTDV
Figura 5 Aggiornamento delle tabelle HWMV e UTDV
Passaggio 3: Ecco dove entra in gioco il vettore di aggiornamento. DC2 informa DC1 che sono disponibili alcune modifiche. DC1 contatta poi DC2 che richiede tutte le modifiche nuove inviando a DC2 le seguenti informazioni:
  • Il vettore limite massimo di DC1 per DC2, in questo caso 4501.
  • Tabella UTDV del DC1 (illustrata nella Figura 6), che indica l'USN di origine più elevato ricevuto da tutti i controller di dominio, compreso DC3.
Figure 6 Tabella UTDV (Close Figure 6)

Tutti i controller di dominio che replicano questo contesto dei nomi | UTDV
<GUID del DC2> | 4501
<GUID del DC3> | 7002
In base al valore HWMV di 4501, DC2 verifica che non sia stata replicata la modifica in questione a DC1 (vedere la Figura 7).
Figure 7 È necessario replicare una modifica (Close Figure 7)

Proprietà | Valore | GUID del controller di dominio locale | USN locale | GUID del controller di dominio di origine | USN di origine
Proprietà della password jsmith | %#FH%2rfg2 | <GUID del DC2> | 4501 | <GUID del DC3> | 7002
Tuttavia, in base alla tabella UTDV che DC1 ha trasmesso prima dell'avvio della replica, DC2 determina che DC1 non necessita effettivamente di questa modifica, poiché DC1 l'ha già ricevuta da DC3. A questo punto, DC1 aggiorna semplicemente la voce HWMV affinché DC2 rifletta l'USN incrementato, come illustrato nella Figura 8. Tuttavia, per risparmiare larghezza di banda, i dati reali non vengono inviati tramite cavo.
Figura 8 Blocco della propagazione
Figura 8 Blocco della propagazione
Passaggio 4: Questo stesso blocco della propagazione avrà luogo quando DC2 informa DC3 della presenza di modifiche disponibili e quando DC1 informa allo stesso modo DC2 e DC3. Tutti e tre i controller di dominio aggiorneranno le rispettive voci HWMV per i propri partner di replica, come illustrato nella Figura 8, ma i dati correnti non attraverseranno nuovamente il cavo poiché sono già stati trasmessi a ciascun DC nel Passaggio 2.

Risoluzione dei conflitti in un ambiente multimaster
Fino a qui i nostri esempi rientravano in un mondo perfetto, dove un solo amministratore alla volta apporta modifiche a un controller di dominio e nessuno si sovrappone alle operazioni di qualcun altro. Nel mondo reale, ciò non avviene mai. Poiché gli aggiornamenti a un oggetto di Active Directory possono essere eseguiti da qualsiasi controller di dominio nel dominio, cosa accade se i due amministratori apportano aggiornamenti in conflitto da due controller di dominio diversi? Esistono tre tipi di conflitti che possono verificarsi in un ambiente Active Directory, ciascuno dei quali utilizza un metodo diverso di risoluzione dei conflitti.
Conflitti nelle modifiche delle proprietà . Un conflitto di questo tipo si verifica nel caso in cui due amministratori aggiornano lo stesso oggetto in maniera differente: un amministratore imposta una descrizione dell'utente su "Marketing", mentre un altro amministratore su un controller di dominio diverso imposta la descrizione di quell'utente su "Vendite e marketing".
Creazione di nuovi oggetti in conflitto . Questo conflitto si verifica se due amministratori creano contemporaneamente un oggetto con lo stesso nome, ad esempio due utenti denominati jsmith.
Spostamento di un oggetto in un contenitore eliminato . Questo tipo di conflitto è molto più raro e ha luogo se un amministratore crea o sposta un oggetto in un contenitore, ad esempio un'unità organizzativa, mentre un altro amministratore su un controller di dominio diverso elimina quel contenitore.
Per risolvere i primi due tipi di conflitti, è arrivato il momento di presentare due ulteriori parti di metadati di replica che vengono utilizzati principalmente per la risoluzione dei conflitti. Il valore versionID viene assegnato a ogni singolo attributo su un oggetto, con un valore iniziale di 1 la prima volta che viene creato l'oggetto e viene incrementato di 1 ogni volta che un singolo attributo viene modificato da qualunque controller di dominio. Pertanto, se l'attributo della descrizione di un determinato utente viene aggiornato rispetto al relativo valore predefinito (vuoto o <non impostato>) in "Reparto marketing", l'attributo della descrizione avrà un valore versionID di 2. Se, successivamente, la descrizione viene modificata in "Reparto vendite e marketing", l'attributo della descrizione avrà un valore versionID di 3, e così via. Questo valore versionID è incluso in ogni voce di replica insieme ad altre parti di metadati già presentati.
È possibile utilizzare versionID anche per ridurre il traffico di replica. Ad esempio, se un amministratore su DC2 ha apportato diverse modifiche a un singolo attributo (digitando a volte erroneamente la modifica) per cui DC2 dispone di scritture di origine che corrispondono al valore versionIDs 2, 3, 4 e 5, DC2 replicherà soltanto la scrittura che corrisponde all'ultimo valore, versionID 5. Poiché le prime modifiche verrebbero comunque semplicemente sovrascritte, si ottiene un collegamento che consente di ridurre l'utilizzo inutile della larghezza di banda.
Ogni modifica ad Active Directory include anche il secondo pezzo aggiuntivo di metadati utilizzato per la risoluzione dei conflitti, un timestamp, come parte dei metadati di replica, che indica quando è stata apportata la modifica.
L'attributo timestamp viene utilizzato anche come misura proattiva dello stato di replica di Active Directory. Se un controller di dominio non ha visualizzato alcuna modifica con un timestamp relativamente recente di un controller di dominio particolare, inizierà a generare dei messaggi di errore che indicano la possibile presenza di problema con il controller di dominio in questione.
Pertanto, come vengono utilizzati questi due attributi nella risoluzione dei conflitti? Esaminiamo singolarmente ogni tipo di conflitto.

Risoluzione dei conflitti nelle modifiche delle proprietà
Si prenda in considerazione l'esempio dell'oggetto utente jsmith nel dominio contoso.com. Un amministratore nel DC1 modifica la descrizione di jsmith in "Marketing". Quasi contemporaneamente, un amministratore nel DC3 modifica la stessa descrizione dell'utente in "Vendite e marketing". A questo punto, le informazioni di DC1 e DC3 relative all'attributo di descrizione di jsmith vengono messe a confronto, come illustrato nella Figura 9.
Figure 9 Modifiche quasi simultanee (Close Figure 9)

Server | Proprietà | Valore | VersionID | Timestamp | GUID del controller di dominio locale | USN locale | GUID del controller di dominio di origine | USN di origine
DC1 | Proprietà della descrizione jsmith | "Marketing" | 2 | 2007-06-07 14:03:25 | <GUID del DC1> | 3003 | <GUID del DC1> | 3003
DC3 | Proprietà della descrizione jsmith | "Vendite e marketing" | 2 | 2007-06-07 14:04:57 | <GUID del DC3> | 7003 | <GUID del DC3> | 7003
Se DC2 riceve entrambe queste modifiche contemporaneamente, dovrà necessariamente determinare quale sia quella "vincente". L'ordine degli spareggi per la risoluzione di conflitti è il seguente:
  1. La modifica che ha il valore versionID più elevato sarà accettata come modifica "vincente"; quella "perdente" verrà sovrascritta. In questo caso, il valore di versionID è 2 per entrambi i record, dunque sarà necessario passare al secondo spareggio.
  2. Se entrambi i record hanno lo stesso valore di versionID, la modifica con il timestamp più recente verrà considerata come vincente; l'altra verrà sovrascritta. In questo caso, il timestamp della scrittura di origine di DC3 è successivo, pertanto la descrizione di jsmith verrà impostata su "Vendite e marketing". Nel raro caso in cui sia il valore versionID che il timestamp siano identici, sarà necessario un terzo spareggio definitivo:
  3. Se entrambi i record hanno lo stesso valore versionID e timestamp, qualunque scrittura proveniente dal controller di dominio con il GUID inferiore vincerà; la scrittura con il GUID superiore verrà sovrascritta. Pertanto, se il GUID del DC1 è 1234567890 e quello del DC3 è 2345678901, la scrittura di origine del DC1 avrebbe la meglio se entrambi i valori di versionID e timestamp fossero identici.
Probabilmente verrebbe da pensare, "Non avrebbe più senso far sì che timestamp sia il primo spareggio?". Ciò non è prestabilito, come si potrebbe pensare. Se timestamp fosse lo spareggio principale nella risoluzione dei conflitti di Active Directory, l'unica cosa che dovrebbe fare un amministratore malintenzionato per diffondere le proprie modifiche sarebbe impostare di nuovo l'orologio su un controller di dominio particolare in modo che vincesse in base al timestamp.

Risoluzione dei conflitti nella creazione degli oggetti
Nel caso in cui venissero creati due oggetti con lo stesso nome, Active Directory utilizzerà gli stessi tre spareggi descritti nella sezione precedente per stabilire qual è l'oggetto "vincente". A differenza della sezione precedente, tuttavia, l'oggetto "perdente" non viene sovrascritto. Al contrario, tale oggetto viene ridenominato utilizzando il CNF dei caratteri (per l'oggetto di conflitto), seguito da due punti e dal GUID dell'oggetto "perdente". Ciò consente agli amministratori di stabilire in maniera più metodica quale oggetto deve essere conservato e quale invece eliminato.

Risoluzione dei conflitti dovuti allo spostamento di un oggetto in un contenitore eliminato
Come già accennato, la risoluzione di un conflitto dovuto allo spostamento di oggetto in un contenitore eliminato è un caso abbastanza raro che si verifica soltanto in uno dei due scenari illustrati di seguito. Nel primo, un amministratore su un controller di dominio crea un oggetto all'interno di un contenitore particolare, ad esempio Unità organizzativa di formazione, nello stesso momento in cui un amministratore in un altro controller di dominio elimina proprio tale contenitore. Il secondo scenario può verificarsi quando un amministratore in un controller di dominio sposta un oggetto in un contenitore nello stesso momento in cui un amministratore in un altro controller di dominio elimina quel contenitore.
La risoluzione in questo caso è abbastanza semplice: Active Directory sposta l'oggetto rimasto "orfano" in un contenitore speciale all'interno di Active Directory progettato proprio a questo scopo, il contenitore LostAndFound che si trova al di fuori della radice di ogni dominio Active Directory. Per il dominio contoso.com, il contenitore LostAndFound dovrebbe trovarsi nel seguente percorso LDAP: LDAP://cn=LostAndFound.dc=contoso.dc=com. Se quando viene aperto lo snap-in Utenti e computer di Active Directory non viene visualizzato il contenitore LostAndFound, è sufficiente fare clic su Visualizza | Funzionalità avanzate.

Protezione dal ripristino USN
Una delle situazioni più gravi che è possibile riscontrare in un ambiente Active Directory è anche una delle più semplici da evitare, una volta individuati la causa e il modo per risolverla. Il ripristino USN è una condizione di errore che può arrestare completamente la replica sulla rete e viene causato consentendo a un controller di dominio di rimanere non in linea per troppo tempo e poi riattivarlo o ripristinando un controller di dominio utilizzando un metodo non supportato.
Una causa implicita del ripristino USN ha a che fare con il modo in cui viene eseguita l'eliminazione degli oggetti nell'ambiente multimaster di Active Directory. Quando un oggetto viene eliminato definitivamente da un controller di dominio, l'oggetto viene contrassegnato per la rimozione definitiva in modo che tale oggetto possa essere replicato in altri controller di dominio, informandoli dell'eliminazione. In particolare, un oggetto contrassegnato per la rimozione definitiva dispone di un attributo isDeleted impostato su TRUE. Per ridurre la dimensione dell'oggetto contrassegnato per la rimozione definitiva, la maggior parte dei valori contenuti nell'oggetto, come la descrizione, le informazioni personali e l'appartenenza al gruppo di un oggetto utente, vengono rimossi (per ulteriori informazioni su questo processo, vedere l'articolo di Gil Kirkpatrick "Recupero degli oggetti contrassegnati per la rimozione definitiva di Active Directory" disponibile in linea all'indirizzo technetmagazine.com/issues/2007/09).
È possibile che si verifichi il ripristino USN perché questi oggetti non rimangono sospesi all'infinito. Per impostazione predefinita, vengono eliminati completamente dal database di Active Directory dopo 60 o 180 giorni (a seconda della versione di Windows Server® in esecuzione sul proprio computer la prima volta che è stato creato l'ambiente Active Directory). Questo periodo di 60 o di 180 giorni viene definito durata dell'oggetto contrassegnato per la rimozione definitiva. Tutti i controller di dominio devono essere in grado di replicare almeno una volta durante questo periodo altrimenti diventano inutili e creano un'opportunità per il ripristino USN. Fondamentalmente, il ripristino USN si verifica quando un controller di dominio è talmente obsoleto da non contenere più oggetti contrassegnati per la rimozione definitiva e che, pertanto, non è in grado di mantenere aggiornata la copia locale del database di Active Directory con gli altri controller di dominio. Per cautelarsi, qualunque controller di dominio che è stato non in linea per un tempo maggiore rispetto alla durata dell'oggetto contrassegnato per la rimozione definitiva non deve essere ripristinato; sarà opportuno, invece, crearlo da zero eliminando i vecchi metadati del controller di dominio di Active Directory seguendo i passaggi presenti nell'articolo della Microsoft Knowledge Base 216498 (support.microsoft.com/kb/216498).
Il ripristino USN si verifica anche quando un controller di dominio viene ripristinato utilizzando un metodo non supportato oppure, più spesso, utilizzando uno strumento di creazione di immagini o di clonazione dei dischi. Nel momento in cui si verifica una situazione di questo tipo, il database di Active Directory ripristinato non realizza di essere tornato "indietro nel tempo" perché il metodo di ripristino non era supportato per Active Directory. Con Windows 2000 e la prima versione di Windows Server 2003 era difficile poter individuare un ripristino USN mentre Windows Server 2003 SP1 (e Windows Server 2008 disponibile a breve) dispone di controlli incorporati che consentono di rilevare eventuali ripristini non corretti di un controller di dominio. In queste nuove versioni del sistema operativo, un controller di dominio registrerà l'ID evento 1115, 2095, 2103 e 2110 nel registro eventi dei servizi di directory. Il testo di questi eventi, oltre ai passaggi necessari per il ripristino USN, sono rintracciabili nell'articolo della Knowledge Base 875495 (support.microsoft.com/kb/875495) per Windows Server 2003. È possibile trovare ulteriori informazioni sulla gestione del ripristino USN in Windows 2000 nell'articolo della Knowledge Base 885875, disponibile all'indirizzo support.microsoft.com/kb/885875.

Aggiornamento del modello multimaster nel 2008
Con la versione imminente di Windows Server 2008, Microsoft ha inserito una leggera modifica al modello multimaster introducendo il Controller di dominio di sola lettura (RODC, Read-Only Domain Controller). Il RODC è stato progettato principalmente per le distribuzioni alle succursali o per qualunque scenario in cui non si dispone in sede di personale IT dedicato e in cui è necessario effettuare operazioni aggiuntive per garantire l'integrità di un controller di dominio particolare. Sebbene potremmo dedicare un intero articolo per approfondire tutti i dettagli tecnici del RODC, riesaminiamo i punti principali di cui è necessario essere a conoscenza.
Come indica il nome stesso, la copia del database di Active Directory che si trova in un RODC è di sola lettura. È possibile connettersi a un RODC per leggere tutte le informazioni desiderate, ma non sarà possibile eseguire alcuna operazione di scrittura.
In secondo luogo, un RODC non esegue repliche in uscita. Si tratta di una differenza fondamentale rispetto al modello di replica multimaster di cui abbiamo discusso fino a questo punto. Un RODC riceverà la replica in ingresso dagli altri controller di dominio di Windows Server 2008 scrivibili, ma non replicherà tutte le informazioni al di fuori del controller di dominio. In questo modo viene a crearsi un ulteriore livello di protezione che, nel caso in cui un utente malintenzionato fosse in grado di modificare Active Directory dal RODC, tali modifiche non verrebbero diffuse in tutto l'ambiente.
Probabilmente, la cosa più interessante di tutte è che il RODC non replica le password dell'utente per impostazione predefinita. Quando il database di Active Directory viene replicato in ingresso a un RODC da un controller di dominio scrivibile, tutti gli oggetti utente vengono replicati senza le informazioni sulla password dell'utente. In questo modo viene fornito un ulteriore livello di protezione in una succursale, in maniera tale che se a un controller di dominio "gli crescono le gambe e scappa via", il disco rigido non contiene alcuna informazione sulla password. Nel loro insieme, queste differenze con l'idea originale della replica di Active Directory multimaster creano un modello migliorato per la protezione dei controller di dominio nelle filiali o in altre posizioni remote.

Laura E. Hunter è stata insignita per quattro volte del premio Microsoft MVP per l'area Windows Server Networking. Lavora da oltre 10 anni nel settore IT ed è autrice o coautrice di numerosi libri, articoli e white paper, tra cui Active Directory Cookbook, Second Edition (O'Reilly, 2006).


 System Center: Nuovi strumenti di gestione degli aggiornamenti software
System Center Steve Rachui

Nuovi strumenti di gestione degli aggiornamenti software
Panoramica:
  • Gestione degli aggiornamenti con i metodi precedenti
  • Il nuovo processo in SCCM 2007
  • Configurazione personalizzata e flessibilità
  • Pianificazione degli aggiornamenti ottimizzata

La gestione degli aggiornamenti software è stata introdotta per la prima volta in SMS (Systems Management Server) 2.0, con gli strumenti di protezione e di analisi degli aggiornamenti di Office. Questi strumenti hanno subito vari rimaneggiamenti: lo strumento esteso
per l'inventario degli aggiornamenti di protezione è stato rielaborato in modo da supportare l'analisi di altri prodotti; Inventory Tool for Microsoft ® Updates in modo da combinare gli strumenti di protezione e di Office in un unico prodotto; infine Inventory Tool for Dell Updates. Anche Custom Updates Publish Tool è stato introdotto al fine di supportare i prodotti di patching di terzi. ITMU (Inventory Tool for Microsoft Updates) è stato sottoposto a tre revisioni. Ciascuno di questi strumenti è costituito da propri cataloghi, infrastrutture di analisi, requisiti unici e sfide. Nel tempo i cataloghi per questi sistemi sono diventati molto estesi, al punto che gli aggiornamenti più vecchi sono stati eliminati in favore dei nuovi, a causa dei limiti di spazio.
Con la gamma di opzioni disponibili, distribuire gli aggiornamenti con questi strumenti poteva diventare molto complicato. È stato quindi necessario semplificare il processo. Con la versione successiva di SMS-System Center Configuration Manager 2007 (SCCM) si sono fatti grandi progressi in questa direzione. Con SCCM, il meccanismo degli aggiornamenti software è stato ottimizzato al fine di raggiungere risultati complessivi migliori. Un approccio completamente diverso alle operazioni di gestione degli aggiornamenti, ha reso i vecchi cataloghi e motori di analisi del tutto obsoleti. Per lo stato dell'aggiornamento, storicamente riportato tramite un inventario dell'hardware, si utilizza ora un meccanismo nuovo, il messaggio di stato, che garantisce una migliore determinazione della conformità e dell'applicazione su ciascun client. Il nuovo approccio alla gestione degli aggiornamenti in SCCM 2007 rappresenta un miglioramento significativo.
SCCM 2007 introduce due componenti nuovi che è necessario illustrare prima di affrontare l'argomento della funzionalità di gestione degli aggiornamenti.
SUP (Software Update Point) Come già accennato, i cataloghi in SCCM non esistono più. SCCM infatti opera direttamente con un server WSUS (Windows Server® Update Services) dedicato, che funziona da SUP (Software Update Point) per il download dei metadati e l'analisi dei client. In SCCM le funzioni di recapito binario degli aggiornamenti di WSUS sono disattivate per concentrare l'attenzione sul processo di analisi. Con questa modifica, WSUS riesce a gestire l'analisi di un massimo di 25.000 client per SUP su un server dedicato. Con SCCM è inoltre possibile configurare SUP dietro un cluster NLB di bilanciamento del carico di rete per una maggiore disponibilità e scalabilità, con l'attivazione di fino a quattro SUP per un totale di 100.000 possibili client per il sito primario.
Elementi di configurazione (CI) L'elemento di configurazione è un nuovo approccio utilizzato in SCCM per definire le configurazioni specifiche che devono esistere nei sistemi di destinazione. Per la gestione degli aggiornamenti SCCM ora si utilizza questa infrastruttura. Gli aggiornamenti non devono essere più concepiti in termini di normale distribuzione del software, sebbene sussistano delle somiglianze. Al contrario, gli aggiornamenti risiedono in un proprio nodo all'interno della console di amministrazione e utilizzano questo meccanismo CI assolutamente unico. Sul lato client gli aggiornamenti vengono scaricati in modo selettivo e memorizzati a livello locale.

Configurazione della gestione degli aggiornamenti
L'impostazione della gestione degli aggiornamenti rientra in tre aree generali: abilitazione dell'agente client, configurazione del SUP e configurazione degli aggiornamenti per la distribuzione.
L'agente client SCCM (come illustrato nella Figura 1) è simile agli altri agenti client ed è configurato nello stesso nodo della console di amministrazione. Nella pagina delle proprietà del nodo Software Updates Client Agents gli amministratori possono attivare questo agente e configurare l'installazione degli aggiornamenti e le impostazioni per la scheda Deployment Re-evaluation. L'impostazione di attivazione di Software Updates Client Agent viene applicata all'intero sito, ne consegue che il ruolo sarà attivato in ciascun client SCCM assegnato al sito in cui è attiva questa funzione. Se per alcuni sistemi presenti in un ambiente questa funzione non è attivata, sarà possibile sovrascrivere l'impostazione per l'intero sito in base al sistema utilizzando le impostazioni per la sovrascrittura dei criteri locali.
Figura 1 Proprietà dell'agente client
Figura 1 Proprietà dell'agente client
Le impostazioni consentono inoltre all'amministratore di specificare come vanno gestite le scadenze degli aggiornamenti. Si supponga, ad esempio, di avere quattro aggiornamenti in attesa di installazione, uno (l'aggiornamento A) con scadenza un giorno dopo gli altri tre. È preferibile installare comunque tutti e quattro gli aggiornamenti contemporaneamente, anche quelli non ancora scaduti. L'opzione in questa scheda per l'applicazione di tutte le distribuzioni obbligatorie consente di impostare questa scelta. Inoltre, le impostazioni consentono agli amministratori di specificare che tutte le notifiche e le indicazioni visibili del processo di aggiornamento devono essere eliminate. Queste opzioni sono illustrate nella Figura 1.
Le impostazioni nella scheda Deployment Re-evaluation consentono agli amministratori di pianificare i tempi di rivalutazione delle distribuzioni. I client SCCM saranno valutati secondo questa pianificazione per controllare se gli aggiornamenti installati in precedenza sono ancora necessari e, qualora risultino mancanti, si procederà a reinstallarli.

Configurazione del SUP
Come già accennato, SUP è il componente che si occupa del download di tutte le informazioni sugli aggiornamenti disponibili presenti in una pianificazione e che regola l'interazione diretta con i client SCCM per analisi di conformità basate sul database degli aggiornamenti. Prima di configurare un SUP, è necessario installare un server WSUS 3.0 o superiore, poiché il processo del SUP non installa realmente WSUS, ma configura WSUS per l'utilizzo di SCCM. Inoltre, la Console di amministrazione WSUS deve essere installata sul server del sito per abilitare la connettività con il server WSUS. Nel momento in cui SCCM assume il controllo del server WSUS per il ruolo SUP, il server WSUS viene dedicato a SCCM e può essere utilizzato solo dai client SCCM.
Il SUP è un nuovo ruolo di sistema del sito disponibile in SCCM. Per avviare la configurazione, passare al nodo dei sistemi del sito della console amministrazione e aggiungere un nuovo sistema del sito. Selezionare quindi il SUP e proseguire con la procedura guidata, che raccoglierà le informazioni seguenti:
  • Configurazione proxy
  • Informazioni su porta e SSL
  • Modalità di aggiornamento per la sincronizzazione con il SUP: da Microsoft Update, tramite un SUP upstream o manualmente
  • Pianificazione della sincronizzazione
  • Aggiornamento delle classificazioni in base all'interesse, come aggiornamenti critici, driver, aggiornamenti per la protezione, rollup di aggiornamento e così via
  • Aggiornamento dei prodotti disponibili: Windows®, Exchange, SQL Server™ e così via (riportati nella Figura 2)
  • Lingua
Figura 2 Impostazioni del prodotto nella creazione guidata del ruolo del sito
Figura 2 Impostazioni del prodotto nella creazione guidata del ruolo del sito
Una volta completata la procedura guidata, il SUP verrà installato e le configurazioni interne saranno impostate in modo da supportare i requisiti di SCCM. È opportuno confermare l'esito positivo dell'installazione esaminando il file SUPSetup.log che si trova nella cartella dei registri in cui è stato installato SCCM.
Una volta installato SUP, è necessario eseguire la sincronizzazione per recuperare gli aggiornamenti e memorizzarli in SUP e nel database SCCM. È possibile eseguire la sincronizzazione manualmente o in una pianificazione configurata quando è in esecuzione la procedura guidata di installazione. La sincronizzazione manuale degli aggiornamenti può essere avviata in qualsiasi momento ed è opportuno verificare che la sincronizzazione avvenga dopo aver installato per la prima volta SUP. Nella Figura 3 viene illustrata la procedura per ottenere questo risultato.
Figura 3 Esecuzione manuale della sincronizzazione
Figura 3 Esecuzione manuale della sincronizzazione
Il processo di sincronizzazione si sviluppa in due fasi. Prima di tutto, il server SUP (WSUS) viene configurato in modo da associare le impostazioni di SCCM e gli aggiornamenti configurati vengono sincronizzati nel server SUP (WSUS). Al termine di queste operazioni, le informazioni sugli aggiornamenti dal server SUP (WSUS) vengono sincronizzate nel database SCCM e restano disponibili per la distribuzione degli aggiornamenti. In questa seconda fase si creano gli elementi di configurazione necessari (uno per ciascun aggiornamento software) nel database SCCM e potrebbe essere necessario molto tempo. A volte la sincronizzazione iniziale può richiedere diverse ore. Il processo di sincronizzazione può essere esaminato nel registro WSyncMgr, di cui è riportato un estratto nelle figure 4 e 5. In particolare nella Figura 4 si illustra il processo di sincronizzazione con la richiesta che il server SUP (WSUS) aggiorni l'elenco degli aggiornamenti da Microsoft Update. Nella Figura 5 è riportato l'inizio del processo per la sincronizzazione dell'inventario SUP nel database SCCM.
Figura 4 Sincronizzazione dell'elenco aggiornamenti
Figura 4 Sincronizzazione dell'elenco aggiornamenti
Figura 5 Sincronizzazione degli aggiornamenti come CI nel database di SCCM
Figura 5 Sincronizzazione degli aggiornamenti come CI nel database di SCCM
Dopo aver configurato un server WSUS come SUP, qualsiasi operazione di amministrazione richiesta può essere eseguita mediante la console di amministrazione SCCM. Se le modifiche di configurazione vengono eseguite direttamente sul server WSUS, ciò influirà negativamente su SCCM. Inoltre le configurazioni vengono reimpostate ogni ora quando SCCM controlla il SUP per accertarsi che le configurazioni siano corrette.
In una gerarchia multilivello è necessario disporre di almeno un SUP in ciascun sito primario in cui verranno distribuiti gli aggiornamenti software. Tali SUP lavoreranno insieme in una gerarchia con un unico SUP, in genere il più alto nella gerarchia, che esegue la sincronizzazione con Microsoft Update. I restanti SUP verranno sincronizzati da un partner di replica SUP configurato upstream.

Configurazione della distribuzione di aggiornamenti
Dopo aver configurato l'agente client e dopo aver configurato e sincronizzato il SUP, è possibile preparare concretamente una distribuzione. È prima di tutto opportuno esaminare i vari nodi dell'interfaccia utente dell'amministrazione SCCM. Esistono in sostanza cinque nodi principali di interesse: Update Repository, Update Lists, Deployment Templates, Deployment Management e Deployment Packages.
Update Repository è il nodo in cui vengono memorizzati tutti gli aggiornamenti sincronizzati disponibili per la distribuzione. Gli aggiornamenti possono essere distribuiti selezionando uno o più aggiornamenti e avviando la procedura guidata per la distribuzione degli aggiornamenti software, con l'esecuzione di due operazioni: configurazione del modello di distribuzione (o selezione di un modello già esistente) e configurazione della distribuzione vera e propria. Questo processo verrà illustrato brevemente di seguito. L'elenco di aggiornamenti può diventare piuttosto voluminoso e le cartelle di ricerca, una nuova funzionalità in SCCM 2007, possono facilitare molto la ricerca di aggiornamenti interessanti sulla base di 28 criteri relativi agli aggiornamenti, tra cui gravità, classificazione, prodotto, data di rilascio e sostituzione.

Modelli di distribuzione
I modelli di distribuzione contengono impostazioni comuni (come le informazioni di pianificazione e raccolta di destinazione) che si utilizzano durante la distribuzione degli aggiornamenti software e che sono state sviluppate per ridurre i tempi amministrativi necessari per la distribuzione degli aggiornamenti. I modelli possono essere creati per organizzare più condizioni di distribuzione in un ambiente e possono essere utilizzati nella distribuzione guidata, selezionando semplicemente il modello appropriato. Le impostazioni precompilate dal modello di distribuzione comprendono la raccolta di destinazione, le impostazioni di scadenza degli aggiornamenti (come illustrato nella Figura 6), le impostazioni di riavvio e le finestre di manutenzione. Se in una distribuzione è presente un numero elevato di aggiornamenti, gli effetti sulle prestazioni del sistema di destinazione potrebbero essere sensibili, poiché tutte le scadenze degli aggiornamenti capitano contemporaneamente. Inoltre, le impostazioni all'interno del modello vengono applicate alla distribuzione al momento della creazione della stessa. Queste impostazioni restano in vigore nella distribuzione, a meno che non vengano modificate manualmente all'interno della distribuzione. È importante ricordare che, se vengono modificate in un secondo momento, le impostazioni del modello non verranno modificate nelle distribuzioni esistenti in cui si utilizza il modello modificato.
Figura 6 Impostazione dei piani di distribuzione nella procedura guidata
Figura 6 Impostazione dei piani di distribuzione nella procedura guidata
Le opzioni contenute nella Figura 6 possono essere configurate durante l'esecuzione della procedura guidata per il modello di distribuzione o della procedura guidata per la distribuzione degli aggiornamenti software (quando si crea un modello nuovo). Si noti come il valore della durata in questa schermata sia impostato su 0. Il valore predefinito per questa impostazione è due settimane. Se questo valore è impostato su un numero diverso da 0, si avrà un ritardo sul client per la distribuzione degli aggiornamenti, in base alla lunghezza di tale valore. Nel periodo di tempo compreso tra il momento in cui la distribuzione si rende disponibile e quello in cui viene applicata la scadenza configurata, l'aggiornamento sarà disponibile all'utente finale per un'installazione manuale per le installazioni pianificate prima della scadenza. Alla data della scadenza, l'aggiornamento verrà necessariamente installato. In caso di ritardi nella distribuzione degli aggiornamenti, verificare che questa impostazione sia configurata correttamente in base alle proprie esigenze.

Gestione della distribuzione
Dopo aver configurato una distribuzione degli aggiornamenti software, è possibile accedervi nel nodo Deployment Management. È opportuno ricordare che una distribuzione software configurata non equivale a un pacchetto di distribuzione. Le impostazioni relative alla distribuzione, come pure gli aggiornamenti contenuti nella distribuzione, possono essere visualizzati e manipolati in questo nodo, ma ciò non è possibile con il pacchetto. Le impostazioni di distribuzione qui illustrate riflettono le impostazioni che provengono dagli aggiornamenti software insieme a quelle ereditate dal modello selezionato.

Pacchetti di distribuzione
I pacchetti di distribuzione sono simili ai pacchetti SMS standard perché definiscono le specifiche dell'aggiornamento, ovvero la directory di origine, il punto di distribuzione e così via. I pacchetti di distribuzione sono indipendenti dalla distribuzione vera e propria utilizzata per distribuire gli aggiornamenti e costituiscono essenzialmente un archivio per gli aggiornamenti. Se più di un pacchetto di distribuzione contiene gli aggiornamenti necessari per una distribuzione, gli agenti SCCM determineranno il percorso migliore da cui recuperare l'aggiornamento e potranno utilizzare qualsiasi pacchetto di distribuzione disponibile che contenga tale aggiornamento.
Per distribuire gli aggiornamenti in SCCM, viene utilizzata la procedura guidata per la distribuzione degli aggiornamenti software. Tale procedura guidata può essere utilizzata con aggiornamenti singoli o con elenchi di aggiornamenti. Nella Figura 7 viene illustrato come avviare la procedura guidata.
Figura 7 Avvio della procedura guidata per la distribuzione degli aggiornamenti software
Figura 7 Avvio della procedura guidata per la distribuzione degli aggiornamenti software
In questa procedura guidata viene richiesto un nome per la distribuzione, se si utilizzano impostazioni di modello nuove o esistenti (se viene selezionato un modello nuovo, la procedura guidata richiederà le impostazioni del modello descritte sopra), le impostazioni del pacchetto di distribuzione (esistente o nuovo), le impostazioni del punto di distribuzione, le opzioni del percorso per il download, le lingue di aggiornamento da scaricare e le informazioni di pianificazione della distribuzione.
Al termine della configurazione, i criteri vengono aggiornati per notificare ai client gli aggiornamenti di destinazione e gli aggiornamenti vengono installati nei sistemi client. I processi client sono abbastanza diversi dalle versioni precedenti e non riguardano gli argomenti trattati in questo articolo. Una differenza principale, tuttavia, consiste nel fatto che le analisi degli aggiornamenti non vengono più eseguite localmente, poiché il SUP gestisce tutto il processo di analisi, ma i dettagli sulla conformità degli aggiornamenti vengono memorizzati nell'archivio WMI (Windows Management Instrumentation) locale, come nelle versioni precedenti.
A differenza delle versioni precedenti, invece, per inviare lo stato di aggiornamento al server del sito non viene più utilizzato l'inventario hardware. I messaggi di stato infatti (un tipo nuovo di messaggio di stato semplificato) vengono inviati al server del sito attraverso il punto di gestione. I messaggi di stato forniscono dati su tutti i client gestiti per l'analisi di conformità e per tenere traccia dell'avanzamento delle distribuzioni. Esistono diversi nuovi report in SCCM per la gestione degli aggiornamenti software, tra cui conformità globale per computer per tutti gli aggiornamenti distribuiti a ciascun client, stato di applicazione della distribuzione per client e report di errori client per le analisi e le distribuzioni che forniscono un elenco, classificato per stack, dei problemi più gravi da risolvere.
Oltre all'applicazione tradizionale pianificata/obbligatoria della distribuzione degli aggiornamenti, con SCCM è possibile installare gli aggiornamenti approvati prima della scadenza di installazione in una pianificazione molto simile a quella utilizzata per gli aggiornamenti automatici. Questo ulteriore e utile elemento consentirà di aumentare di molto il numero di sistemi conformi prima della scadenza di distribuzione.
Se l'utente è interessato agli aggiornamenti personalizzati, SCCM è la soluzione ideale. Lo strumento di pubblicazione degli aggiornamenti personalizzati da SMS 2003 R2 è stato modificato in modo da essere utilizzato con SCCM 2007 come server di pubblicazione per gli aggiornamenti di System Center. In questo modo tutti gli aggiornamenti personalizzati possono essere distribuiti nello stesso modo descritto.
Le modifiche apportate alla gestione aggiornamenti sono molte in SCCM, ma dal punto di vista dell'amministrazione dovrebbero essere più facili da utilizzare e dovrebbero rappresentare un chiaro miglioramento rispetto alle versioni precedenti. Nonostante alcune delle modifiche concettuali possano sembrare inizialmente una sfida per gli utenti abituati a SMS 2003, senza dubbio vale la pena di provare questo nuovo approccio. Buon lavoro.

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


 Comunicazioni: Server Trasporto Edge di Microsoft Exchange
Comunicazioni Kay Unkroth

Server Trasporto Edge di Microsoft Exchange
Panoramica:
  • Ruolo del server Trasporto Edge di Exchange
  • Configurazione di un laboratorio per i test
  • Agenti ed eventi di trasporto
  • Agenti interni
Scarica il codice per questo articolo: ExchangeEdge2007_10.exe (354KB)

In media, in un giorno lavorativo Microsoft riceve ogni giorno circa 13 milioni di tentativi di inoltro di messaggi da Internet e ne blocca oltre 10,5 milioni in quanto non legittimi. In situazioni
critiche, ad esempio durante attacchi di posta indesiderata o virus su Internet, il volume può aumentare fino a superare i 90 milioni. Naturalmente queste informazioni si riferiscono a Microsoft, tuttavia attacchi di phishing, posta indesiderata e virus introdotti con la posta elettronica, directory harvesting, attacchi distribuiti Denial of Service (DDoS) e problemi simili non interessano solo Microsoft. Nell'affrontare problemi di questo tipo, come viene garantita la distribuzione di messaggi legittimi agli utenti continuando a proteggere l'ambiente di messaggistica dal flusso di contenuti illegittimi e dannosi?
Un modo per ottenere una protezione della messaggistica affidabile consiste nel distribuire i server Trasporto Edge e Forefront Security per Exchange Server di Exchange Server 2007 in una rete perimetrale tra Internet e l'ambiente di produzione. In questo modo per tutto il perimetro viene collocato un team organizzato di oltre 10 agenti Trasporto Edge che consentono di proteggere gli utenti e i sistemi di produzione. L'importanza di bloccare il prima possibile il contenuto indesiderato è evidente. In teoria, ciò accade persino prima che il contenuto venga distribuito ai server, considerando il carico che l'ambiente di messaggistica deve sostenere in una situazione critica. Tuttavia, per proteggere la messaggistica è possibile fare molto di più che bloccare semplicemente i messaggi.
Questa è la prima parte di una serie dedicata all'architettura e alle funzionalità chiave di agenti contro virus e posta indesiderata disponibili con Exchange Server 2007 e Forefront Security per Exchange Server. Affinché le spiegazioni siano realistiche e pratiche, in questo primo articolo verrà illustrato come creare un laboratorio per i test che rispecchi il progetto di protezione della messaggistica utilizzato da Microsoft nell'ambiente di produzione aziendale. In seguito, verrà analizzata in dettaglio l'architettura Trasporto Edge di Exchange Server 2007.
In tutto l'articolo si farà grande uso di script e file batch per automatizzare le attività di configurazione più importanti. Questi file contengono commenti che spiegano i singoli passaggi eseguiti. È possibile trovare gli script nel download disponibile nel sito Web TechNet Magazine all'indirizzo technetmagazine.com/code07.aspx.

Topologia Trasporto Edge
Nella Figura 1 viene illustrato il progetto Trasporto Edge implementato da Microsoft IT nell'ambiente di produzione aziendale. Prima di approfondire l'architettura Trasporto Edge, è opportuno analizzare alcune funzionalità di progettazione molto interessanti. Per i dettagli relativi all'implementazione completa, vedere il white paper IT Showcase indicato nella barra laterale "Risorse di Exchange".
Figura 1 Topologia Trasporto Edge in Microsoft
Figura 1 Topologia Trasporto Edge in Microsoft
Se si analizza la Figura 1, è possibile notare che la topologia Trasporto Edge in Microsoft è completamente ridondante. Non esiste un solo punto di errore in qualsiasi posizione. Per il bilanciamento del carico, Microsoft IT utilizza esternamente il DNS round robin e internamente i connettori di messaggistica con più teste di ponte. È importante notare anche che per la ricerca di virus tutti i server di trasporto (Hub ed Edge) eseguono Forefront Security per Exchange Server. In questo modo Microsoft IT è in grado di eseguire la scansione di tutti i messaggi in ingresso e in uscita non appena questi raggiungono un server di trasporto nella topologia di invio dei messaggi.
Un altro aspetto importante della progettazione relativo alla protezione riguarda i server Trasporto Edge che non fanno parte dell'ambiente Active Directory®. Infatti, non è necessario distribuire i server Trasporto Edge in nessuna foresta di Active Directory. Tuttavia, per mantenere un framework di gestione coerente, è necessario applicare una serie di criteri comune e supportare Single Sign-On. Microsoft distribuisce tutti i server Trasporto Edge in una foresta extranet diversa dall'ambiente di produzione.
Infine, è possibile vedere come tutti i messaggi provenienti da Internet raggiungono Microsoft tramite i server Trasporto Edge con sede in Nord America. I server Trasporto Edge con sede a Dublino e a Singapore gestiscono soltanto i messaggi in uscita. Il vantaggio di concentrare tutto il traffico in ingresso sui server Trasporto Edge del Nord America consiste nel centralizzare i controlli di protezione e contro la posta indesiderata impedendo l'invio dei messaggi in uscita da datacenter regionali di grandi dimensioni alla struttura di messaggistica interna.
Omesh Desai, Systems Engineer di Microsoft IT, ha progettato la topologia Trasporto Edge in Microsoft. Quando ho chiesto a Omesh informazioni sulle più importanti funzionalità di progettazione, ha risposto "Durante la progettazione del server Trasporto Edge, sono state sfruttate le funzionalità di difesa da posta indesiderata e virus di Exchange per la protezione della messaggistica a più livelli nella struttura della messaggistica. La protezione perimetrale della messaggistica ha la priorità, ma un modello di gestione semplice è ugualmente importante. I server Trasporto Edge consentono di migliorare la protezione attraverso configurazioni firewall più rigide pur consentendo maggiore accuratezza dei servizi contro la posta indesiderata tramite la reputazione IP, gli aggiornamenti automatici del filtro contenuti, l'aggregazione dell'elenco indirizzi attendibili, nonché la convalida del timbro per i messaggi di posta elettronica. Per impostazione predefinita vengono crittografate tutte le comunicazioni interne tra server e, se possibile vengono crittografate anche le comunicazioni con le destinazioni esterne.
"Nei server Trasporto Edge, vengono utilizzati due processori dual core a 64 bit e otto gigabyte di memoria. Sei di questi server, il cui carico di lavoro è stato bilanciato attraverso in due datacenter, sono sufficienti per sostenere picchi di inoltro messaggi come avviene durante attacchi di virus in Internet".

Laboratorio per i test di Trasporto Edge
Installazione del laboratorio per i test
Poiché è consigliabile utilizzare nomi di dominio e indirizzi IP privati non esistenti, decidiamo di utilizzare AdventureWorks.com e gli indirizzi IP negli intervalli 192.168.xxx.0-24. Non sono presenti sistemi ridondanti o array di firewall perché non sto eseguendo il test del bilanciamento del carico o della tolleranza di errore. Ovviamente, per motivi di sicurezza, non è possibile discutere degli attuali sistemi firewall utilizzati da Microsoft IT. Questi dettagli non sono importanti per questo ambiente di test.
Nel mio ambiente di test utilizzo ISA Server 2006 perché è probabilmente uno dei sistemi firewall più comuni utilizzato con Exchange Server 2007. L'esecuzione di ISA Server 2006 su entrambi i firewall, interno ed esterno, consente di mantenere a un livello moderato la complessità dell'ambiente di test, sebbene per aumentare la protezione negli ambienti di produzione consiglio l'uso di diversi sistemi firewall esterni e interni. Poiché questi aggiornamenti non rientrano nell'ambito di questo articolo, non sono stati distribuiti i criteri IP Security (IPSEC) e non è stato preparato l'ambiente per Transport Layer Security (TLS).
Tuttavia, ho utilizzato le macchine virtuali e un software di valutazione a 32 bit, che è possibile scaricare dal sito Web di Microsoft. Microsoft non supporta la versione a 32 bit di Exchange Server 2007 in fase di produzione, ma questo non rappresenta un problema in un ambiente di test.
Dove possibile, il laboratorio per i test si basa sulle impostazioni predefinite. Soltanto la configurazione IP, i firewall e le aree DNS richiedono particolare attenzione prima di eseguire Exchange Server 2007 e sottoscrivere il server Trasporto Edge nell'ambiente di produzione. Per i dettagli relativi alla configurazione dell'indirizzo IP, fare riferimento, nel laboratorio per i test, al file IP Configuration.xls che si trova nel download complementare. Se si utilizzano le stesse assegnazioni dell'indirizzo IP, è possibile configurare rapidamente il firewall esterno, definito ISA01, eseguendo lo script ISA01_Firewall_Policies.vbs direttamente nel computer ISA01 e utilizzare ISA02_Firewall_Policies.vbs per il firewall interno (ISA02). Il download complementare contiene anche i file batch che consentono di configurare i server DNS (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat e AD02_DNS_Config.bat). Poiché questi file batch utilizzano lo strumento della riga di comando DNS (dnscmd.exe), è necessario che vengano installati gli strumenti di supporto di Windows, altrimenti, è necessario creare manualmente i record DNS utilizzando la console DNS.
Per evitare qualunque interferenza proveniente dagli ambienti esistenti, il mio laboratorio per i test non è connesso a Internet. Questo isolamento è una buona precauzione perché impedisce il download degli aggiornamenti della firma, della reputazione IP, nonché degli aggiornamenti del filtro contenuti, ma questo non è fondamentale per lo scopo dei nostri test. Per evitare i messaggi di errore, è necessario passare a Aggiornamenti utilità di analisi nella console amministratore di Forefront Server Security, quindi impostare la frequenza di aggiornamento per tutti i motori di scansione e specificare una data nel passato.

Per analizzare queste funzionalità in azione, è utile creare un ambiente di test. Il buon senso suggerisce di non utilizzare mai un sistema di produzione per eseguire un test. È necessario prima di tutto un server che esegue Exchange Server 2007 per i ruoli server Cassetta postale, Accesso client e Trasporto Hub ed è necessario un secondo server Exchange per il ruolo del server Trasporto Edge. È possibile ignorare l'installazione del server Trasporto Edge se vengono distribuiti tutti gli agenti di trasporto sul server con più ruoli eseguendo lo script Install-AntispamAgents.ps1 (disponibile sui server Trasporto Hub nella cartella %ProgramFiles%\Microsoft\Exchange Server\Scripts). Questo approccio, però, non assomiglia affatto alla distribuzione di Microsoft IT. Un laboratorio per i test realistico deve ricorrere a più server. Nella Figura 2 viene illustrato l'ambiente di test utilizzato per la ricerca di questo articolo. Un'illustrazione più dettagliata è disponibile nel download complementare. Per ulteriori informazioni sull'impostazione del laboratorio, vedere la barra laterale "Installazione del laboratorio per i test".
Figura 2 Ambiente di test di Trasporto Edge
Figura 2 Ambiente di test di Trasporto Edge
Durante la sottoscrizione del server Trasporto Edge e la configurazione dei connettori associati, Microsoft IT rimuove tutti i connettori predefiniti e procede poi alla creazione di quattro connettori di invio per comunicare in modo efficiente con diversi tipi di host SMTP (Simple Mail Transfer Protocol) e server Trasporto Hub interni. Il primo connettore di invio è un connettore Internet generale per tutte le destinazioni che non corrispondono a specifiche definizioni dello spazio degli indirizzi.
Il secondo connettore di invio è un connettore Internet con le definizioni dettagliate di spazio degli indirizzi per le destinazioni conosciute che non supportano SMTP estesi (domini HELO). Impostando il parametro ForceHELO per questo connettore su $true, durante le connessioni SMTP Microsoft IT evita una sequenza inutile di EHLO, Failure Response 500.
Il terzo è un connettore Internet con le definizioni dettagliate di spazio degli indirizzi per i partner e altri domini remoti che supportano TLS per comunicare in maniera sicura durante le connessioni crittografate (domini TLS). Questo connettore prevede che il parametro RequireTLS sia impostato su $true.
Il quarto connettore di invio è un connettore in ingresso che consente di trasferire i messaggi ricevuti via Internet ai server Trasporto Hub nell'ambiente aziendale. Ancora, per ulteriori dettagli relativi alla configurazione del server Trasporto Edge, vedere il white paper IT Showcase della barra laterale "Risorse di Exchange" alla fine di questo articolo.
Per applicare una topologia del connettore di tipo Microsoft IT al laboratorio per i test, ho seguito una procedura basata sugli script creata da Omesh per uso interno da parte di Microsoft IT. Per motivi legati alla protezione, ho modificato e accorciato drasticamente i singoli comandi, ma la topologia del connettore risultante corrisponde ancora alla topologia di Microsoft IT. Di seguito viene riportata la procedura:
  1. Sul server Exchange con più ruoli (HUB-MBX-01) e il server Trasporto Edge (EDGE01), rimuovere i connettori predefiniti.
  2. In HUB-MBX-01, creare un nuovo connettore di ricezione eseguendo lo script HUB-MBX-01_recv_connector.ps1, disponibile nel download di questo articolo.
  3. Su EDGE01, creare due nuovi connettori di ricezione per la connettività di messaggistica interna ed esterna eseguendo lo script EDGE01_recv_connector.ps1.
  4. Su EDGE01, creare un file di sottoscrizione utilizzando il seguente comando:
    New-EdgeSubscription -FileName
    "c:\subscriptionfile.xml"
In seguito, copiare il file di sottoscrizione risultante nella cartella principale del server Trasporto Hub (c:\subscriptionfile.xml).
5. Su HUB-MBX-01, verificare che il percorso del file di sottoscrizione sia c:\subscriptionfile.xml, quindi eseguire lo script HUB-MBX-01_complete_subscription.ps1. Questo script importa il file di sottoscrizione per la Sincronizzazione Edge senza la creazione automatica di un connettore di invio, crea i connettori di invio per Internet e la connettività interna e replica la configurazione risultante al server Trasporto Edge tramite la Sincronizzazione Edge.
6. Verificare la configurazione inviando messaggi di test come Contoso.User@contoso.com e Fabrikam.User@fabrikam.com dall'host Internet a Administrator@adventureworks.com e rispondendo ai messaggi ricevuti per verificare il funzionamento del trasferimento dei messaggi in ingresso e in uscita.
Suggerisco di aprire i singoli file di script nel Blocco note e di analizzare i cmdlet e i parametri utilizzati da questi script per eseguire la configurazione. Informazioni dettagliate su questi cmdlet e parametri sono disponibili in linea nella documentazione del prodotto per Exchange Server 2007.

Architettura Trasporto Edge
Adesso iniziamo a discutere sugli agenti Trasporto Edge che, da quando ho installato il ruolo del server Trasporto Edge, aspettano che qualcuno dica HELO o EHLO. Se eseguiamo il cmdlet Get-TransportAgent sul server Trasporto Edge, vengono visualizzate le 11 voci elencate nella Figura 3. Tutti gli agenti vengono attivati per impostazione predefinita per fornire la protezione di messaggistica con le impostazioni appropriate.
Figure 3 Agenti di trasporto (Close Figure 3)

Agenti di ricezione SMTP
Agente filtro di connessione
Agente di riscrittura indirizzi in ingresso
Agente del ruolo Edge
Agente filtro contenuto
Agente ID mittente
Agente filtro mittente
Agente filtro destinatario
Agente di analisi protocollo
Agente filtraggio allegati
Agenti di invio
Agente di riscrittura indirizzi in uscita.
Agente di invio FSE
Nel cmdlet Get-TransportAgent e nella Figura 3 vengono elencati gli agenti in base alla priorità, anche se questo non è l'ordine secondo cui gli agenti eseguono il proprio lavoro. L'ordine delle operazioni eseguite dipende principalmente dalla sequenza degli eventi di ricezione e di invio SMTP per cui vengono registrati gli agenti. Per vedere come sono combinati gli agenti e gli eventi, vedere il diagramma illustrato nella Figura 4, che mostra il modo in cui gli agenti di trasporto si integrano nell'architettura Trasporto Edge.
Figura 4 Agenti di trasporto nell'architettura Trasporto Edge
Figura 4 Agenti di trasporto nell'architettura Trasporto Edge
Gli eventi di trasporto si verificano in varie fasi durante l'elaborazione dei messaggi per richiamare il codice aggiuntivo per il filtro contro la posta indesiderata, la ricerca di virus e altre attività. In questo progetto collegato ed estensibile, il processo Trasporto Edge (EdgeTransport.exe) assume il ruolo di origine eventi. I gestori eventi, in altre parole gli agenti di trasporto, sono oggetti delegati gestiti basati su Microsoft® .NET Framework 2.0, registrati con l'origine eventi per ricevere le notifiche di richiamata.
Nella Figura 5 vengono illustrate le registrazioni evento per tutti gli agenti installati su un server Trasporto Edge con Forefront Security. Può risultare difficile ordinare queste registrazioni a causa dell'elevato numero di registrazioni di agenti, ma non è impossibile. Se si esegue il comando Get-TransportPipeline | Format-List sul server Trasporto Edge, è possibile analizzare opportunamente le registrazioni per ogni singolo evento di trasporto. È sufficiente verificare che il servizio Microsoft Exchange Transport (MSExchangeTransport.exe) sia in esecuzione e che dall'ultimo riavvio del servizio sia stato inviato almeno un messaggio tramite il server Trasporto Edge. Come indicato dall'output, è possibile che più agenti si registrino per lo stesso tipo di evento e che singoli agenti si registrino per più eventi. Le registrazioni evento dipendono dai requisiti di elaborazione dell'agente corrispondente.
Figura 5 Registrazioni evento per gli agenti di trasporto
Figura 5 Registrazioni evento per gli agenti di trasporto
Uno degli eventi più importanti è l'evento di invio OnSubmittedMessage, attivato quando un messaggio raggiunge la coda di invio. Tutti i messaggi devono passare attraverso questa coda se giungono tramite SMTP, il file system o qualunque altro meccanismo. Il classificatore è un componente principale dell'architettura di trasporto di Exchange Server, responsabile della risoluzione dei destinatari, della biforcazione e dell'invio dei messaggi, nonché della generazione della notifica sullo stato del recapito (DSN, Delivery Status Notification). L'evento OnSubmittedMessage risulta essere pertanto una scelta di registrazione ideale per gli agenti che devono elaborare tutti i messaggi ricevuti. L'agente di invio FSE è un componente di Forefront Security registrato affinché l'evento OnSubmittedMessage invii tutti i messaggi ricevuti ai motori di scansione antivirus. Poiché l'agente di invio FSE è registrato per l'evento OnSubmittedMessage, nessun messaggio può ignorare la soluzione antivirus.
Pertanto, per quale motivo tutti gli agenti non si registrano per l'evento OnSubmittedMessage e considerano terminate tutte le operazioni? Il motivo è che si desidera bloccare i messaggi indesiderati il prima possibile, prima che il server confermi l'avvenuto recapito. Altrimenti, i server potrebbero trovarsi a dover elaborare 90 milioni di messaggi indesiderati durante un attacco di posta indesiderata o virus, a generare 90 milioni di rapporti di mancato recapito (NDR) che potrebbero rappresentare un pericolo serio per gli utenti inconsapevoli. Gli attacchi di posta indesiderata e virus utilizzano quasi sempre informazioni falsificate sull'origine. L'invio di milioni di NDR ai destinatari che non hanno creato i messaggi originali non solo è uno spreco di risorse proprie e delle organizzazioni di destinazione, ma rappresenta anche un'opportunità per gli utenti malintenzionati di eseguire attacchi DDoS o attacchi che prevedono una vera inondazione della posta elettronica. Per proteggere se stessi e gli altri, è importante arrestare i mittenti dannosi.
Per bloccare un messaggio, è necessario che un agente di trasporto interrompa la conversazione SMTP con l'host remoto prima che il server confermi la ricezione dei dati con un codice di stato 250 OK. Secondo il principio di archiviazione e inoltro SMTP, in caso di mancata conferma dell'avvenuta ricezione del messaggio, il server può eliminare senza rischi tutti i dati ricevuti senza generare alcun NDR. Tale operazione può essere eseguita dagli agenti di ricezione SMTP. Questi interagiscono con la sessione SMTP perché il pipeline di trasporto li richiama in base agli eventi di ricezione SMTP nel momento in cui l'host remoto effettua la connessione al server, stabilisce una sessione SMTP, trasmette i verbi SMTP, inoltra i messaggi e termina la connessione. Gli eventi di ricezione SMTP associati a ogni passaggio sono elencati nella Figura 6. Grazie alla possibilità di rifiutare i messaggi prima della consegna e di scollegare gli host SMTP remoti, tutti gli agenti contro la posta indesiderata di Exchange Server 2007 vengono implementati come agenti di ricezione SMTP.
Figure 6 Eventi sessione SMTP (Close Figure 6)

Azione | Eventi correlati
Connetti al server | OnConnectEvent
Stabilisci una sessione SMTP | OnHeloCommand, OnEhloCommand, OnAuthCommand, OnEndOfAuthentication
Trasmetti i verbi SMTP | OnMailCommand, OnRcptCommand, OnDataCommand, OnNoopCommand, OnHelpCommand
Inoltra i messaggi | OnEndOfHeaders, OnEndOfData
Rifiuta il comando o il messaggio | OnReject
Ripristina connessione | OnRsetCommand
Termina connessione | OnDisconnect
È importante riconoscere la differenza tra gli agenti di invio e di ricezione SMTP, con particolare attenzione al relativo contesto di elaborazione. Nonostante gli agenti di invio abbiano accesso completo alle proprietà dei messaggi, gli agenti di ricezione SMTP sono più sensibili al contesto perché interagiscono con la sessione SMTP. Ad esempio, un filtro contro la posta indesiderata non può agire sulle proprietà dei messaggi fino a quando l'host remoto non ha trasferito effettivamente il messaggio. Pertanto, è importante registrare l'agente per l'evento di ricezione SMTP corretto. Per maggiori dettagli, vedere la barra laterale "Sviluppo dell'agente di trasporto".

Risorse di Exchange
  • Protezione della messaggistica e Trasporto Edge di Microsoft Exchange Server 2007 (White paper tecnico su Microsoft IT Showcase)
  • Script center di Windows PowerShell
  • Exchange Server 2007 TechCenter
  • Blog del team di Microsoft Exchange "You Had Me From EHLO"

Resta sintonizzato!
Facciamo una breve pausa prima di addentrarci negli scenari di architettura di trasporto e test. Finora ho affrontato molti argomenti, dalla distribuzione di tipo Microsoft IT dei server Trasporto Edge agli eventi interni attivati nel pipeline di trasporto durante l'elaborazione dei messaggi. Nella seconda parte di questa serie continuerò ad analizzare il comportamento degli agenti Trasporto Edge in alcuni scenari di test interessanti.
Nel frattempo, consiglio di scaricare la versione di prova di 90 giorni di Microsoft Visual Studio 2005 Professional Edition (go.microsoft.com/fwlink/?LinkId=98043) e seguire le spiegazioni di Steve per compilare e installare gli agenti di esempio nell'ambiente di test. Anche se non sei uno sviluppatore, scoprirai presto quanto è semplice eseguire queste attività. Non ci si dovrebbe meravigliare se aumentasse il numero di applicazioni aziendali che dipendono dagli agenti personalizzati, considerato quanto sia conveniente in Exchange Server 2007 sviluppare questi componenti con Visual Studio 2005.

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 di documentazione e localizzazione gestiti.


 SQL Server: Ottimizzazione delle prestazioni della CPU in SQL Server
SQL Server Zach Nichter

Ottimizzazione delle prestazioni della CPU in SQL Server
Panoramica:
  • Risoluzione dei problemi di prestazioni del database
  • Analisi delle cause hardware
  • Utilizzo di PerfMon per tenere traccia dei colli di bottiglia a livello di database
  • Valutazione delle prestazioni di esecuzione delle query

La risoluzione di problemi di prestazioni su un sistema di database può rivelarsi un'attività piuttosto complessa. Individuare il punto di origine di un problema è importante, ma ancora più cruciale è riuscire a capire le ragioni del comportamento del sistema a fronte di una specifica richiesta. Numerosi fattori possono influire sull'utilizzo della CPU
su un server di database: compilazione e ricompilazione di istruzioni SQL, indici mancanti, operazioni multithreading, colli di bottiglia a livello di disco e memoria, gestione di routine e, tra le altre cose, attività di estrazione, trasformazione e caricamento (ETL). L'utilizzo della CPU non costituisce di per sé un problema: eseguire operazioni rappresenta, d'altro canto, la funzione a cui la CPU è preposta. La chiave per un "sano" utilizzo della CPU consiste nel creare tutte le condizioni necessarie perché la CPU possa elaborare esclusivamente i processi specificati anziché sprecare cicli su codice scritto in modo approssimativo o hardware lento.

Due percorsi che si muovono verso uno stesso obiettivo
Da un punto di vista generale, esistono due percorsi che possono condurre all'identificazione dei problemi di prestazioni della CPU. Il primo prevede l'analisi delle prestazioni dell'hardware del sistema, un'operazione che consente di determinare dove cercare il problema quando si intraprende il secondo percorso, che consiste nell'analisi dell'efficienza delle query del server. Questo secondo percorso è in genere più efficace nell'identificazione dei problemi di prestazioni di SQL Server™. A meno che non si conosca con esattezza il punto di origine dei problemi di prestazioni delle query, tuttavia, è consigliabile iniziare sempre con una valutazione delle prestazioni del sistema. Alla fine, si finisce in genere con l'intraprendere entrambi i percorsi. A questo punto, è opportuno introdurre alcuni elementi di base necessari per esaminare entrambi i percorsi.

Concetti di base
Hyperthreading
La tecnologia hyperthreading è un argomento che merita un maggiore approfondimento data la notevole influenza che esercita su SQL Server. L'hyperthreading è una tecnologia grazie alla quale ciascun processore fisico viene visto dal sistema operativo come due processori logici. Questa tecnologia in sostanza sfrutta il tempo di elaborazione dei processori fisici in modo da consentire un pieno utilizzo di ciascun processore. Il sito Web Intel (intel.com/technology/platform-technology/hyper-threading/index.htm) fornisce una descrizione di gran lunga più dettagliata sulla modalità di funzionamento della tecnologia hyperthreading.
Sui sistemi SQL Server, il sistema di gestione di database (DBMS) mette a disposizione del sistema operativo le relative tecniche di accodamento e threading, estremamente efficienti e, pertanto, la tecnologia hyperthreading viene utilizzata solo per eseguire l'overload delle CPU fisiche sui sistemi in cui si registra già un utilizzo elevato della CPU. Quando SQL Server inserisce in coda più richieste di esecuzione delle operazioni su più utilità di pianificazione, il sistema operativo dovrà eseguire la commutazione del contesto dei thread sui processori fisici per soddisfare le richieste effettuate anche se i due processori logici si basano sullo stesso processore fisico. Se il valore del contatore Commutazioni di contesto/sec risulta superiore a 5000 per ciascun processore fisico, è consigliabile disattivare la tecnologia hyperthreading nel sistema e rieseguire il test delle prestazioni.
In rari casi, le applicazioni in SQL Server che presentano un utilizzo elevato della CPU possono utilizzare senza problemi la tecnologia hyperthreading. Prima di implementare le modifiche introdotte nei sistemi di produzione, testare sempre le applicazioni su SQL Server con la tecnologia hyperthreading sia attivata che disattivata.

Le prestazioni di un processore dual-core di fascia alta saranno di gran lunga superiori a quelle della RAM in un computer che, a sua volta, risulterà più veloce di un dispositivo di archiviazione collegato. Una CPU dalle prestazioni elevate è in grado di offrire una velocità effettiva di circa sei volte superiore a quella della memoria DDR2 di fascia alta corrente e di circa due volte superiore a quella della memoria DDR3 di fascia alta. La velocità effettiva della memoria tipica è di 10 volte superiore a quella delle più veloci unità Fiber Channel. Le unità disco, a loro volta, possono solo eseguire un numero finito di IOPS (operazioni di input/output al secondo), un valore completamente limitato dal numero di ricerche al secondo che un'unità è in grado di svolgere. In realtà, non accade in genere che venga utilizzata solo una singola unità di archiviazione per gestire tutte le esigenze di archiviazione sui sistemi di database aziendali. La maggior parte delle installazioni oggi prevede l'utilizzo delle reti SAN (Storage Area Network) sui server di database aziendali o gruppi RAID di maggiori dimensioni che sono in grado di impedire o ridurre al minimo i problemi relativi al processore di I/O del disco. L'aspetto più importante da tenere presente è che, indipendentemente dal tipo di installazione effettuato, i colli di bottiglia a livello del disco e della memoria possono influire sulle prestazioni dei processori.
A causa delle differenze di velocità delle operazioni di I/O, il recupero di dati dal disco risulta molto più dispendioso del recupero di dati dalla memoria. Una pagina di dati in SQL Server è 8 KB. Un extent in SQL Server è costituito da otto pagine di 8 KB, per un totale di 64 KB. È importante comprendere questo in quanto, quando SQL Server richiede il recupero di una specifica pagina di dati dal disco, in realtà non viene semplicemente recuperata la pagina di dati ma l'intero extent in cui risiede la pagina di dati. Esistono diversi motivi che spiegano i vantaggi derivanti dall'utilizzo di questo approccio per SQL Server; si tratta tuttavia di un argomento che esula dall'ambito del presente articolo. Il recupero di una pagina di dati già memorizzata nella cache dal pool di buffer, operando al massimo della velocità, dovrebbe richiedere meno di un millisecondo; il recupero di un singolo extent dal disco dovrebbe richiedere un intervallo di tempo compreso tra 2 e 4 millisecondi in un ambiente ottimale. Si prevede in genere che un'operazione di lettura di un sottosistema del disco integro e dalle prestazioni elevate richieda un periodo di tempo compreso tra 4 e 10 ms. La velocità di recupero di una pagina di dati dalla memoria è in genere 4-20 volte superiore a quella del recupero di una pagina di dati dal disco.
Quando SQL Server richiede una pagina di dati, controlla la cache del buffer in memoria prima di cercare la pagina di dati nel sottosistema del disco. Se la pagina di dati si trova nel pool di buffer, il processore recupererà i dati ed eseguirà le operazioni richieste. Questo comportamento è denominato errore di pagina software. Gli errori di pagina software sono ideali per SQL Server in quanto i dati recuperati come parte di una richiesta devono risiedere nella cache del buffer prima di poter essere utilizzati. Una pagina di dati che non risiede nella cache del buffer deve essere recuperata dal sottosistema del disco del server. Quando il sistema operativo deve recuperare la pagina di dati dal disco, questo comportamento è noto come errore di pagina hardware.
Quando si mettono in correlazione le prestazioni della memoria, le prestazioni del disco e le prestazioni della CPU, un denominatore comune consente di collocare il tutto nella giusta prospettiva: la velocità effettiva. In termini non propriamente scientifici, la velocità effettiva rappresenta la misurazione della quantità di dati che è possibile trasmettere attraverso una pipe con capacità limitata.

Percorso 1: prestazioni del sistema
Sono disponibili solo pochi metodi per determinare se su un server è presente un collo di bottiglia a livello di CPU e non esistono molte cause potenziali dell'utilizzo elevato della CPU. Alcuni di questi problemi possono essere rilevati tramite PerfMon o uno strumento di monitoraggio del sistema simile mentre altri vengono rilevati mediante SQL Profiler o strumenti simili. Un altro metodo consiste nell'utilizzare i comandi SQL tramite Analizzatore query o SQL Server Management Studio (SSMS).
La filosofia che utilizzo durante la valutazione delle prestazioni di un sistema prevede un procedimento che va dal generale al particolare. Ovviamente, è possibile focalizzare l'attenzione su determinate aree problematiche solo dopo averle identificate. Dopo aver valutato l'utilizzo globale della CPU con uno strumento come PerfMon, è possibile utilizzare tale strumento per esaminare un paio di contatori delle prestazioni molto semplici da utilizzare e di immediata comprensione.
Uno dei contatori delle prestazioni più noti è % Tempo processore; quando si utilizza PerfMon, questo contatore viene evidenziato non appena si apre la finestra Aggiungi contatori. % Tempo processore rappresenta la quantità di tempo impiegata dai processori nell'esecuzione delle operazioni. L'utilizzo delle risorse dei processori viene in genere considerato elevato quando questo valore è pari a 80% o superiore per la maggior parte del tempo in cui il sistema opera alla massima velocità. Accade che a volte si registrino picchi di utilizzo fino a 100% anche quando il server non opera a un tasso di utilizzo dell'80%.
Un altro contatore che è consigliabile esaminare è Lunghezza coda processore, disponibile nell'oggetto prestazione Sistema in PerfMon. Lunghezza coda processore indica il numero di thread in attesa di eseguire un'operazione sulla CPU. SQL Server gestisce le relative operazioni tramite le utilità di pianificazione nel motore di database, in cui vengono accodate ed elaborate le rispettive richieste. Poiché gestisce il relativo lavoro, SQL Server utilizza solo un singolo thread della CPU per ogni processore logico. Questo implica che ci dovrebbe essere un numero minimo di thread nella coda del processore in attesa di eseguire il lavoro su un sistema dedicato a SQL Server. In genere questo numero non dovrebbe essere di cinque volte superiore al numero di processori fisici su un sistema SQL Server dedicato, ma già un numero di due volte superiore può rivelarsi problematico. Sui server in cui DBMS condivide un sistema con altre applicazioni, è opportuno esaminare questo contatore insieme ai contatori delle prestazioni % Tempo processore e Commutazioni di contesto/sec (le commutazioni di contesto verranno trattate più avanti) per determinare se le altre applicazioni o il sistema DBMS deve essere spostato in un server differente.
In caso di accodamento del processore e di utilizzo elevato della CPU, esaminare i contatori Compilazioni SQL/sec e Ricompilazioni SQL/sec nell'oggetto prestazione SQLServer: Statistiche SQL (vedere la Figura 1). La compilazione e la ricompilazione dei piani di query contribuiscono all'utilizzo elevato della CPU di un sistema. Per le ricompilazioni si dovrebbero registrare valori vicino a zero; tuttavia è opportuno osservare le tendenze all'interno dei sistemi in uso per determinare il tipico comportamento del server e il numero di operazioni di compilazione che è normale eseguire. Le ricompilazioni non sempre possono essere evitate, ma è possibile ottimizzare le query e le stored procedure per ridurre al minimo le ricompilazioni e riutilizzare i piani di query. Confrontare questi valori con le istruzioni SQL effettive inserite nel sistema tramite il contatore Richieste batch/sec, disponibile nell'oggetto prestazione SQLServer: Statistiche SQL. Se le compilazioni e le ricompilazioni al secondo prevedono un'elevata percentuale delle richieste batch inoltrate al sistema, questa è un'area che è opportuno esaminare. In alcune situazioni gli sviluppatori SQL potrebbero non comprendere come o perché il relativo codice possa contribuire a generare questi tipi di problemi legati all'utilizzo eccessivo delle risorse del sistema. Più avanti in questo articolo verranno forniti alcuni riferimenti che potranno essere utili per ridurre al minimo questo tipo di attività.
Figura 1 Selezione dei contatori da monitorare
Figura 1 Selezione dei contatori da monitorare
Quando si utilizza PerfMon, esaminare il contatore delle prestazioni Commutazioni di contesto/sec (vedere la Figura 2). Questo contatore indica la frequenza con cui è necessario recuperare i thread dalle utilità di pianificazione del sistema operativo (non le utilità di pianificazione SQL) per eseguire le operazioni per altri thread in attesa. Le commutazioni di contesto sono in genere molto più frequenti sui sistemi di database condivisi con altre applicazioni come IIS o componenti di server applicazioni di altri fornitori. La soglia utilizzata per Commutazioni di contesto/sec è pari a circa 5000 volte il numero dei processori nel server. Questo valore può essere elevato anche sui sistemi con la tecnologia hyperthreading attivata e su cui si registra un utilizzo della CPU da moderato a elevato. Quando l'utilizzo della CPU e le commutazioni di contesto superano periodicamente le relative soglie, questo indica la presenza di un collo di bottiglia a livello della CPU. Se questo avviene a intervalli regolari, è consigliabile valutare l'opportunità di acquistare un numero maggiore di CPU o CPU più veloci se il sistema in uso è obsoleto. Per ulteriori informazioni, vedere l'intestazione laterale "Hyperthreading".
Figure 2 Contatori delle prestazioni da esaminare (Close Figure 2)

Contatore delle prestazioni | Oggetto contatore | Soglia | Note
% Tempo processore | Processore | > 80% | Le possibili cause sono: utilizzo eccessivo della memoria, basso riutilizzo dei piani di query, query non ottimizzate.
Commutazioni di contesto/sec | Sistema | > 5000 per ogni processore | Le possibili cause sono: installazione di altre applicazioni nel server, esecuzione di più istanze di SQL Server sullo stesso server, tecnologia hyperthreading attivata.
Lunghezza coda processore | Sistema | > 5 per ogni processore | Le possibili cause sono: installazione di altre applicazioni nel server, numero elevato di compilazioni o ricompilazioni, esecuzione di più istanze di SQL Server sullo stesso server.
Compilazioni SQL/sec | SQL Server:Statistiche SQL | Tendenza | Confrontare questo contatore con Richieste batch/sec.
Ricompilazioni SQL/sec | SQL Server:Statistiche SQL | Tendenza | Confrontare questo contatore con Richieste batch/sec.
Richieste batch/sec | SQL Server:Statistiche SQL | Tendenza | Confrontare questo contatore con Compilazioni SQL/sec e Ricompilazioni SQL/sec.
Permanenza presunta delle pagine | SQL Server:Gestione buffer | < 300 | Possibilità di un utilizzo eccessivo della memoria.
Scritture Lazywriter/sec | SQLServer:Gestione buffer | Tendenza | Possibilità di cancellazioni di dati di grandi dimensioni dalla cache o utilizzo eccessivo della memoria.
Pagine checkpoint/sec | SQLServer:Gestione buffer | Tendenza | Valutare i checkpoint in base ai contatori PLE e Scritture Lazywriter/sec.
Percentuale riscontri cache: Piani SQL | SQLServer:Cache dei piani | < 70% | Indica un riutilizzo ridotto dei piani.
Percentuale riscontri cache buffer | SQLServer:Gestione buffer | < 97% | Possibilità di un utilizzo eccessivo della memoria.
Il Lazywriter SQL Server (come definito in SQL Server 2000) o il monitor risorse (come definito in SQL Server 2005) è un'altra area da monitorare quando l'utilizzo della CPU è elevato. Lo svuotamento del buffer e delle cache delle procedure possono incremento il tempo di CPU tramite il thread delle risorse definito monitor risorse. Il monitor risorse è un processo di SQL Server che determina quali pagine conservare e quali pagine scaricare dal pool di buffer sul disco. A ogni pagina nel buffer e nelle cache delle procedure viene originariamente assegnato un valore di spazio che rappresenta le risorse utilizzate quando tale pagina viene memorizzata nella cache. Questo valore di spazio viene decrementato ogni volta che viene analizzato dal monitor risorse. Quando si richiede spazio della cache, le pagine vengono rimosse dalla memoria in base al valore di spazio associato a ciascuna pagina; le pagine con i valori più bassi vengono rimosse per prime. È possibile tenere traccia dell'attività del monitor risorse tramite il contatore delle prestazioni Scritture Lazywriter/sec nell'oggetto SQLServer: Gestione buffer in PerfMon. È consigliabile tenere traccia della tendenza con cui questo valore determina quale sia la soglia tipica nel sistema in uso. Questo contatore viene in genere esaminato insieme ai contatori Permanenza presunta delle pagine e Pagine checkpoint/sec per determinare se si è in presenza di un numero eccessivo di richieste di memoria.
Il contatore Permanenza presunta delle pagine (PLE, Page Life Expectancy) consente di determinare il numero di richieste di memoria. Il contatore PLE indica la durata della permanenza di una pagina di dati nella cache del buffer. 300 secondi rappresenta la soglia generalmente accettata per questo contatore. Qualsiasi valore inferiore a una media di 300 secondi per un periodo di tempo prolungato indica che le pagine di dati vengono rimosse dalla memoria con frequenza eccessiva. Quando questo si verifica, si determina un aumento significativo del carico di lavoro del monitor risorse che, a sua volta, forza l'utilizzo di un maggior numero di risorse dei processori. È opportuno valutare il contatore PLE insieme al contatore Pagine checkpoint/sec. Quando si verifica un checkpoint nel sistema, le pagine di dati danneggiate nella cache del buffer vengono scaricate sul disco, causando una diminuzione del valore PLE. Il processo monitor risorse rappresenta il meccanismo con cui queste pagine vengono scaricate su disco; pertanto durante i checkpoint è possibile che il valore del contatore Scritture Lazywriter/sec aumenti. Se il valore PLE aumenta immediatamente dopo il completamento di un checkpoint, è possibile ignorare questo sintomo temporaneo. D'altra parte, se si rileva che il valore è regolarmente inferiore alla soglia PLE, esiste un'alta probabilità che una quantità di memoria aggiuntiva possa risolvere i problemi e, allo stesso tempo, rilasciare alcune risorse a vantaggio della CPU. Tutti questi contatori sono disponibili nell'oggetto prestazione SQLServer: Gestione buffer.

Percorso 2: prestazioni delle query
Esecuzione della traccia con stored procedure
Quando si esegue la traccia dell'applicazione SQL Server, è opportuno acquisire familiarità con le stored procedure utilizzate per la traccia. L'utilizzo dell'interfaccia GUI (SQL Server Profiler) per la traccia può determinare un aumento del carico del sistema che va dal 15 al 25%. L'utilizzo di stored procedure durante la traccia potrebbe ridurre di circa la metà questo carico.
Quando si rileva la presenza di un collo di bottiglia nel sistema e si desidera determinare quali istruzioni SQL correnti siano all'origine dei problemi verificatisi sul server in uso, eseguire la query riportata di seguito. Questa query consente di visualizzare le singole istruzioni e le risorse da esse utilizzate nonché le istruzioni che devono essere esaminate per ottenere un miglioramento delle prestazioni. Per ulteriori informazioni sulle tracce SQL, visitare il sito Web all'indirizzo msdn2.microsoft.com/ms191006.aspx.
SELECT
    substring(text,qs.statement_start_offset/2
        ,(CASE
            WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2)
    ,qs.plan_generation_num as recompiles
    ,qs.execution_count as execution_count
    ,qs.total_elapsed_time - qs.total_worker_time as total_wait_time
    ,qs.total_worker_time as cpu_time
    ,qs.total_logical_reads as reads
    ,qs.total_logical_writes as writes
FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    LEFT JOIN sys.dm_exec_requests r
        ON qs.sql_handle = r.sql_handle
ORDER BY 3 DESC

Quando una nuova query viene inviata a SQL Server, i piani di query vengono valutati, ottimizzati, compilati e inseriti nella cache delle procedure. Ogni volta che una query viene inviata al server, la cache delle procedure viene esaminata per tentare di ottenere la corrispondenza tra un piano di query e una richiesta. Se non viene trovata alcuna corrispondenza, in SQL Server verrà creato un nuovo piano, un'operazione potenzialmente dispendiosa.
Di seguito sono riportate alcune considerazioni in relazione all'ottimizzazione della CPU T-SQL:
  • Riutilizzo del piano di query
  • Riduzione di compilazioni e ricompilazioni
  • Operazioni di ordinamento
  • Join non corretti
  • Indici mancanti
  • Scansione di tabelle/indici
  • Utilizzo di funzioni nelle clausole SELECT e WHERE
  • Operazioni multithreading
A questo punto è opportuno ricollocare il tutto nella giusta prospettiva. SQL Server in genere prevede l'estrazione di dati sia dalla memoria che dal disco ed è raro che si utilizzi solo una singola pagina di dati. Accade di frequente invece che più parti di un'applicazione utilizzino un record, eseguano più query di minori dimensioni o uniscano le tabelle in modo da fornire una visualizzazione completa dei dati rilevanti. Negli ambienti OLAP, le applicazioni potrebbero estrarre milioni di righe da una o due tabelle in modo che sia possibile consolidare, aggregare e riepilogare i dati per un report relativo alle vendite regionali. In situazioni di questo tipo, la restituzione dei dati può essere misurata in millisecondi se i dati sono in memoria, ma questi millisecondi possono trasformarsi in minuti quando gli stessi dati vengono recuperati dal disco anziché dalla RAM.
Il primo esempio è relativo a una situazione con un elevato volume di transazioni e in cui il riutilizzo dei piani dipende dall'applicazione. Un basso riutilizzo dei piani determina un numero elevato di compilazioni di istruzioni SQL che, a sua volta, mette a dura prova la capacità di elaborazione della CPU. Nel secondo esempio, l'utilizzo intensivo delle risorse di sistema può determinare un'eccessiva attività della CPU di un sistema, in quanto i dati esistenti devono essere costantemente eliminati dalla cache del buffer per risparmiare spazio per l'elevato volume delle nuove pagine di dati.
Si consideri un sistema che prevede un numero elevato di transazioni, in cui un'istruzione SQL come quella riportata di seguito viene eseguita 2000 volte in un periodo di 15 minuti per recuperare informazioni sull'imballo di spedizione. Senza il riutilizzo del piano di query si potrebbe registrare un tempo di esecuzione di circa 450 ms per ogni istruzione. Se lo stesso piano di query viene utilizzato dopo l'esecuzione iniziale, ogni query successiva potrebbe essere eseguita in circa 2 ms, determinando una riduzione del tempo totale di esecuzione di circa 5 secondi.
USE SHIPPING_DIST01;
SELECT
    Container_ID
    ,Carton_ID
    ,Product_ID
    ,ProductCount
    ,ModifiedDate
FROM Container.Carton
WHERE Carton_ID = 982350144;
Il riutilizzo del piano di query è fondamentale per ottenere prestazioni ottimali su sistemi con un numero elevato di transazioni e in genere v iene ottenuto parametrizzando le query o le stored procedure. Di seguito sono riportate alcune risorse preziose contenenti informazioni sul riutilizzo del piano di query:
  • Problemi di compilazione batch, ricompilazione e memorizzazione nella cache dei piani in SQL Server 2005 (microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
  • Ottimizzazione delle stored procedure di SQL Server per evitare le ricompilazioni (sql-server-performance.com/rd_optimizing_sp_recompiles.asp)
  • Ricompilazione di query in SQL Server 2000 (msdn2.microsoft.com/aa902682.aspx)
Una risorsa preziosa in cui è disponibile una quantità enorme di informazioni è rappresentata dalle viste a gestione dinamica (DMV) di SQL Server 2005. In caso di utilizzo elevato della CPU, è possibile utilizzare un paio di viste a gestione dinamica che consentono di determinare se la CPU viene utilizzata in modo appropriato.
Una di queste DMV è sys.dm_os_wait_stats, che viene utilizzata per fornire agli amministratori del database (DBA) un metodo per determinare ciascun tipo di risorsa o funzione utilizzata da SQL Server e di misurare la quantità di tempo in cui il sistema resta in attesa a causa di tale risorsa. I contatori in questa DMV sono cumulativi. Questo significa che per ottenere una vista chiara delle risorse che potrebbero influire su diverse aree del sistema, è necessario eseguire innanzitutto il comando DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) per reimpostare tutti i contatori dopo aver esaminato i dati relativi a tutti i problemi di particolare rilievo. La DMV sys.dm_os_wait_stats è l'equivalente del comando per il controllo della coerenza del database DBCC SQLPERF(WAITSTATS) in SQL Server 2000. Ulteriori informazioni sui diversi tipi di attesa sono disponibili nella documentazione in linea di SQL Server all'indirizzo msdn2.microsoft.com/ms179984.aspx.
È importante sapere che le attese sono normali in un sistema anche quando il sistema funziona in modo ottimale. È necessario semplicemente determinare se le attese sono interessate da un eventuale collo di bottiglia a livello della CPU. I tempi di attesa del segnale dovrebbero essere il più basso possibile in relazione al tempo di attesa totale. Il periodo di tempo in cui una specifica risorsa resta in attesa di una risorsa del processore può essere determinato semplicemente sottraendo il tempo di attesa del segnale dal tempo di attesa totale; questo valore non dovrebbe essere superiore di circa il 20% a quello del tempo di attesa totale.
La DMV sys.dm_exec_sessions indica tutte le sessioni aperte in SQL Server. Questa DMV fornisce una visualizzazione dettagliata delle prestazioni di ciascuna sessione e di tutte le operazioni eseguite da ciascuna sessione sin da quando è stata avviata. Le informazioni fornite in tale vista includono il tempo totale in cui la sessione è rimasta in attesa, l'utilizzo totale della CPU, l'utilizzo della memoria e un conteggio di letture e scritture. Nella DMV vengono forniti inoltre l'account di accesso, il tempo di accesso, il computer host e l'ultima volta in cui la sessione ha effettuato una richiesta in SQL Server.
L'utilizzo della DMV sys.dm_exec_sessions consente di determinare solo le sessioni attive; pertanto, nel caso in cui si rilevi un utilizzo elevato della CPU, questa DMV rappresenta una delle prime aree che è opportuno esaminare. Analizzare prima le sessioni con un conteggio elevato dei cicli di CPU. Determinare l'applicazione e l'utente che ha eseguito l'attività, quindi avviare un'analisi più particolareggiata. La combinazione delle DMV sys.dm_exec_sessions e sys.dm_exec_requests può fornire molte delle informazioni disponibili tramite le stored procedure sp_who e sp_who2. Se si utilizzano questi dati in combinazione con la funzione a gestione dinamica (DMF) sys.exec_sql_text attraverso la colonna sql_handle è possibile ottenere la query correntemente in esecuzione della sessione. Nel frammento nella Figura 3 viene illustrato come unire questi dati per determinare gli eventi correntemente eseguiti su un server.
Figure 3 Determinazione dell'attività del server (Close Figure 3)
SELECT es.session_id
    ,es.program_name
    ,es.login_name
    ,es.nt_user_name
    ,es.login_time
    ,es.host_name
    ,es.cpu_time
    ,es.total_scheduled_time
    ,es.total_elapsed_time
    ,es.memory_usage
    ,es.logical_reads
    ,es.reads
    ,es.writes
    ,st.text
FROM sys.dm_exec_sessions es
    LEFT JOIN sys.dm_exec_connections ec
        ON es.session_id = ec.session_id
    LEFT JOIN sys.dm_exec_requests er
        ON es.session_id = er.session_id
    OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st
WHERE es.session_id > 50    -- < 50 system sessions
ORDER BY es.cpu_time DESC
Ritengo che questa istruzione consente di determinare le applicazioni su cui è necessario concentrare l'attenzione. Quando si mettono a confronto CPU, memoria, letture, scritture e letture logiche per tutte le sessioni all'interno di un'applicazione e si determina che la percentuale di utilizzo delle risorse della CPU è molto più elevata rispetto a quella delle altre risorse utilizzate, è opportuno incentrare l'attenzione su queste istruzioni SQL.
Per tenere traccia delle istruzioni SQL per un'applicazione cronologicamente, utilizzare le tracce SQL Server. A tal fine, è possibile utilizzare lo strumento SQL Server Profiler o le stored procedure di sistema di traccia per determinare cosa accade nel sistema. Per ulteriori informazioni su questo argomento, vedere l'intestazione laterale "Esecuzione della traccia con stored procedure". È opportuno controllare SQL Profiler per verificare se siano presenti istruzioni con un elevato utilizzo della CPU oltre ad avvisi relativi a operazioni di ordinamento e hash, mancati riscontri nella cache e altri "red flag". Questo può consentire di focalizzare l'attenzione su specifiche istruzioni SQL o su uno specifico periodo di tempo che ha causato un utilizzo elevato delle risorse. SQL Profiler è in grado di tenere traccia di elementi come testo di istruzioni SQL, piani di esecuzione, utilizzo della CPU, utilizzo della memoria, letture logiche, scritture, memorizzazione nella cache di piani di query, ricompilazioni, rimozione di piani di query dalla cache, mancati riscontri nella cache, scansioni di tabelle e indici, statistiche mancanti e molti altri eventi.
Dopo aver raccolto i dati dalle stored procedure sp_trace o da SQL Server Profiler, è opportuno utilizzare un database, che viene compilato con i dati di traccia "a posteriori" o impostando la traccia per la scrittura nel database. La compilazione del database "a posteriori" può essere eseguita utilizzando la funzione di sistema di SQL Server fn_trace_getinfo. Il vantaggio di questo approccio è rappresentato dalla possibilità di eseguire una query e ordinare i dati in più modi per verificare quali istruzioni SQL hanno utilizzato il maggior numero di risorse della CPU o hanno eseguito il maggior numero di letture, calcolare il numero di ricompilazioni eseguite e molte altre attività. Di seguito viene riportato un esempio della modalità di utilizzo di questa funzione per caricare una tabella con un file di traccia di SQL Profiler. Per impostazione predefinita, tutti i file di traccia per tale traccia verranno caricati nell'ordine in cui sono stati creati:
SELECT * INTO trc_20070401
FROM fn_trace_gettable('S:\Mountpoints\TRC_20070401_1.trc', default);
GO

Conclusioni
Come si è osservato, un utilizzo elevato della CPU non indica necessariamente la presenza di un collo di bottiglia a livello della CPU. Un utilizzo elevato della CPU può mascherare anche numerosi altri colli di bottiglia a livello di applicazione o hardware. Una volta rilevato che si è in presenza di un utilizzo elevato della CPU nonostante gli altri contatori sembrino funzionare correttamente, è possibile iniziare a cercare la causa all'interno del sistema e individuare una soluzione (che potrebbe prevedere l'acquisto di CPU aggiuntive o l'ottimizzazione del codice SQL). Qualunque sia la scelta effettuata, è importante non rinunciare in partenza. I suggerimenti forniti in questo articolo, unitamente a un minimo di esercitazione e di ricerca, rendono l'ottimizzazione dell'utilizzo della CPU in SQL Server un obiettivo raggiungibile.

Zach Nichter è un professionista SQL Server con oltre 10 anni di esperienza. Ha ricoperto ruoli di supporto SQL Server diversi, tra cui amministratore del database (DBA), responsabile del team, manager e consulente. Attualmente Zach è architetto DBA presso Levi Strauss & Co. e si dedica in particolare a prestazioni, monitoraggio, architettura e altre attività strategiche di SQL Server. Zach è inoltre l'autore di un blog video disponibile all'indirizzo www.sqlcatch.com.


 Dal redattore: Il meglio deve ancora venire
Dal redattore
Il meglio deve ancora venire
Joshua Hoffman

Può sembrare incredibile, ma sto per iniziare la mia prima nota da redattore con un flashback. L'uso così precoce di questo genere di astuzie letterarie non depone bene per me, ma tant'é, ecco i miei ricordi.
Nell'estate del 2005, dopo il successo riscosso dai primi due numeri di TechNet Magazine, era ora di pianificare la produzione e iniziare a pubblicare periodicamente degli ottimi articoli tecnici dedicati ai professionisti dell'IT. Joshua Trupin, il nostro direttore esecutivo, e Stephen Toub (all'epoca direttore tecnico della pubblicazione consorella MSDN Magazine), avevano fatto un ottimo lavoro contattando gli esperti e pianificando i primi pochi numeri, ma avevano entrambi un lavoro "ufficiale" a cui dedicarsi.
Così sono entrato a far parte del team come nuovo direttore tecnico, onorato dalla fiducia che entrambi riponevano in me e reso umile dall'ottimo lavoro che avevano svolto fino a quel momento. La produzione di una rivista è un'opera tutt'altro che semplice. Provengo dal mondo dei professionisti IT (un vero appassionato) e i quattro anni precedenti li avevo trascorsi lavorando nei servizi di consulenza Microsoft. Avevo scarsa (o nessuna) conoscenza su come funziona il lavoro di redazione. Avevo un elenco lunghissimo di testi da leggere e consultare e c'erano tre numeri da iniziare subito a pianificare. Avevo nuovi compagni di lavoro, autori, revisori tecnici, partner commerciali e, ovviamente, lettori da conoscere. Soprattutto, avevo scadenze tipografiche impossibili da spostare (che, come è facile immaginare, è un concetto di difficile comprensione per un dipendente Microsoft di vecchia data).
Ma il team mi ha accolto, incoraggiato e assecondato, aiutandomi nell'impresa molto più di quanto fosse lecito aspettarsi. Gli autori, i revisori, i partner e i lettori hanno reso questo lavoro affascinante, avvincente e appagante e mi considero un privilegiato ad aver incontrato così tanti nuovi amici. Ricordo gli ultimi due anni con orgoglio per i risultati ottenuti dal team. Ma ora, nei panni del nuovo direttore, sono ancora più emozionato da ciò che riserva il futuro.
L'unico intento di questa rivista consiste nell'aiutare i professionisti IT di ottenere il migliori risultati possibili con i prodotti e le tecnologie Microsoft (credetemi; i nostri stipendi dipendono soprattutto da questo). Abbiamo ricevuto molti apprezzamenti e, ciò che più conta, suggerimenti per rendere più efficaci le aree migliorabili. I commenti e i suggerimenti rappresentano per noi una risorsa irrinunciabile. Nei prossimi mesi e anni continueremo a migliorare, aggiungendo nuovi autori e articoli, rendendo più efficace la piattaforma online con nuovi contenuti e supporti e, si spera, consentendo ai lettori di apprendere ciò che interessa nel modo che più si preferisce. Nessuno di questi obiettivi potrà essere tuttavia raggiunto senza il continuo apporto dei lettori. Fateci sapere cosa preferite e cosa non vi piace. A quali attività dovremmo dedicarci per migliorare la nostra pubblicazione? L'opinione dei lettori per noi è vincolante e speriamo che tutti vogliano approfittare di questa opportunità. Per esprimere un'opinione, è sufficiente inviare un messaggio di posta elettronica all'indirizzo tnmag@microsoft.com. Joshua Hoffman

Si ringraziano i seguenti esperti tecnici di Microsoft: Omesh Desai, Raja Ganjikunta, Saleem Hakani, Justin Hall, Michael Murgolo, John Orefice, Jim Truher, Marc Umeno, Jeff Wettlaufer, Buck Woody e Minxiao Zhou.


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

Linguaggio di script più potente
PowerShell Analyzer
www.pwershellanalyzer.com
Windows PowerShell™ sta riscuotendo enorme entusiasmo. E per una buona ragione. Se non si ha ancora avuto la possibilità di eseguire questo linguaggio di script di nuova generazione, vale la pena darvi un'occhiata. Gli utenti che hanno eseguito l'aggiornamento a Microsoft® Exchange 2007 capiranno immediatamente che la nuova Exchange Management Shell è basata su Windows PowerShell, consentendo di eseguire tutte le operazioni eseguibili da Exchange Management Console ma dalla riga di comando, un ottimo sistema per automatizzare attività ripetitive. Sfortunatamente, l'acquisizione della sintassi e della semantica di questo linguaggio richiede una certa curva di apprendimento. E qui entra in gioco PowerShell Analyzer, di ShellTools.
L'applicazione è in sostanza un IDE per la scrittura e il debug degli script di Windows PowerShell. Tuttavia, a differenza di un tradizionale ciclo di scrittura-compilazione-test, l'applicazione consente di comportarsi come un amministratore alla tastiera, interagendo in tempo reale con uno spazio di esecuzione di Windows PowerShell. PowerShell Analyzer consente di immettere i comandi una riga alla volta o creare, modificare ed eseguire gli script di Windows PowerShell in un editor nella parte inferiore dell'interfaccia utente. Entrambe le opzioni consentono il completamento del codice di base e sono pertanto di grande supporto nell'assistere i professionisti IT a districarsi tra i numerosi parametri dei cmdlet. Nel caso in cui non si abbia ancora familiarità con Windows PowerShell, con il termine cmdlet si fa riferimento a comandi astratti, parametrizzati e basati sulle attività.
Per ulteriori informazioni in merito, PowerShell Analyzer fornisce una scheda facilmente accessibile contenente descrizioni dettagliate, sintassi, spiegazione di parametri ed esempi relativi a ciascun cmdlet. Sono inoltre presenti riferimenti per i fornitori di Windows PowerShell, i file della Guida incorporati disponibili e gli alias più brevi dei cmdlet.
Quando si eseguono comandi da Windows PowerShell, vengono in effetti restituiti gli oggetti di Microsoft .NET Framework anziché semplicemente i risultati in formato testo visualizzati sullo schermo. PowerShell Analyzer consente di acquisire le proprietà dei risultati restituiti e passarle a una serie di "visualizzatori". Questi visualizzatori consentono di interagire con gli oggetti, offrendo ad esempio un'esplorazione ad albero dei dati XML o una visualizzazione tabulare gerarchica, ordinabile e raggruppabile dei dati, nonché di generare una serie di grafici differenti per rappresentare graficamente il set di dati restituito. Naturalmente, non tutte queste opzioni sono disponibili per ogni comando o script eseguito ma, quando applicabile, offrono un interessante set di rappresentazioni dei dati che è possibile salvare o esportare per un riutilizzo futuro.
PowerShell Analyzer consente inoltre di utilizzare più spazi di esecuzione contemporaneamente, offrendo la possibilità di passare da un'attività all'altra. Nella finestra dell'editor sono presenti strumenti per la definizione della struttura del codice e stili personalizzabili per l'evidenziazione del codice che consentono di conferire maggiore leggibilità agli script.
Nel complesso, se si intende utilizzare Windows PowerShell, uno strumento come PowerShell Analyzer consentirà di semplificare la creazione, la modifica e il debug degli script nonché la visualizzazione dei dati.

Prezzo: 129 dollari per licenza di un singolo utente.
Figure powershell

Deframmentazione di dischi
Auslogics Disk Defrag
www.auslogics.com/disk-defrag
Più intensivo è l'utilizzo dell'unità disco, maggiori saranno le possibilità che i file contenuti in tale unità risultino frammentati. Operazioni quali la creazione e l'eliminazione dei file, l'installazione e la rimozione delle applicazioni e persino la generazione di file e cache del disco temporanei possono contribuire tutte alla frammentazione. La percentuale di frammentazione può aumentare in modo significativo quando la quantità di spazio libero sull'unità è limitata, in quanto nuovi file verranno distribuiti negli spazi disponibili all'interno di un'area quasi completamente piena. Tutta questa frammentazione determinerà un rallentamento delle prestazioni del sistema.
Tutti naturalmente sanno che le versioni correnti di Windows® forniscono diversi strumenti di deframmentazione incorporati. Tuttavia, se si cerca uno strumento dedicato o se di recente si è eseguito l'aggiornamento a Windows Vista ® e non si è assistito alla presentazione dei controlli e dell'interfaccia utente offerta dalle versioni precedenti dello strumento di deframmentazione, è disponibile un'alternativa molto interessante che è consigliabile provare: Disk Defrag, di Auslogics.
Disk Defrag supporta Windows XP, Windows 2000, Windows Server® 2003 e Windows Vista e, come probabilmente ci si aspetta, è in grado di deframmentare i volumi FAT16, FAT32 e NTFS. L'applicazione è leggera e l'installazione richiede solo pochi clic del mouse.
L'esecuzione dell'applicazione è altrettanto semplice. È sufficiente selezionare l'unità che si desidera deframmentare e fare clic su Next. Una volta completata l'esecuzione, in Disk Defrag viene fornita una rapida panoramica dei risultati, mostrando il numero totale dei file, delle directory, dei file frammentati, dei file deframmentati e dei file ignorati nonché la diminuzione in percentuale della frammentazione. Se si desidera, è possibile inoltre fare clic sul pulsante Display Report di Disk Defrag in modo che l'applicazione generi una versione HTML del report di deframmentazione. In questo report vengono fornite ulteriori informazioni utili riguardanti il disco, come un elenco dei file ignorati con il relativo percorso, il numero di frammenti, il tempo trascorso per l'esecuzione e informazioni sul cluster del disco.

Prezzo:gratuito.
Disk Defrag è facile da installare e utilizzare
Disk Defrag è facile da installare e utilizzare

Trasferimento di file
FileZilla
filezilla.sourceforge.net
Non c'è niente di meglio che disporre di un buon client SFTP in grado di semplificare il proprio lavoro; questo vale in particolar modo quando il client è progettato in modo affidabile ed è disponibile gratuitamente, come nel caso del client FileZilla. FileZilla è un progetto open-source, ospitato in SourceForge.net, che è stato avviato da Tim Kosse e un paio di suoi collaboratori nel lontano 2001 per un progetto relativo a corsi di scienze informatiche. FileZilla può essere eseguito su tutte le versioni di Windows da Windows NT®4.0 a Windows Vista. Negli ultimi sei anni il progetto si è ampliato in modo significativo, ma Kosse è ancora il leader del progetto per l'applicazione.
Oltre alle connessioni FTP standard, il client supporta connessioni tramite SFTP con Secure Shell versione 2 (SSH2), FTP tramite TLS e FTP tramite SSL con crittografia implicita ed esplicita, offrendo pertanto la possibilità di connettersi a un'ampia gamma di server. FileZilla può ospitare firewall locali consentendo di limitare le porte locali utilizzate e di impostare uno specifico binding IP per i trasferimenti non passivi sia per IPv4 che per IPv6. Il client supporta inoltre una serie di configurazioni di proxy, tra cui i proxy SOCKS4/5, HTTP1.1 e FTP.
In termini di autenticazione server per le connessioni FTP, FileZilla supporta le normali configurazioni in forma anonima di nome utente/password e configurazioni basate sull'account. È inoltre possibile attivare il supporto per Kerberos Generic Security Services (GSS) (che richiede l'installazione nel sistema di Kerberos per Windows) e creare un elenco di server abilitati all'utilizzo di GSS. Ovviamente, prima di poter utilizzare GSS è necessario un ticket Kerberos v5 valido. È inoltre possibile attivare il supporto per il server Ident per la connessione ai server che lo richiedono come metodo per identificare il client.
FileZilla è in grado di gestire con facilità un'ampia gamma di siti FTP e consente di organizzare le connessione in una struttura ad albero. Per ogni connessione impostata, è inoltre possibile specificare directory locali e remote predefinite, impostare la porta a cui connettersi, scegliere di ignorare il proxy configurato, selezionare in modo esplicito le modalità di trasferimento attivo o passivo e persino impostare un offset per il fuso orario del server. Oltre alle connessioni salvate, FileZilla dispone anche della funzionalità Quickconnect da utilizzare per i trasferimenti occasionali in modo che, per stabilire una connessione, sia sufficiente immettere semplicemente l'indirizzo, il nome utente, la password e la porta e fare clic su un pulsante. Una volta configurate tutte le impostazioni e le connessioni è possibile esportarle in formato XML per il backup o il riutilizzo su altri sistemi.
L'interfaccia utente dell'applicazione, che è simile all'interfaccia di Esplora risorse, consente di trascinare con facilità i file tra i sistemi locali e remoti. Per i trasferimenti dei file, è possibile specificare un'impostazione predefinita per la sovrascrittura dei file oltre a un'opzione che consente di limitare le velocità di download e caricamento in base a una serie predefinita di regole o utilizzando un limite di velocità Kbs costante. Per impostazione predefinita, FileZilla è configurato per l'utilizzo dei trasferimenti di file compressi in modalità MODE Z sui server che supportano questa capacità, ma è possibile modificare il livello di compressione o disattivare la funzionalità. Il client dispone inoltre della funzionalità di accodamento dei trasferimenti che consente di inserire in una coda un gruppo di file da trasferire e importare ed esportare questo elenco di trasferimenti per il riutilizzo. Questo si rivela particolarmente utile per le attività di amministrazione del sistema ripetitive.

Prezzo:gratuito.

Modifica degli eseguibili
PE Explorer
www.heaventools.com
Per tutti coloro che desiderano addentrarsi negli aspetti più specifici delle applicazioni, è opportuno provare PE Explorer di HeavenTools. Questa applicazione consente di esaminare in modo approfondito i meccanismi interni dei file PE (Portable Executable) che vengono utilizzati per i binari eseguibili per le applicazioni Windows. In poche parole, PE Explorer fornisce un'interfaccia utente per l'esplorazione e la modifica del contenuto di questi eseguibili. PE Explorer è in grado di aprire diversi tipi di file, da quelli più comuni, come EXE e DLL, a quelli meno familiari, come i file DPL e CPL.
Quando si decide di esplorare per la prima volta un eseguibile, PE Explorer visualizza le informazioni sulle intestazioni del file, come il numero delle sezioni del codice, le dimensioni dell'immagine, il sottosistema dell'applicazione e le dimensioni dello stack. In un'altra visualizzazione viene fornita una panoramica delle intestazioni delle sezioni dell'eseguibile: facendo doppio clic sull'intestazione di una sezione viene visualizzata una finestra che consente di esplorare il contenuto di ciascuna sezione.
L'applicazione consente di estrarre, ricalcolare ed eliminare le sezioni del file PE caricato, operazioni indubbiamente non semplici. Uno strumento ottimale per il rilevamento di virus, malware e altri eseguibili dannosi, è possibile utilizzare la finestra Digital Signature Viewer dell'applicazione per esaminare e convalidare la firma digitale Microsoft Authenticode, se presente, nel file eseguibile caricato. Si tratta di un metodo molto efficace per verificare l'autore e l'integrità dell'eseguibile.
PE Explorer inoltre include una funzionalità di disassemblaggio rapido incorporata che consente di esaminare il codice assembly dell'eseguibile e supporta il comune set di istruzioni Intel x86 oltre ad estensioni come MMX, 3D Now! e SSE/2/3. Il disassemblatore è in grado inoltre di estrarre stringhe di testo ASCII dai dati del file PE in uso.
Un'altra funzionalità fornita è Dependency Scanner, che consente di analizzare tutti i moduli a cui il file PE è collegato in modo statico e i moduli caricati in modalità ritardata e di visualizzarli in una struttura ad albero gerarchica.
Una delle funzionalità più interessanti di PE Explorer è, secondo me, Resource Editor. Questa funzionalità consente di visualizzare, estrarre, sostituire, modificare ed eliminare le risorse di uno specifico eseguibile. L'interfaccia utente visualizza in modo simile a una struttura di directory le risorse incorporate, come immagini, suoni, finestre di dialogo, menu, dati XML, dati HTML e barre degli strumenti. Non tutte queste risorse supportano la modifica diretta ma per la maggior parte di esse è possibile eseguire la sostituzione e la modifica. Questo consentirebbe, ad esempio, di aggiungere le informazioni personalizzate del produttore OEM a un'applicazione, modificare i messaggi delle finestre di dialogo, personalizzare le azioni delle barre degli strumenti e così via, senza dover accedere al codice sorgente effettivo. PE Explorer è uno strumento molto utile per coloro che desiderano esplorare gli eseguibili. Se tuttavia Resource Editor è l'unica funzionalità che si desidera effettivamente utilizzare, è opportuno dare un'occhiata a Resource Tuner, un'applicazione molto più economica fornita dalla stessa azienda.

Prezzo: 129 dollari per una licenza personale; 199 dollari per una licenza commerciale.
Figure peexplorer

Recensione
Endpoint Security
www.awprofessional.com
L'aggiunta di un perimetro di rete tradizionale estremamente solido all'infrastruttura interna è un passo importante nell'ambito della protezione delle risorse aziendali. Questa misura presenta tuttavia alcuni limiti specifici. L'accresciuto livello di mobilità e connettività dell'hardware e del software attuali elimina la necessità di un reale perimetro a protezione dell'infrastruttura aziendale: l'infrastruttura, al contrario, si estende fino agli endpoint più remoti. Infatti, nonostante la maggiore propensione degli utenti a implementare misure di protezione contro attacchi provenienti dall'esterno dell'ambiente in cui si opera, vi sono maggiori probabilità che un attacco venga sferrato in modo accidentale da un utente che porta il proprio computer portatile da casa in ufficio e si connette alla rete aziendale non protetta.
Se si desidera ottenere rapidamente le conoscenze necessarie su come implementare opportuni controlli sull'accesso alla rete e proteggere gli endpoint della propria infrastruttura, è consigliabile consultare il libro di Mark Kadrich, Endpoint Security (Addison-Wesley Professional, 2007). Il libro inizia fornendo una definizione esatta degli endpoint e successivamente offre un esempio delle diverse variazioni esistenti: client Windows, client Linux, dispositivi incorporati, telefoni cellulari e PDA. Kadrich considera la rete come un "problema di controllo". Rifiutando la rappresentazione tipica di una rete complessa basata sull'analogia organica, egli descrive invece la rete come qualcosa che può essere delineato e visualizzato in modo utile e gestibile.
Il libro esamina i principi fondamentali del controllo dell'accesso alla rete (NAC, Network Access Control), stabilendo un livello di attendibilità di base. Questa discussione contiene informazioni su come realizzare una soluzione sicura per i sistemi endpoint proteggendo e controllando il software del codice sorgente e l'ambiente di generazione. Una panoramica degli strumenti che possono garantire la protezione e l'affidabilità degli endpoint copre argomenti noti, come l'utilizzo di un firewall o un software antivirus, e mette in rilievo la necessità di una gestione proattiva delle patch nonché dell'utilizzo di strumenti più avanzati, come sistemi per la prevenzione e il rilevamento delle intrusioni, sistemi di controllo dell'integrità degli host e la crittografia.
Nella seconda parte del libro vengono esplorati gli aspetti più specifici della protezione dei sistemi operativi di vari tipi di client, come Microsoft Windows, Apple OS X e Linux. In ogni capitolo viene fornita una panoramica su come eseguire un controllo di integrità iniziale per il sistema endpoint. In alcuni capitoli, dedicati ai PDA, agli smartphone e ai dispositivi incorporati, viene illustrato come questi dispositivi siano diventati una seria minaccia per l'infrastruttura e vengono fornite informazioni su come proteggere i diversi tipi di comunicazione.
Infine, Kadrich esamina quattro casi di studio e identifica in ciascuno la modalità in cui gli endpoint sono stati compromessi e il modo in cui la portata di questo rischio avrebbe potuto essere ridotta. Nel complesso, Endpoint Security fornisce informazioni molto utili per i professionisti che operano nell'ambito della protezione e rappresenta un punto di vista indipendente dai fornitori su come proteggere la rete dal perimetro di un endpoint.

Prezzo: 54,99 dollari di listino.

Greg Steen è un professionista IT, un imprenditore e un appassionato costantemente alla ricerca di nuovi strumenti e riferimenti che aiutino a rendere più semplici le operazioni e lo sviluppo per i professionisti IT. Per inviare dei suggerimenti, è possibile contattarlo all'indirizzo tntools@microsoft.com


 SQL: domande e risposte: Trigger di accesso, deframmentazione dei file di dati e altro ancora
SQL: domande e risposte
Trigger di accesso, deframmentazione dei file di dati e altro ancora
A cura di Nancy Michell

Impostazione dell'account di servizio
Suggerimento: password più protette
Il motore SQL Server 2000 conserva due copie di ogni password di accesso di SQL Server. Una versione è la password effettiva fornita dall'utente, l'altra è la password in lettere maiuscole.
Questa pratica è utile nella convalida senza distinzione tra caratteri maiuscoli e minuscoli delle password perché un utente può accedere al server utilizzando sia entrambi i caratteri che esclusivamente i caratteri maiuscoli. Tuttavia, questa facilitazione comporta un problema. Il salvataggio delle password costituite esclusivamente da caratteri maiuscoli aumenta la vulnerabilità verso attacchi a forza bruta per individuare la password poiché riduce il numero di password possibili.
SQL Server 2005 memorizza solo la copia originale della password. La password inserita da un utente deve corrispondere alla password memorizzata sul server. Se la password non corrisponde, all'utente viene negato l'accesso. Nel caso venisse dimenticato l'ordine preciso dei caratteri maiuscoli e minuscoli della password, sarà necessario reimpostarla.
Se si utilizza il nome di accesso utente SQLCOMMUNITY, è possibile reimpostare la relativa password SQL Server tramite il seguente comando:
Use Master;
ALTER LOGIN SQLCOMMUNITY WITH PASSWORD = 'k3t9h4s8wJF7t';
Questo comando reimposta la password per l'accesso a SQL Server di SQLCOMMUNITY su "k3t9h4s8wJF7t".

D In SQL Server™ 2000, impostavo l'account di servizio per l'agente e il motore di SQL Server tramite l'applet Servizi in Strumenti di amministrazione. Ho sentito che adesso in SQL Server 2005 è necessario utilizzare lo strumento Gestione configurazione. Perché non posso continuare a utilizzare gli strumenti di Windows?
R SQL Server 2005 è stato creato in modo da essere più sicuro rispetto alle versioni precedenti. In molti negozi, gli utenti imposterebbero esclusivamente account interni, come LocalSystem, per eseguire SQL Server. Tali account, però, dispongono spesso di un numero di diritti e autorizzazioni in Windows® maggiore o minore di quanto richiesto. È necessario creare un account Windows senza privilegi elevati per eseguire i servizi dell'agente e del motore di SQL Server 2005. Se si selezionano questi account con Configuration Manager, verranno automaticamente concessi loro i diritti e le autorizzazioni appropriati sia in SQL Server che nel sistema operativo. Se vengono utilizzati gli strumenti di Windows per gestire i servizi di SQL Server, potrebbero non essere concessi i diritti appropriati o ne potrebbero essere concessi troppi.
Per ulteriori informazioni, vedere il suggerimento relativo alla modifica dell'account di servizio.

Accesso al server personale
D Desidero sapere chi accede al mio server e quando. Vorrei anche limitare alcuni utenti specifici a determinati periodi di tempo e sapere come tenere traccia dell'attività degli utenti. È possibile?
R Sì, è possibile fare tutto questo con SQL Server 2005 se si dispone di Service Pack 2 installato.
SQL Server 2005 consente di creare trigger di accesso che possono avviare un'istruzione T-SQL o una stored procedure in risposta a un evento LOGON. È possibile utilizzare un trigger di accesso per controllare gli utenti tenendo traccia dell'attività di accesso, limitando gli accessi a SQL Server o limitando il numero di sessioni per accessi specifici. Si noti che l'evento viene avviato solo dopo l'autenticazione di un accesso, ma prima che la sessione dell'utente venga effettivamente stabilita. Di conseguenza, tutti i messaggi che hanno origine dall'interno del trigger (come i messaggi o gli errori) dall'istruzione PRINT vengono inviati al log degli errori di SQL Server. Se l'autenticazione di un accesso non riesce, i trigger di accesso non vengono avviati.
Il seguente esempio mostra come creare un trigger di accesso e inviare un messaggio al log degli errori di SQL Server ad ogni accesso utente:
ALTER TRIGGER Ops_Login
ON ALL SERVER
AFTER LOGIN
AS
PRINT SUSER_SNAME() + ' has just logged in to ' + LTRIM(@@ServerName) + ' SQL Server at '+LTRIM(getdate())
GO
Per visualizzare tutti i trigger impostati al livello del server, utilizzare le query seguenti:
SELECT * FROM sys.server_triggers;

Procedure consigliate di deframmentazione
D Qual è il modo migliore per risolvere la frammentazione dei file di dati in SQL Server? Se si utilizzano gli strumenti di deframmentazione in Windows, essi considerano i file di dati di SQL nel suo insieme e non ne eseguiranno la deframmentazione in modo granulare.
R È possibile eseguire il backup del database e quindi ripristinarlo. Se esiste lo spazio per un file contiguo, quest'ultimo deve essere scritto nel database subito dopo l'ultimo file. Detto questo, non è necessario tentare di deframmentare i file fisici. In genere, comunque, non si verifica molta frammentazione esterna. È più utile reindirizzare regolarmente i dati per ridurre il più possibile la frammentazione interna. Ciò consentirà di ottimizzare l'efficacia delle letture in avanti e la quantità di dati che possono essere memorizzati nel buffer.
I fattori più importanti per efficaci operazioni I/O del disco assicurano che l'allineamento del disco e la configurazione del RAID siano corretti, scalando gli array del disco per gestire in modo appropriato il carico I/O e mantenendo un layout appropriato di Log, Data, TempDB e file di backup. Evitando di utilizzare le funzioni di aumento delle dimensioni e di compattazione automatica come metodo principale per il ridimensionamento dei file di dati, verrà ridotto il numero di frammentazioni del file create al livello del volume. Ad esempio, l'esecuzione di 10 operazioni di aumento delle dimensioni, ognuna di 500 MB, probabilmente aggiunge 10 nuove frammentazioni del file fisico. Contrariamente, una singola operazione di aumento delle dimensioni manuale di 5 GB ne aggiungerà solo una.

Suggerimento: modifica dell'account di servizio
Quando l'account di accesso di servizio di SQL Server viene configurato con un account Windows NT®, SQL Server imposta i diritti e le autorizzazioni dell'utente di Windows su diversi file, cartelle e chiavi del Registro di sistema. È anche possibile impostare l'account di servizio di SQL Server dalla console dei servizi in Strumenti di amministrazione. Tuttavia, quando si esegue questa operazione tramite i servizi, i diritti e le autorizzazioni non vengono impostate e potrebbero verificarsi seri problemi dovuti alla mancanza di impostazioni di protezione appropriate sugli elementi Windows e SQL Server citati in precedenza.
Quindi, si consiglia di utilizzare la funzionalità di gestione della configurazione di SQL Server piuttosto che la console dei servizi per la modifica dell'account di servizio dell'agente di SQL Server o SQL Server. Tuttavia, se sono già state effettuate modifiche sull'account utilizzando la console dei servizi, è ancora possibile risolvere questo problema.
Passaggio 1: Applicare autorizzazioni complete sulle seguenti chiavi del Registro di sistema e relative sottochiavi:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>
Passaggio 2: Impostare il controllo completo per l'account di avvio per il servizio MSSQLServer e il servizio SQLServerAgent (un account Windows NT locale o un account Windows NT di dominio) su questa cartella NTFS:
Drive:\Program Files\Microsoft SQL Server\<MSSQL.1>\MSSQL
Invece di effettuare questa operazione manualmente, tuttavia, si consiglia di utilizzare la funzionalità di gestione della configurazione di SQL Server per effettuare modifiche sugli account di servizio dell'agente e di SQL Server.

Si ringraziano i seguenti professionisti IT di Microsoft per la propria esperienza tecnica: Cary Gottesman, Saleem Hakani, Trayce Jordan, Peter Kalbach, Al Noel, Uttam Parui, Amber Sitko e Buck Woody.


 Utilit&#224; in primo piano: Virtual Machine Remote Control Plus
Utilità in primo piano
Virtual Machine Remote Control Plus
Matthijs ten Seldam
Scarica il codice per questo articolo: UtilitySpotlight2007_10.exe (10163KB)

La virtualizzazione è attualmente un argomento di grande interesse. Molti professionisti IT utilizzano la virtualizzazione hardware negli scenari di apprendimento e testing. Considerato quanto appena detto, Microsoft ha rilasciato Virtual PC 2007, una soluzione di virtualizzazione software per le installazioni autonome con un numero limitato di macchine virtuali. Si noti che questo nuovo prodotto non intende sostituire Virtual Server
2005, che ha introdotto la virtualizzazione nel datacenter.
Microsoft® Virtual Server 2005 consente di virtualizzare molti carichi di lavoro server, ma, a differenza di Virtual PC, la sua interfaccia è un'applicazione Web. Sebbene la gestione basata su Web presenti numerosi vantaggi, per la gestione quotidiana molti utenti preferiscono un'interfaccia utente completa che funzioni allo stesso modo di un'applicazione Windows®.
Virtual Machine Remote Control Plus, in breve VMRCplus, è un'interfaccia alternativa di Virtual Server 2005. Poiché si tratta di un'applicazione Windows Forms, VMRCplus offre una semplice gestione di Virtual Server e delle relative macchine virtuali. Si noti che Virtual Server è dotato di uno strumento denominato Controllo remoto macchina virtuale che viene utilizzato per il controllo remoto delle macchine virtuali. Ma VMRCplus garantisce, con un'unica applicazione, sia la gestione della configurazione di Virtual Server che il controllo remoto delle macchine virtuali.

Virtual Machine Manager
La finestra principale di VMRCplus, Virtual Machine Manager, è illustrata nella Figura 1. In questo esempio, Virtual Machine Manager è collegata a localhost, con cinque macchine in esecuzione, tre in stato salvato e tutte le altre spente. Il sesto computer dell'elenco è selezionato e sono visualizzate alcune informazioni tra cui il sistema operativo guest, il carico CPU, le statistiche I/O di rete e disco oltre la versione di componenti aggiuntivi installati. L'elenco è ordinato per stato.
Figura 1 Virtual Machine Manager di VMRCplus
Figura 1 Virtual Machine Manager di VMRCplus
Grazie a Virtual Machine Manager, è possibile collegarsi agli host Virtual Server e visualizzare le macchine virtuali. Per passare da un host all'altro è possibile selezionare una scheda e collegarsi a un host dell'elenco a discesa presente nella barra degli strumenti oppure digitare il nome host o l'indirizzo IP. In caso di connessione riuscita, VMRCplus aggiunge il nome o l'indirizzo IP all'elenco.
Alcune proprietà degli host Virtual Server, ad esempio le informazioni su CPU e memoria, vengono visualizzate nella parte inferiore della finestra. Un misuratore della memoria fornisce una rapida visione della quantità di RAM disponibile per le macchine virtuali.

Gestione di Virtual Server
Nella finestra Virtual Machine Manager non è possibile solo visualizzare informazioni, ma anche configurare alcune impostazioni. Utilizzando l'opzione di menu View, è possibile impostare l'intervallo di aggiornamento utilizzato da VMRCplus per aggiornare l'elenco Virtual Machine. L'impostazione dell'attuale intervallo di aggiornamento viene visualizzato nell'angolo inferiore destro della finestra, come illustrato nella Figura 1.
Il menu Virtual Server consente di accedere alla configurazione di Virtual Server, alle impostazioni di Controllo remoto macchina virtuale, alla posizione predefinita delle nuove macchine virtuali, alle impostazioni di protezione e alle proprietà dei servizi. Nella pagina delle impostazioni di Controllo remoto macchina virtuale è possibile impostare le proprietà, disattivare il Controllo remoto macchina virtuale o tornare alle impostazioni predefinite di Virtual Server.
Nella pagina delle impostazioni di protezione è possibile specificare le autorizzazioni di Virtual Server. Per impostazione predefinita, il gruppo locale Administrators ha il pieno controllo di Virtual Server. È possibile specificare le autorizzazioni per gruppi o utenti. Se non si è membro del gruppo locale Administrators, è necessario prima di tutto aggiungere un gruppo o il proprio account e impostare le autorizzazioni necessarie. Non è necessario eseguire VMRCplus come amministratore, in quanto sono sufficienti i privilegi utente normali.
Le proprietà dell'host Virtual Server, tra cui le proprietà fisiche, sono illustrate nella Figura 2. Si noti che questo host supporta la virtualizzazione assistita da hardware, come risulta chiaro dalle funzionalità del processore.
Figura 2 Proprietà di Virtual Server
Figura 2 Proprietà di Virtual Server

Gestione di reti e dischi virtuali
VMRCplus dispone di altre utilità di gestione mirate alle funzionalità specifiche di Virtual Server. Il componente Virtual Disks Manager presenta un'interfaccia con schede che corrispondono ai diversi tipi di dischi fisici che è possibile creare, tra cui dischi rigidi (dinamici o fissi), dischi floppy e dischi differenze. È inoltre possibile analizzare i propri dischi virtuali.
Il componente Virtual Networks Manager consente di gestire le reti virtuali. È possibile aggiungere una rete virtuale da un file di configurazione rete virtuale (VNC) o crearne una nuova. Durante la creazione di una rete virtuale, è possibile aggiungere una scheda di rete o riservare la rete esclusivamente ai guest. Nella stessa finestra è possibile attivare un server DHCP e visualizzarne le impostazioni.

Gestione delle macchine virtuali
I precedenti componenti di gestione si rivolgono tutti a Virtual Server. Cosa offre VMRCplus per la creazione e configurazione di macchine virtuali?
La creazione di macchine virtuali è un'operazione abbastanza semplice: basta selezionare Virtual machine | Create dal menu. Nella finestra di dialogo aperta vengono visualizzate le impostazioni predefinite equivalenti a quelle di Virtual Server, ma con qualche differenza nell'interfaccia. Ad esempio, VMRCplus crea sempre due dischi rigidi virtuali e li aggiunge a SCSI. VMRCplus inoltre consente di creare più macchine virtuali contemporaneamente scegliendo l'opzione "Create multiple virtual machines", che consente di creare più macchine virtuali, e selezionando il numero di macchine desiderato. VMRCplus consente di aggiungere un trattino e un numero di sequenza al nome della macchina virtuale fornito.
Una funzionalità molto utile consente di creare più macchine virtuali da una macchina virtuale padre. Supponiamo di aver creato una macchina virtuale con gli ultimi componenti aggiuntivi, service pack, aggiornamenti rapidi e strumenti e volere utilizzarla come base per altre macchine virtuali. Presupponendo di aver eseguito sysprep come ultima operazione e di aver chiuso la macchina padre, è possibile creare più macchine virtuali che erediteranno le proprietà da quest'ultima.
In pochi secondi, è possibile creare molte macchine virtuali in base a questa macchina padre e avviarle dallo stesso riferimento. Al termine delle operazioni, ad esempio del testing, è possibile eliminarle. È facile: VMRCplus supporta la selezione multipla sull'elenco della macchina virtuale insieme all'ordinamento delle colonne. In questo modo è possibile selezionare più macchine e rimuoverle (deregistrandole semplicemente) oppure eliminarle (eliminando anche i file).
Sono disponibili altri comandi di selezione multipla che è possibile utilizzare sulle macchine virtuali, ad esempio la selezione multipla e l'avvio, la selezione multipla e l'apertura della console o la selezione multipla e il salvataggio dello stato. È possibile fare quanto appena detto utilizzando l'interfaccia utente o i tasti di scelta rapida.
Anche la configurazione di una macchina virtuale è semplice se si utilizza la pagina delle impostazioni hardware. È possibile impostare la quantità di memoria, aggiungere i controller SCSI, aggiungere dischi o immagini (trascinandoli) nonché attivare e configurare le schede di rete. Nella finestra delle proprietà avanzate è possibile configurare le impostazioni di configurazione più avanzate. Ad esempio, è possibile eseguire le macchine virtuali con un determinato account utente in modo da avviare automaticamente una macchina all'avvio di Virtual Server.

Controllo remoto
Infine, VMRCplus fornisce anche la finestra Console Manager, che contiene le sessioni di controllo remoto (sessioni VMRC) con le macchine virtuali. È possibile aprire una console scegliendo una o più macchine virtuali in esecuzione e facendo clic sul pulsante corrispondente alla console della macchina virtuale sulla barra degli strumenti delle proprietà.
La finestra Console Manager, illustrata nella Figura 3, supporta l'ordinamento a schede delle sessioni remote. È possibile passare da una macchina virtuale all'altra scegliendo la scheda corrispondente. È disponibile, inoltre, una barra degli strumenti contenente le funzioni più utilizzate.
Figura 3 Console Manager
Figura 3 Console Manager
Come si è visto, Console Manager dispone di menu di scelta rapida che consentono di aggiungere un'immagine floppy virtuale o ISO, montare unità host e installare componenti aggiuntivi. È disponibile anche una barra di stato che visualizza lo stato dei supporti CD/DVD e floppy, la versione dei componenti aggiuntivi correnti nella macchina virtuale, la chiave host attualmente attiva e l'impostazione di ridimensionamento dello schermo dinamico. VMRCplus consente di impostare la chiave host. È inoltre possibile accedere alle impostazioni hardware della macchina virtuale e alle proprietà avanzate.
VMRCplus fornisce altre semplici funzionalità. Ad esempio, è possibile catturare una schermata delle impostazioni della macchina virtuale e salvarla come file jpg, il che può essere utile per la risoluzione dei problemi. Inoltre, è possibile scegliere l'opzione "Send Text to Virtual Machine", che consente di inviare testo alla macchina virtuale, ad esempio combinazioni di tasti. Non si tratta di una funzione degli Appunti, ma è molto utile in situazioni in cui, ad esempio, è necessario copiare e incollare il tasto di un prodotto dall'host alla macchina virtuale.
VMRCplus è stato creato inizialmente da Paul Despe e doveva essere uno strumento per gli sviluppatori che gestivano funzioni di base ma comprendeva tutte le funzionalità di Virtual Server. Veniva utilizzato per il testing e presentava diversi inconvenienti. Circa un anno fa, ho riscritto il codice, estendendone le funzionalità. Da allora è diventato molto diffuso tra gli utenti di Virtual Server di Microsoft. Si noti, tuttavia, che VMRCplus non è un'applicazione Microsoft supportata. Viene fornito così com'è ed è soggetto alle condizioni di licenza software Microsoft previste.
VMRCplus è stato sviluppato per Virtual Server 2005 Service Pack 1. Sebbene le versioni precedenti possano essere compatibili, è stato testato solo con Service Pack 1. Gli utenti possono aggiornare i propri host Virtual Server a Service Pack 1 prima di utilizzarlo. VMRCplus è disponibile per il download nel sito Web TechNet Magazine all'indirizzo technetmagazine.com/code07.aspx.

Matthijs ten Seldam è Principal Consultant per i servizi di consulenza Microsoft. In particolare, si occupa di sicurezza, distribuzione e automazione ed è esperto di virtualizzazione.


 L'azienda IT: Calcolo del valore dell'infrastruttura IT nell'amministrazione pubblica
L'azienda IT
Calcolo del valore dell'infrastruttura IT nell'amministrazione pubblica
Acer Maamoun

Dimostrare i vantaggi di un investimento in infrastrutture IT, sia hardware che software, può essere difficile nelle amministrazioni pubbliche. Come in tutte le altre organizzazioni di grandi dimensioni, i manager devono produrre per qualsiasi tipo di aggiunta o miglioramento un business case che sarà valutato a fronte di tutte le altre richieste di finanziamento.
Poiché esistono molti modi diversi per inquadrare un business case, i manager dell'IT devono scegliere quello che meglio rappresenta la cultura specifica della propria organizzazione. Questo vale per le amministrazioni pubbliche come per le organizzazioni commerciali. L'allineamento dell'IT con le altre priorità aziendali è essenziale. Nel settore pubblico le organizzazioni IT riescono in genere a far valere i propri argomenti utilizzando il concetto di valore pubblico nell'approccio alla creazione di un portfolio di progetti e iniziative.
La creazione di un business case che dimostri in che modo un miglioramento dell'infrastruttura possa giovare alla produttività o alla qualità del servizio è un processo difficile. In questo articolo vengono illustrate alcune soluzioni per definire e misurare il valore degli investimenti in infrastrutture IT operati da reali organizzazioni di IT nella pubblica amministrazione.

Come giustificare gli investimenti
Un problema comune a molte organizzazioni IT è che queste ricevono troppe richieste relative alle aree di attività più diverse, tutte ovviamente della massima urgenza. Le iniziative nuove tendono a rispondere a requisiti normativi o priorità operative di singoli reparti. Tali iniziative potrebbero sembrare confuse e casuali, ma sono spesso strettamente allineate al valore pubblico perseguito da un determinato reparto.
D'altra parte, i costi operativi che vengono ripartiti in base all'utilizzo effettivo a supporto delle operazioni dei singoli reparti possono nascondere il costo (e il valore) delle funzioni diffuse nell'intera azienda o dei servizi condivisi. In questo ambiente può essere estremamente difficile valutare correttamente il valore degli investimenti per infrastrutture nuove o per il miglioramento dell'infrastruttura esistente che hanno un impatto sull'intera organizzazione o che rispondono indirettamente al raggiungimento degli obbiettivi dei singoli reparti.
Ne consegue che l'organizzazione IT nel suo complesso incontra spesso delle difficoltà nel supportare un punto di vista aziendale sull'IT come descritto dal GSA Federal Enterprise Architecture Framework (whitehouse.gov/omb/egov/a-1-fea.html). In uno scenario di questo tipo diventa difficile realizzare gli sforzi per adottare un punto di vista condiviso sull'architettura dell'organizzazione, un modello comune di business case e un processo di gestione del portfolio per collocare le richieste di investimento e spesa IT sullo stesso piano degli altri investimenti. Un modello più efficace consiste nel supportare un portfolio di attività IT che evidenzino al massimo i vantaggi del valore pubblico. È quindi necessario che i criteri comuni del valore pubblico vengano scelti e imposti nei processi di sviluppo del business case, di gestione del portfolio, di realizzazione dei vantaggi e di valutazione.

Misurazione del valore
I problemi reali da affrontare nel caso di investimenti IT che coinvolgono l'intera azienda sono molteplici. Prima di tutto, questo tipo di investimenti ha un impatto più indiretto e a lungo termine se valutato con il metro dei vantaggi in valore pubblico. Questi vantaggi vengono percepiti, spesso in modo diseguale, dalle diverse parti dell'organizzazione in modi che non sempre sono di facile e immediata identificazione. Inoltre, i rischi e i costi associati vengono percepiti in modo molto più immediato rispetto al valore pubblico, meno evidente e quantificabile.
Un business case deve quindi evidenziare come un investimento in infrastrutture IT può facilitare investimenti futuri e attività correnti. Tale valore può essere calcolato in diversi modi, ciascuno con dei vantaggi e delle limitazioni e ciascuno con un grado diverso di adattabilità a culture e livelli di maturità di una particolare organizzazione.
Modello matematico Questi metodi sono basati su un modello matematico dei vantaggi potenziali. Un metodo efficace, definito opzioni reali, è basato sulla teoria finanziaria e tiene conto dei cambiamenti futuri e della flessibilità necessaria, considerando esplicitamente il diritto di intraprendere un'azione (vale a dire, l'opzione reale) a un determinato costo per un dato periodo di tempo. Le opzioni comprendono il differimento, l'espansione, la messa in opera e l'abbandono degli investimenti, la modifica di input o output e i piloti di sviluppo.
Le opzioni reali sono particolarmente indicate quando una decisione di investimento è influenzata dagli eventi futuri. Nel caso di un'infrastruttura IT, tali eventi potrebbero essere i seguenti: requisiti normativi, richiesta commerciale o anche un evento critico come un grave problema operativo.
Simulazione L'analisi dell'incertezza è basata sulla simulazione di Monte Carlo, in cui si utilizzano degli strumenti automatici per calcolare i risultati di scenari alternativi basati sulla selezione dei valori variabili e sulla ripetizione del processo. Per la simulazione è necessaria l'individuazione di un intervallo di valori (ad esempio, il numero di workstation interessate o il livello di assorbimento dei canali elettronici) e la distribuzione delle probabilità per ciascuna variabile. Il risultato di una simulazione è l'intervallo dei risultati possibili e consente di identificare il valore medio dei vantaggi, oltre a costi e rischi. La scelta accurata di variabili di valore e rischio che riflettano il possibile impatto degli investimenti di infrastruttura consente di collocare in prospettiva il ritorno su un investimento di questo tipo.
Scenari Quando i modelli matematici o di simulazione non sono praticabili oppure si rivelano poco adatti alla cultura e alle competenze dell'organizzazione, è preferibile utilizzare tecniche basate sugli scenari. Tenendo conto dell'oggetto o della funzione dell'ufficio, delle priorità politiche e delle tendenze ambientali (compresa la tecnologia), l'organizzazione può sviluppare un numero ridotto di scenari plausibili per un periodo compreso tra tre e cinque anni. Ciascuno scenario deve essere esclusivamente volto a dimostrare i vantaggi dell'investimento in infrastruttura.
A differenza della pianificazione a più a lungo termine, gli scenari non devono escludersi a vicenda ed è possibile assegnare loro un livello di probabilità. Gli scenari possono tenere conto delle prossime elezioni, del risultato di dibattiti politici in corso e di possibili eventi sul mercato IT, come acquisizioni o cambiamenti nelle strategie dei fornitori.
Scenario del tipo "peggiore delle ipotesi" Questa variante dell'approccio basato sugli scenari viene applicata quando nell'organizzazione IT si ritiene che sia necessario un investimento urgente per rispondere a nuove esigenze che nasceranno da impegni o nuove funzioni future o, semplicemente, per mantenere i livelli di servizio correnti. Quando vengono ignorati, i problemi di infrastruttura si aggravano e lo sforzo necessario per la loro risoluzione tende ad aumentare. Chi si assume la responsabilità di proporre delle modifiche incontrerà delle resistenze ed è probabile che non ottenga alcun credito per i propri sforzi. Una situazione del genere può essere in parte risolta con una forte enfasi su metriche e misurazioni relative ad alcune della prestazioni interessate, come il tempo di risposta alle richieste e i tempi di riparazione. Queste informazioni devono essere pubblicizzate il più possibile, in modo che gli interlocutori diventino consapevoli dei possibili vantaggi in termini di prestazioni.
Con gli scenari del tipo "peggiore delle ipotesi" si accentuano di proposito le conseguenze di un mancato investimento, concentrando l'attenzione sull'aumento dei rischi e il deterioramento delle prestazioni. Questo approccio deve essere utilizzato con grande cautela e solo in circostanze davvero eccezionali. L'utilizzo abituale di questo approccio potrebbe indurre la sensazione che l'organizzazione IT stia tentando di sovvertire i processi di gestione degli investimenti stabiliti, generando conflitti e disallineamenti negli stessi processi che si intende risolvere.

Scelta di una metodologia di pianificazione
Nella Figura 1 vengono riepilogati i pro e i contro di ciascun metodo e le occasioni in cui è consigliabile adottarli. Una volta scelto, il metodo dovrà essere utilizzato in modo coerente in tutta l'organizzazione per garantire la comparabilità.
Figure 1 Metodologie con business case (Close Figure 1)

Metodo Pro Contro Da utilizzare quando
Opzioni reali (matematico)
  • Rigoroso
  • Base teorica solida
  • Complesso
  • Non adeguato quando i valori immateriali sono prevalenti
  • Valore e valore futuro sono quantificabili
  • Esiste una solida cultura di valutazione dell'investimento
  • Le competenze sono disponibili o facilmente accessibili
Simulazione
  • Consente l'esplorazione di valori alternativi
  • Consente di costruire con facilità delle alternative
  • Le medie potrebbero essere poco significative in presenza di valori immateriali
  • La scelta dell'intervallo nella variabile è critical
  • I vantaggi tangibili sono prevalenti
  • Il supporto strumentale è già disponibile
Scenario
  • Consente di utilizzare qualsiasi combinazione di vantaggi tangibili e immateriali
  • Consente l'esplorazione di scenari molto diversi, combinando tecniche diverse
  • Richiede una forte disciplina per la convergenza verso scenari comparabili
  • L'orizzonte temporale potrebbe variare
  • I valori immateriali prevalgono o la natura reale dei vantaggi non è chiara
  • La cultura dell'organizzazione non è matura per gli altri metodi
Scenario del tipo "peggiore delle ipotesi"
  • Consente di dimostrare in modo efficace le conseguenze del mancato investimento
  • Semplice da creare
  • Non aiuta a definire le priorità
  • Misurabile
  • L'investimento è assolutamente necessario e in ritardo
L'efficacia di ciascun approccio dipende da alcuni fattori. Un buon punto di partenza consiste nel fornire una risposta alle domande riportate di seguito. Quanto è integrato o compatibile l'approccio con i processi obbligatori (vale a dire, con il budget e la pianificazione dei fondi)? Il metodo del business case prescelto è di facile utilizzo ed efficace nel comunicare il valore ai responsabili?
Le organizzazioni devono saper bilanciare la flessibilità nella scelta degli indicatori di valore adatti a un particolare ufficio con l'esigenza di garantire la comparabilità tra i diversi uffici. Inoltre, la capacità di utilizzare determinati parametri di valutazione in ogni parte del ciclo di vita degli investimenti e non solo nella cornice temporale del business case è estremamente importante. Allo stesso modo, il piano deve dimostrare la propria utilità per più tipi di investimento.
È quindi necessario scegliere e sviluppare un approccio al valore in collaborazione con i membri della struttura direttiva dell'organizzazione. È essenziale che la cornice operativa scelta consenta di comunicare il valore con efficacia ai responsabili interni ed esterni. Questo concetto vale per i dirigenti di organizzazioni private quanto per i funzionari eletti o i manager degli enti pubblici coinvolti.
Ulteriori riferimenti
  • Webcast: l'IT come risorsa di business strategica
  • Serie IT Manager Connections

Acer Maamoun è un Enterprise Strategy Consultant in Microsoft. Ha accumulato oltre 18 anni di esperienza nel campo delle strategie aziendali in ambito IT


 The Cable Guy: Authenticated Internet Protocol
The Cable Guy
Authenticated Internet Protocol
Joseph Davies
Parti di questo articolo illustrano una versione provvisoria di Windows Server 2008. Tali informazioni potrebbero essere soggette a modifiche.

Windows Vista e Windows Server 2008 (attualmente in fase di beta test) supportano entrambi Authenticated Internet Protocol (AuthIP), una versione avanzata del protocollo IKE (Internet Key Exchange). Sia AuthIP che IKE sono protocolli utilizzati per determinare il materiale principale e negoziare i parametri di protezione per comunicazioni protette tramite
Internet Protocol security (IPsec). AuthIP fornisce manutenzione e configurazione semplificate dei criteri IPsec in molte configurazioni e offre flessibilità aggiuntiva per l'autenticazione del peer IPsec. In questo articolo vengono forniti i dettagli sul protocollo AuthIP e descritte le funzionalità di coesistenza tra i peer IPsec che supportano AuthIP e IKE o solo IKE.

Panoramica su IKE
Esempi di negoziazione
Per dimostrare la funzionalità di coesistenza, verrà esaminato cosa succede tra i peer IPsec basati su Windows Vista e su Windows XP quando si tenta di negoziare la protezione di IPsec.

Esempio 1: due peer IPsec basati su Windows Vista in modalità di richiesta
In questo esempio, l'iniziatore è un peer IPsec basato su Windows Vista (Peer 1) e il risponditore sta eseguendo Windows Vista (Peer 2). Entrambi i peer sono configurati con modalità di richiesta sia per le comunicazioni in ingresso che per quelle in uscita. In modalità di richiesta, un peer IPsec richiede la protezione di IPsec, che tuttavia non è obbligatoria. Vengono di seguito riportati i messaggi scambiati tra i due peer:
  1. Peer 1 invia un segmento SYN (synchronize) TCP in testo normale iniziando una connessione TCP con Peer 2.
  2. Peer 2 invia un segmento SYN-ACK (acknowledgment) TCP.
  3. Peer 1 invia un segmento ACK TCP.
  4. Peer 1 invia un messaggio ISAKMP basato su AuthIP iniziando la negoziazione in modalità principale AuthIP.
  5. Peer 1 invia un messaggio ISAKMP basato su IKE iniziando la negoziazione in modalità principale IKE.
  6. Peer 2 risponde con un messaggio ISAKMP basato su AuthIP continuando la negoziazione in modalità principale AuthIP.
  7. Peer 1 e Peer 2 completano la negoziazione in modalità principale, modalità veloce e modalità estesa (facoltativo) di AuthIP.
  8. I segmenti successivi inviati tramite la connessione TCP sono protetti con IPsec.
L'esatto ordine dei messaggi numerati da 1 a 5 dipende dalla latenza di rete. Gli esempi descritti in questo articolo valgono per una rete a latenza molto ridotta, in cui l'handshake TCP (Messaggi da 1 a 3) termina prima che Peer 1 possa inviare i messaggi ISAKMP iniziali (Messaggi 4 e 5). Su una rete a latenza superiore, Peer 1 invierebbe il segmento SYN TCP in testo normale, il messaggio ISAKMP basato su AuthIP e quindi il messaggio ISAKMP basato su IKE come primi tre messaggi dello scambio.

Esempio 2: peer IPsec basato su Windows Vista in modalità di richiesta e peer IPsec basato su Windows XP in modalità di richiesta
In questo esempio, l'iniziatore è un peer IPsec basato su Windows Vista (Peer 1) e il risponditore sta eseguendo Windows XP (Peer 2). Entrambi i peer sono configurati con modalità di richiesta sia per le comunicazioni in ingresso che per quelle in uscita. Vengono di seguito riportati i messaggi scambiati tra i due peer:
  1. Peer 1 invia un segmento SYN TCP in testo normale iniziando una connessione TCP con Peer 2.
  2. Peer 2 invia un segmento SYN-ACK TCP.
  3. Peer 1 invia un segmento ACK TCP.
  4. Peer 1 invia un messaggio ISAKMP basato su AuthIP iniziando la negoziazione in modalità principale AuthIP.
  5. Peer 1 invia un messaggio ISAKMP basato su IKE iniziando la negoziazione in modalità principale IKE.
  6. Peer 2 risponde con un messaggio ISAKMP basato su IKE continuando la negoziazione in modalità principale IKE.
  7. Peer 1 e Peer 2 terminano la negoziazione in modalità veloce e in modalità principale IKE.
  8. I segmenti successivi inviati tramite la connessione TCP sono protetti con IPsec.

Esempio 3: peer IPsec basato su Windows Vista in modalità di richiesta e peer IPsec basato su Windows XP in modalità di richiesta obbligatoria
In questo esempio, l'iniziatore è un peer IPsec basato su Windows Vista (Peer 1) e il risponditore sta eseguendo Windows XP (Peer 2). Peer 1 è configurato con la modalità di richiesta per le comunicazioni in uscita e Peer 2 è configurato con la modalità di richiesta obbligatoria per le comunicazioni in ingresso. In modalità di richiesta obbligatoria, un peer IPsec richiede necessariamente la protezione IPsec ed elimina automaticamente i pacchetti non protetti. Vengono di seguito riportati i messaggi scambiati tra i due peer:
  1. Peer 1 invia un segmento SYN TCP in testo normale iniziando una connessione TCP che Peer 2 elimina automaticamente.
  2. Peer 1 invia un messaggio ISAKMP basato su AuthIP iniziando una negoziazione in modalità principale AuthIP che Peer 2 elimina automaticamente.
  3. Peer 1 invia un messaggio ISAKMP basato su IKE iniziando la negoziazione in modalità principale IKE.
  4. Peer 2 risponde con un messaggio ISAKMP basato su IKE continuando la negoziazione in modalità principale IKE.
  5. Peer 1 e Peer 2 terminano la negoziazione in modalità veloce e in modalità principale IKE.
  6. Peer 1 ritrasmette il segmento SYN TCP (protetto con IPsec).
  7. Peer 2 invia il segmento SYN-ACK TCP (protetto con IPsec).
  8. Peer 1 invia il segmento ACK TCP (protetto con IPsec).

IKE è uno standard Internet, definito in RFC 2409 (ietf.org/rfc/rfc2409.txt), che definisce un meccanismo per stabilire le associazioni di protezione (SA) IPsec. Una SA è una combinazione di criteri e chiavi compatibili che definiscono i meccanismi e i servizi di protezione che consentono di proteggere la comunicazione tra i peer IPsec. Nello specifico, IKE combina Internet Security Association e Key Management Protocol (ISAKMP) in RFC 2408 e il protocollo di determinazione di chiavi Oakley (RFC 2412). IKE utilizza il protocollo di determinazione di chiavi Oakley per generare materiale chiave segreto per comunicazioni protette.
IKE utilizza ISAKMP per negoziare le SA. ISAKMP comprende funzionalità per identificare e autenticare i peer, gestire le SA e scambiare materiale chiave. ISAKMP è un framework per la negoziazione di comunicazioni protette indipendente dai protocolli di scambio chiavi specifici, dagli algoritmi di integrità e crittografia e dai metodi di autenticazione.
I peer IPsec utilizzano IKE per eseguire la negoziazione in modalità veloce e modalità principale. La negoziazione in modalità principale crea la SA ISAKMP che protegge le negoziazioni della protezione. Durante la negoziazione in modalità principale, l'iniziatore e il risponditore si scambiano una serie di messaggi ISAKMP per negoziare gli algoritmi di hash e di crittografia per la SA ISAKMP, scambiare materiale di determinazione chiavi e identificarsi e autenticarsi a vicenda.
Durante la fase di negoziazione in modalità veloce, vengono create le due SA IPsec (una per i dati in ingresso e un'altra per i dati in uscita) che proteggono i dati inviati tra due peer IPsec. Durante la negoziazione in modalità veloce, l'iniziatore e il risponditore si scambiano una serie di messaggi ISAKMP crittografati per negoziare gli algoritmi di hash e di crittografia sia per le SA IPsec in entrata che per quelle in uscita.
Per ulteriori informazioni sulla negoziazione in modalità veloce e in modalità principale basata su IKE, vedere "Negoziazione IKE per le associazioni di protezione IPsec" all'indirizzo microsoft.com/technet/community/columns/cableguy/cg0602.mspx.

Panoramica su AuthIP
AuthIP è una versione migliorata di IKE che offre maggiore flessibilità supportando l'autenticazione per utente, l'autenticazione con più credenziali, la negoziazione con metodo di autenticazione migliorato e l'autenticazione asimmetrica. Allo stesso modo di IKE, AuthIP supporta la negoziazione in modalità principale e in modalità veloce. AuthIP supporta inoltre la modalità estesa, una parte della negoziazione del peer IPsec durante la quale può essere eseguita una seconda fase di autenticazione. La modalità estesa, facoltativa, può essere utilizzata per più autenticazioni. Ad esempio, con la modalità estesa è possibile eseguire autenticazioni separate basate sull'utente e basate sul computer.
Il supporto per l'autenticazione multipla fa parte dell'applicazione di IPsec per la piattaforma Protezione accesso alla rete, in cui i peer IPsec eseguono l'autenticazione con le credenziali del computer e utilizzano anche un certificato di integrità per dimostrare di essere conformi ai requisiti di integrità del sistema. Per ulteriori informazioni sulla Protezione accesso alla rete, vedere microsoft.com/nap. Per ulteriori informazioni sulle funzionalità di AuthIP, vedere l'articolo "AuthIP in Windows Vista" all'indirizzo microsoft.com/technet/community/columns/cableguy/cg0806.mspx.

Messaggi di AuthIP
Sia IKE che AuthIP utilizzano ISAKMP come protocollo di negoziazione SA e di scambio chiavi. I messaggi ISAKMP vengono inviati tramite il protocollo UDP (User Datagram Protocol) e consistono in un'intestazione ISAKMP e uno o più payload ISAKMP. L'intestazione ISAKMP contiene le informazioni sul messaggio, tra cui il tipo di messaggio. Nella Figura 1 viene illustrato il formato dell'intestazione ISAKMP.
Figura 1 Formato dell'intestazione ISAKMP
Figura 1 Formato dell'intestazione ISAKMP
Nell'intestazione ISAKMP, i campi Cookie iniziatore e Cookie risponditore sono impostati su un numero a caso diverso da zero selezionato dai peer IPsec. Il campo Payload successivo indica il primo payload nel messaggio ISAKMP, immediatamente dopo l'intestazione ISAKMP. RFC 2408 elenca i valori definiti nel campo Payload successivo. I tipi di payload 128-255 sono riservati ad uso privato. I campi Versione principale e Versione secondaria indicano le versioni di ISAKMP sul peer IPsec che invia il messaggio ISAKMP. Per IKE e AuthIP, la versione principale è 1 e la versione secondaria è 0.
Il campo Tipo di scambio indica il tipo di scambio di ISAKMP eseguito. Il tipo di scambio detta la struttura e l'ordine dei payload ISAKMP. RFC 2408 definisce i valori del campo Tipo di scambio. I tipi di scambio 128-255 sono riservati ad uso privato.
Il campo Flag contiene tre flag definiti nella specifica RFC 2408. Il bit inferiore (bit 0) è il bit Encryption, che indica che i payload ISAKMP sono crittografati (quando impostato su 1) o non crittografati (quando impostato su 0). La crittografia viene effettuata utilizzando l'algoritmo negoziato per la SA ISAKMP, che viene identificato dalla combinazione dei campi Cookie iniziatore e Cookie risponditore. Il bit di basso livello successivo (Bit 1) è il bit Commit, che indica se lo scambio di chiavi è sincronizzato (quando impostato su 1) o non sincronizzato (quando impostato su 0). Il bit Commit viene utilizzato per assicurare che la SA completi la negoziazione prima che vengano inviati i dati crittografati. Il bit di basso livello successivo (Bit 2) è il bit Authentication Only, utilizzato per indicare che il messaggio contiene (quando impostato su 1) o non contiene (quando impostato su 0) l'intero payload Notify del tipo di scambio informativo ed è stato autenticato, ma non crittografato.
Il campo ID messaggio contiene un identificatore univoco per il messaggio. Questo campo viene utilizzato per impedire conflitti quando entrambi i peer IPsec tentano di stabilire contemporaneamente una SA IPsec. Il campo Lunghezza indica la lunghezza dell'intero messaggio ISAKMP.
Per IKE, il messaggio ISAKMP contiene una serie di payload ISAKMP. Il primo payload è indicato dal campo Payload successivo dell'intestazione ISAKMP. Ogni payload ISAKMP dispone del proprio campo Payload successivo per indicare il payload successivo. Il campo Payload successivo dell'ultimo payload è impostato su 0. Nella Figura 2 viene mostrato il formato dei messaggi IKE.
Figura 2 Formato dei messaggi IKE
Figura 2 Formato dei messaggi IKE
AuthIP utilizza i messaggi ISAKMP con i tipi di scambio 243 (Modalità principale), 244 (Modalità veloce), 245 (Modalità estesa) e 246 (Notifica) nel campo Tipo di scambio dell'intestazione ISAKMP. Un'importante differenza che contraddistingue i messaggi ISAKMP basati su AuthIP consiste nel fatto che contengono esclusivamente un payload ISAKMP: il payload Crypto o il payload Notify. Il payload Crypto contiene i payload incorporati utilizzati per la negoziazione in modalità principale, modalità veloce o modalità estesa. Il payload Crypto può contenere un insieme di payload crittografati o in testo normale, in base al bit Encryption nel campo Flag dell'intestazione ISAKMP. Nella Figura 3 viene mostrato il formato dei messaggi AuthIP contenenti il payload Crypto.
Figura 3 Formato dei messaggi AuthIP contenenti il payload Crypto
Figura 3 Formato dei messaggi AuthIP contenenti il payload Crypto

Coesistenza di AuthIP e IKE
Windows Vista® e Windows Server® 2008 supportano sia IKE che AuthIP. Windows® XP e Windows Server 2003, invece, supportano solo IKE. Un peer IPsec iniziatore che supporta sia AuthIP che IKE e dispone di un criterio di protezione della connessione che utilizza sia AuthIP che IKE deve stabilire se il peer IPsec risponditore supporta AuthIP o IKE. Di conseguenza, deve utilizzare il protocollo più appropriato per la negoziazione della protezione di IPsec, dando priorità all'utilizzo di AuthIP piuttosto che di IKE.
Per determinare il protocollo di negoziazione del peer IPsec risponditore, un peer IPsec iniziatore che utilizza sia AuthIP che IKE invia contemporaneamente i seguenti messaggi:
  • Messaggio 1: un messaggio AuthIP che inizia la negoziazione in modalità principale
  • Messaggio 2: un messaggio IKE che inizia la negoziazione in modalità principale
Se il nodo che risponde supporta AuthIP, deve rispondere al Messaggio 1 con un messaggio AuthIP continuando la negoziazione in modalità principale ed eliminando automaticamente il Messaggio 2. Un nodo che risponde ma non supporta AuthIP elimina automaticamente il Messaggio 1 perché il campo Tipo di scambio contiene un valore non supportato e risponde al Messaggio 2.
Per impedire la negoziazione basata su IKE tra due peer IPsec che eseguono Windows Vista o Windows Server 2008 quando il Messaggio 1 proviene dalla rete o arriva dopo il Messaggio 2, i peer IPsec che eseguono Windows Vista o Windows Server 2008 inviano il Messaggio 2 con un payload ISAKMP di ID del fornitore supportato da AuthIP. Il payload di ID del fornitore supportato da AuthIP indica che il peer IPsec supporta AuthIP.
Quindi, se un peer IPsec che esegue Windows Vista o Windows Server 2008 riceve il Messaggio 2 con il payload di ID del fornitore supportato da AuthIP, attende che il peer IPsec iniziatore ritrasmetta il Messaggio 1 e il Messaggio 2 e risponde al Messaggio 1.
Il peer IPsec iniziatore continua a ritrasmettere sia il Messaggio 1 che il Messaggio 2 fino a quando non riceve una risposta o non scade il tempo. Quando l'iniziatore riceve una risposta, determina la capacità del risponditore dall'intestazione ISAKMP della risposta. Se il campo Tipo di scambio è impostato su 243 (il tipo di scambio per la negoziazione in modalità principale basata su AuthIP), il risponditore consente AuthIP. Se il campo Tipo di scambio è impostato su 2 (il tipo di scambio per la negoziazione in modalità principale basata su IKE e la protezione dell'identità), il risponditore consente IKE.
In base alla risposta, l'iniziatore risponde con il messaggio AuthIP successivo per la negoziazione in modalità principale AuthIP o con il messaggio IKE successivo per la negoziazione in modalità principale IKE. I peer IPsec devono utilizzare lo stesso protocollo che è stato utilizzato per negoziare la SA ISAKMP per tutta la durata della stessa.

Joseph Daviesè un technical writer di Microsoft e autore della rubrica mensile in linea The Cable Guy di TechNet, disponibile all'indirizzo Microsoft.com/technet/community/columns/cableguy.


 Windows PowerShell: Lavorare senza script
Windows PowerShell
Lavorare senza script
Don Jones

In qualsiasi occasione in cui ho modo di illustrare l'utilizzo di Windows PowerShell, durante una conferenza, nel newsgroup pubblico dedicato a Windows PowerShell o sul mio sito, mi imbatto continuamente in amministratori che confessano di voler "attendere ancora un po'" prima di imparare a utilizzare Windows PowerShell. Perché? La ragione più comune avanzata a sostegno di questa decisione è che
non dispongono del tempo materiale sufficiente per imparare a scrivere script.
È un sentimento comune. Gli amministratori sono in effetti una categoria perennemente occupata e spesso, proprio in virtù della mancanza di tempo libero, sono riluttanti ad apprendere l'utilizzo di una nuova tecnologia. Tuttavia è necessario che gli amministratori guardino avanti, apprendano l'utilizzo di nuovo software, come Windows Vista®, Windows Server® 2008 ed Exchange Server 2007, in modo da poter stare al passo con tutte le tecnologie che rivestono un'importanza critica per lo svolgimento del relativo lavoro. Windows PowerShell™ è una parte chiave di queste tecnologie.
Un altro motivo citato dagli amministratori a sostegno della decisione di rinunciare a imparare a scrivere script in Windows PowerShell è "la paura di diventare programmatori". Sotto questo aspetto, il presente articolo può rivelarsi particolarmente utile per tutti gli amministratori "afflitti" da questa paura. Si potrebbe rimanere piacevolmente sorpresi nello scoprire gli eccezionali risultati che è possibile ottenere con Windows PowerShell, senza scrivere il benché minimo frammento di codice.

Introduzione alla pipeline
In passato ho già parlato della pipeline orientata a oggetti, estremamente flessibile e potente utilizzata in Windows PowerShell. Anche se l'espressione "orientata a oggetti" potrebbe far sospettare che mi stia dirigendo verso un terreno proprio dei programmatori, nel corso dell'articolo si scoprirà che non è affatto così. Una delle caratteristiche della pipeline che preferisco è rappresentata dal fatto che è possibile utilizzarla in modo interattivo. Consente di ottenere risultati immediati e di perfezionarli con facilità in base alle esigenze. Si supponga, ad esempio, che sia necessario eseguire un inventario dello spazio disponibile su disco per diversi computer remoti. Si supponga inoltre che i nomi di tali computer siano elencati in un file di testo denominato C:\Computers.txt. Si tratta di un normale file di testo con un nome di computer per riga: nulla a che vedere con le complessità insite nella gestione di un database.
Per cominciare, mi limiterò a verificare se è possibile recuperare le informazioni dal computer locale. Dopotutto, se è possibile effettuare questa attività su un singolo computer, l'esecuzione della stessa attività su più computer dovrebbe essere piuttosto semplice. Inoltre questa attività non implica alcun lavoro di script. Tutte le operazioni verranno eseguite in modo interattivo nella shell e i risultati verranno restituiti immediatamente dopo aver premuto il tasto Invio.
Di seguito è riportato un suggerimento su questo tipo di attività. Per eseguire un inventario delle informazioni di gestione da computer remoti, è probabile che si utilizzi Strumentazione gestione Windows® (WMI). Ai fini dell'esempio, si supponga di utilizzare WMI. Accedo quindi a Live Search e immetto come termine di ricerca "windows wmi free disk space". Vengono visualizzati diversi risultati con la frase "Win32_LogicalDisk". Questa ha tutta l'apparenza di essere una classe WMI e potrebbe essere proprio la classe che sto cercando. Ignoro quindi tutti gli altri risultati della ricerca e immetto "Win32_LogicalDisk" come nuovo termine di ricerca; il risultato restituito fa riferimento a una pagina della documentazione di Win32_LogicalDisk sul sito MSDN® (msdn2.microsoft.com/aa394173.aspx). Accedo quindi a tale pagina e scopro che una delle proprietà per questa classe è FreeSpace. Sembra promettente!

Individuazione di un cmdlet
Per il passaggio successivo è necessario individuare un cmdlet che consenta di recuperare automaticamente le proprietà di una classe WMI. Uno degli aspetti più interessanti di Windows PowerShell è la disponibilità di straordinarie funzionalità di individuazione automatica integrate, vale a dire che la stessa shell aiuta a scoprire le proprie capacità. Immetto quindi Help *wmi* per individuare informazioni sull'utilizzo di WMI all'interno della shell. I risultati, illustrati nella Figura 1, sono l'alias Gwmi e il cmdlet a cui fa riferimento, Get-WMIObject. In sostanza, sono disponibili due modi per accedere alla stessa funzionalità che è possibile utilizzare indifferentemente. Poiché consentono di eseguire la stessa operazione, utilizzerò l'alias più breve, Gwmi:
Figura 1 Informazioni della shell sull'utilizzo di WMI
Figura 1 Informazioni della shell sull'utilizzo di WMI
PS C:\> gwmi win32_logicaldisk
Per la gioia degli amministratori a corto di tempo, in Windows PowerShell non viene rilevata alcuna distinzione tra maiuscole e minuscole.
I risultati del comando, illustrati nella Figura 2, includono tutte le cinque unità locali e le relative proprietà FreeSpace, elencate in byte. Per ciascuna di queste unità viene inoltre riportata la proprietà DriveType e sul computer locale vengono visualizzati i valori 2, 3 e 5.
Figura 2 Tutte le unità locali e le relative proprietà FreeSpace
Figura 2 Tutte le unità locali e le relative proprietà FreeSpace

Cmdlet del mese
È possibile che si sia utilizzato Get-Content per leggere il contenuto di un file di testo. Questo cmdlet considera ciascuna riga del file come oggetto [string], passando tali oggetti alla pipeline in modo che possano essere utilizzati da altri cmdlet. Tuttavia, Get-Content è dotato di numerose opzioni che garantiscono un maggiore livello di flessibilità: il parametro –readCount, ad esempio, consente di specificare quanti oggetti [string] passare contemporaneamente alla pipeline (l'impostazione predefinita prevede che vengano passati tutti gli oggetti), mentre il parametro –totalCount controlla il numero totale di righe lette dal file. Entrambi questi parametri risultano utili per l'utilizzo di file di grandi dimensioni per i quali, per motivi di prestazioni, è opportuno non elaborare l'intero file tutto in una volta.
Ecco un altro suggerimento. Il parametro –encoding consente di leggere in modo corretto un'ampia gamma di tipi di codifica di file, tra cui Unicode, ASCII, UTF7, UTF8 e molti altri. Per un elenco completo dei tipi di codifica supportati, eseguire help gc (gc è un alias per Get-Content).

Ridefinizione dei dati
A questo punto ho davanti due problemi. Innanzitutto, non sono interessato a tutte le altre proprietà: mi interessa solo FreeSpace. Secondo, il mio obiettivo non è ottenere informazioni sulla quantità di spazio disponibile per unità ottiche, unità rimovibili o unità di rete; sono interessato solo alle unità disco rigido locali. A tal fine, la proprietà DriveType può risultare utile per operare una distinzione tra i diversi tipi di unità restituiti. Accedo di nuovo al browser Web e noto che la documentazione contiene una tabella in cui viene spiegato il significato dei diversi valori di DriveType. Le sole unità a cui sono interessato solo quelle a cui è associata la proprietà DriveType con valore 3, che indica che l'unità è un disco rigido locale. Non avendo mai eseguito questa operazione in precedenza, decido di verificare se il comando Gwmi è in grado di eseguire automaticamente operazioni di filtraggio. Se si esegue Help Gwmi –full, sarà possibile ottenere informazioni dettagliate sulla modalità di funzionamento del comando, inclusi diversi esempi. Nell'elenco delle informazioni restituite noto un parametro che sembra particolarmente utile, –filter, quindi decido di provare a eseguirlo:
gwmi win32_logicaldisk -filter "drivetype = 3"
Operazione riuscita! Il mio elenco di unità ora contiene solo dischi rigidi locali. Il secondo problema è pertanto risolto; ora è necessario risolvere il primo, ovvero liberarsi di tutte le proprietà non rilevanti ai fini dell'esempio.
Eseguo Get-Command per elencare tutti i cmdlet di Windows PowerShell e l'occhio si posa casualmente su Select-Object. La descrizione suggerisce che consente di selezionare proprietà specifiche di un oggetto o insieme di oggetti. Provo pertanto a utilizzare questo cmdlet:
gwmi win32_logicaldisk -filter "drivetype = 3" | select freespace
Inviando i risultati di Gwmi a Select (l'alias per Select-Object), otterrò esattamente la proprietà che mi interessa. Però i risultati non sono affatto "intuitivi": è stato restituito semplicemente un elenco di numeri. Accedo di nuovo alla documentazione e scopro che la proprietà DeviceID contiene la lettera di unità. Modifico rapidamente il comando e provo di nuovo:
gwmi win32_logicaldisk -filter "drivetype = 3" | select deviceid,freespace
Perfetto! Poiché vengono elencate solo due proprietà, la shell è in grado di inserire le informazioni in una tabella molto razionale. Nell'articolo del prossimo mese illustrerò i casi in cui Windows PowerShell sceglie di utilizzare elenchi e tabelle.

Calcolo
Ho recuperato informazioni sulla quantità di spazio disponibile, ma tali dati sono espressi in byte anziché in megabyte o gigabyte. Probabilmente, ai fini dell'esempio, più che la proprietà FreeSpace può risultare particolarmente utile un valore calcolato dalla proprietà FreeSpace. Il cmdlet ForEach-Object (o uno dei relativi alias, come %) può rivelarsi utile. Questo cmdlet consente di utilizzare una variabile speciale, $_, per fare riferimento al disco logico corrente e di accedere alle singole proprietà di ciascun disco ed effettuare alcuni calcoli matematici. Di seguito viene riportato il comando modificato:
gwmi win32_logicaldisk -filter "drivetype = 3" | % { $_.deviceid; $_.freespace/1GB }
La modifica del comando prevede semplicemente la rimozione di Select e la relativa sostituzione con l'alias per ForEach-Object (%). Indico a ForEach-Object il tipo di operazione da eseguire con ciascuna classe Win32_LogicalDisk restituita, ovvero utilizzare la proprietà DeviceID e dividere la proprietà FreeSpace per un gigabyte (Windows PowerShell è in grado di riconoscere unità di misura come KB, MB e GB). Pertanto il mio risultato verrà restituito in gigabyte.

Più computer
A questo punto, dato l'esito positivo dell'operazione per un singolo computer, è giunto il momento di verificare se si riesce a ottenere lo stesso risultato su più sistemi. So come ottenere il contenuto di un file di testo. Si tratta di un'operazione che riporta indietro nel tempo, all'epoca di MS-DOS®. Per eseguirla, occorre infatti utilizzare il comando Type che in Windows PowerShell è un alias per Get-Content:
Type c:\computers.txt
Lo scopo ora consiste nell'eseguire il comando WMI utilizzato in precedenza per ciascun computer. Anche in questo caso occorre fare ricorso all'ormai noto cmdlet ForEach-Object. A questo punto non resta che esaminare l'ultimo comando:
type c:\computers.txt | % { $_;
gwmi –computername $_ win32_logicaldisk -filter "drivetype=3" | % { $_.deviceid; $_.freespace/1GB} }
Orribile, vero? L'utilizzo esclusivo di alias anziché di nomi di cmdlet rende la lettura di questo codice piuttosto difficoltosa. Tuttavia, andando avanti si scoprirà che è abbastanza semplice da decifrare:
  • Inizio digitando il contenuto del file di testo.
  • Invio tale contenuto a ForEach-Object.
  • ForEach-Object restituisce, utilizzando la variabile $_, l'elemento corrente, ovvero il nome del computer corrente.
  • ForEach-Object quindi esegue il comando WMI, che include un'altra chiamata a ForEach-Object.
L'espansione dei nomi di alias in nomi di cmdlet potrebbe essere di aiuto. Anche in questo caso viene utilizzato lo stesso comando, ma questa volta ho digitato i nomi completi dei cmdlet e ho suddiviso il comando in singole righe in modo da semplificare l'analisi di ciascuna sezione:
Get-Content C:\Computers.txt |
ForEach-Object {
 $_; Get-WMIObject –computername $_
Win32_LogicalDisk -filter "DriveType=3" |
 ForEach-Object {
 $_.DeviceID; $_.FreeSpace/1GB
 }
}
I risultati, magari non eleganti ma molto funzionali, sono illustrati nella Figura 3.
Figura 3 Risultati finali
Figura 3 Risultati finali

Conclusione: gli script non sono necessari
L'obiettivo di questa presentazione è dimostrare che è possibile utilizzare Windows PowerShell senza alcun lavoro di script. Con pochi esempi, come quello riportato in questo articolo, più un minimo di esplorazione di Windows PowerShell, sarà possibile individuare alcune delle informazioni necessarie per eseguire tutte le attività desiderate.
La conclusione è che l'uso di Windows PowerShell è destinato a diffondersi. Perché non iniziare ad apprenderne le basi fin da subito? Tra qualche tempo è probabile che sembrerà impossibile farne a meno, ma ora di certo non è il termine "script" che può impedire di approfondire l'argomento Windows PowerShell.

Don Jones è il guru degli script di SAPIEN Technologies e istruttore per ScriptingTraining.com. È possibile contattare Don sul suo sito Web, ScriptingAnswers.com.


 Hey, Scripting Guy!: La tecnologia Silverlight
Hey, Scripting Guy!
La tecnologia Silverlight
Gli Scripting Guy di Microsoft
Scarica il codice per questo articolo: HeyScriptingGuy2007_10.exe (156KB)

La storia umana è stata da sempre contrassegnata dallo scontro di forze diametralmente opposte: i romani contro le orde barbare, gli Hatfield contro i McCoy, gli Scripting Guy contro coloro che ritengono che un articolo sulla creazione di script per l'amministrazione del sistema debba trattare esclusivamente questo specifico argomento e non dilungarsi su altri argomenti apparentemente non pertinenti come, ad esempio, lo scontro storico tra forze diametralmente opposte [o trattare, ad esempio, di uncini da macellaio... ].
Il mondo informatico non è immune a questi scontri tra forze diametralmente opposte. In particolare, viene in mente lo scontro tra sviluppatori e amministratori di sistema. Come Karl Marx disse: "O quest'uomo è morto o il mio orologio si è fermato".
Un momento... Era Groucho Marx. Karl Marx ha detto: "L'arte è sempre e ovunque la confessione segreta e, allo stesso tempo, il movimento immortale del suo tempo". In verità, non abbiamo idea di cosa significhi questa affermazione. Bisogna ammettere tuttavia che, sebbene Groucho Marx sia senza dubbio un po' più divertente di Karl Marx, le battute di spirito di Groucho non sono particolarmente pertinenti alla questione relativa al contrasto tra sviluppatori e amministratori di sistema.
Inoltre, non abbiamo dubbi sul fatto che fosse Karl Marx a spingere gli Scripting Guy a recitare il giuramento di fedeltà ogni mattina prima del lavoro: "gli amministratori di sistema non sono sviluppatori". Una verità incontestabile: gli amministratori di sistema non erano sviluppatori. Gli sviluppatori si occupavano della scrittura di programmi software, mentre gli amministratori di sistema si occupavano ... beh, a dire il vero, nessuno di noi alla Microsoft sa con esattezza cosa facessero gli amministratori di sistema. Una sola cosa è certa: non aveva nulla a che vedere con la scrittura di programmi software.
Ovviamente, Karl Marx scrisse anche il brano "The Times, They Are A-Changing" (o almeno ci ha detto che l'ha scritto).
Grazie in parte al TechNet Script Center (microsoft.com/technet/scriptcenter), gli amministratori di sistema hanno gradualmente scoperto VBScript e hanno iniziato a scrivere autonomamente alcune utilità che, sebbene non fossero complete di tutte le funzionalità di cui un tipico programma software dispone, consentivano di eseguire utili attività di gestione. Per la scrittura delle utilità, gli amministratori di sistema hanno dovuto avvalersi di competenze molto simili a quelle degli sviluppatori.
Ma il bello deve ancora venire. Con l'avvento di Windows PowerShell™ (microsoft.com/technet/scriptcenter/hubs/msh.mspx) anche gli amministratori di sistema e gli autori di script hanno la possibilità di utilizzare Microsoft® .NET Framework. Windows Vista® ha in seguito introdotto il concetto di gadget (microsoft.com/technet/scriptcenter/topics/vista/gadgets-pt1.mspx), collocando gli amministratori di sistema, o almeno gli amministratori di sistema che scrivono script, e gli sviluppatori su un piano di parità. E ora, rullo di tamburi, è arrivata la tecnologia Microsoft Silverlight, il "plug-in multipiattaforma compatibile con più browser per la creazione di contenuti multimediali di nuova generazione basati su .NET Framework e di applicazioni interattive complete per il Web".
Una presentazione davvero altisonante, vero? Ci si chiederà tuttavia cosa c'entri tutto questo con gli autori di script per l'amministrazione del sistema. Onestamente, non siamo in grado di dare una risposta esaustiva. È comunque vero che Silverlight consente di semplificare la creazione di presentazioni multimediali e interfacce utente molto interessanti. Tutti sanno che Silverlight è, come descritto nel materiale di marketing, un metodo per creare applicazioni Web; ecco tuttavia una notizia di cui non tutti sono a conoscenza: Silverlight sembra funzionare altrettanto bene con applicazioni HTML o HTA (HTML Application) (microsoft.com/technet/scriptcenter/hubs/htas.mspx), uno strumento molto amato dagli autori di script. Dunque potrebbe valere la pena provare a utilizzare Silverlight.

Prima di andare avanti...
È opportuno sottolineare che questo articolo non si propone di trattare le numerose funzionalità di Silverlight e i potenziali utilizzi di tale tecnologia; lo scopo principale dell'articolo è illustrare un numero sufficiente di frammenti di codice che è possibile utilizzare per esercitarsi con questa tecnologia. Per installare Silverlight (disponibile gratuitamente), accedere alla home page di Silverlight all'indirizzo microsoft.com/silverlight. Sono inoltre disponibili SDK, progetti di esempio e molte altre utili risorse all'indirizzo silverlight.net/GetStarted.
Per ora, si partirà dal presupposto che si sia già installato Silverlight e che si sia scaricato dalla sezione Code Downloads del sito Web di TechNet Magazine (technetmagazine.com/code07.aspx) il file descritto nella Figura 1.
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.
Non è necessario utilizzare il file SampleProject.js, almeno non per seguire le indicazioni illustrate nell'articolo di questo mese. Silverlight consente di associare gli script a oggetti ed eventi all'interno del progetto; gli script possono essere specificati a livello di codice nel file HTML o (come in questo caso) letti da un file di "inclusione" esterno come quello riportato di seguito. Inoltre, il file SampleProject.html verrà convertito in un HTA: è sufficiente rinominarlo SampleProject.hta. Semplice, no?
Salvare tutti questi file in una cartella e prepararsi alle sorprese.

File XAML
Come si sarà intuito, l'attenzione nell'articolo di questo mese della rubrica Hey, Scripting Guy! è incentrata sul file XAML. Detto per inciso, XAML si pronuncia "zamel". XAML è l'acronimo di Extensible Application Markup Language. Tra le altre funzioni, XAML consente di creare interfacce utente mediante un linguaggio XML. La domanda è: questo strumento sarà in grado di semplificare la creazione di interfacce utente per un amministratore di sistema? Questa è una delle sorprese.
Per iniziare, avviare il Blocco note e aprire il file SampleProject.xaml. Sostituire qualsiasi codice eventualmente presente con il seguente codice:
<Canvas
 xmlns="http://schemas.microsoft.com/
    client/2007"
 xmlns:x="http://schemas.microsoft.com/
    winfx/2006/xaml">
</Canvas>
Nota: SampleProject.hta è già preconfigurato per il caricamento delle informazioni contenute in SampleProject.xaml. Per utilizzare un file XAML differente, è necessario modificare il file CreateSilverlight.js.
Dopo aver incollato il codice, salvare il file e fare doppio clic su SampleProject.hta. Cosa verrà visualizzato? Esatto: un grande riquadro grigio.
Nulla di strano: il risultato ottenuto è esattamente quello previsto.
Non c'è niente da vedere semplicemente perché non è stata ancora eseguita alcuna operazione: l'unica operazione eseguita finora è l'aggiunta di un'area di disegno al file XAML. Si tratta tuttavia di un passaggio importante. Dopotutto, utilizzando un'analogia, nel caso in cui si desideri esercitarsi con la tecnica della pittura a olio, la prima operazione da eseguire è trovare una tela. Lo stesso avviene in Silverlight: prima di aggiungere elementi al progetto, è necessario un'area in cui "disegnare". E ora l'area è disponibile.
Perché, tuttavia, si è ottenuto un riquadro grigio di 300 pixel per 300? La risposta è semplice: queste sono lo le specifiche riportate, per impostazione predefinita, nel file CreateSilverlight.js. Per sostituire questi valori predefiniti, è sufficiente aprire CreateSilverlight.js e modificare le impostazioni in base alle proprie esigenze. È meglio un'area di disegno con sfondo bianco di 800 pixel in larghezza e 300 pixel in altezza? Per gli esempi utilizzati in questo articolo, è preferibile proprio una configurazione di questo tipo. Accertarsi semplicemente di includere queste tre righe in CreateSilverlight.js:
width:'800', // Width of rectangular region of
             // control in pixels.
height:'300', // Height of rectangular region
              // of control in pixels.
background:'white', // Background color of
                    // control.
Nota: esatto: Nel file .js originale lo sfondo è impostato su #D6D6D6. Ora è stato impostato su bianco (white). Di fatto, in un file XAML, per rappresentare i colori, è possibile utilizzare valori RGB o nomi di colore (per un elenco completo dei valori e dei nomi di colore, visitare il sito Web all'indirizzo msdn2.microsoft.com/bb188314.aspx). Sebbene agli Scripting Guy piaccia rappresentare i colori con i valori RGB ("la mia casa è tutta in FFFFFACD con finiture FFCD5C5C"), in questo articolo si utilizzeranno i nomi di colore.
Suggerimento bonus: non è obbligatorio utilizzare colori a tinta unita come sfondo di un'area di disegno. Incollare il codice riportato nella Figura 2 nel file XAML e attendere il risultato.
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>
Fatto? Niente male, vero?
Ovviamente, l'interesse che può suscitare una "tela" vuota è davvero minimo se non nullo. È opportuno pertanto procedere aggiungendo un oggetto all'area di disegno. Sebbene Silverlight consenta di aggiungere tutti i tipi di oggetti, tra cui ellissi, rettangoli, linee e poligoni, si procederà aggiungendo all'area di disegno un blocco di testo, come ai vecchi tempi. Come? Inserendo tra i tag <Canvas> e </Canvas> nel file XAML i seguenti tag:
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">
</TextBlock>
Come si può vedere, XAML non è niente di trascendentale. Utilizzare innanzitutto il tag <TextBlock>, includendo i diversi parametri di TextBlock (come Name e FontSize) all'interno del tag. Indicare che si sta utilizzando TextBlock mediante il tag </TextBlock>. Ecco un particolare interessante su questa operazione. La procedura da seguire è molto simile all'aggiunta di un oggetto a un file XAML. Si desidera aggiungere un rettangolo di 300 pixel in larghezza e 100 pixel in altezza? Nessun problema:
<Rectangle
 Height="300"
 Width="100"
 Fill="Blue">
</Rectangle>
Quando si aggiunge una forma, ad esempio un rettangolo, all'area di disegno, specificare anche un colore di riempimento e/o di tratto. In caso contrario, Silverlight aggiungerà automaticamente un rettangolo trasparente all'area di disegno. Il rettangolo esiste, ma non è possibile visualizzarlo, a meno di non avere dei superpoteri con vista a raggi X.
A proposito di colori di riempimento e di tratto, questo è il metodo per applicare i colori ad alcuni oggetti in Silverlight. Per altri oggetti è necessario utilizzare un pennello, come LinearGradientBrush, già citato ma non descritto, nel suggerimento bonus. Se si preferisce applicare agli oggetti un colore a tinta unita, è possibile utilizzare SolidColorBrush. Dare ad esempio un'occhiata al codice XAML nella Figura 3 che consente di applicare al testo il colore rosso (tecnicamente viene "colorata" la proprietà Foreground di TextBlock).
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>
Per un effetto ancora migliore, provare la proprietà ImageBrush, che consente di inserire un'immagine nel testo:
<TextBlock.Foreground>
 <ImageBrush Name="test_brush" ImageSource="Sunset.jpg"/>
</TextBlock.Foreground>
Ecco un altro suggerimento: quando si utilizza la proprietà ImageBrush, è opportuno aumentare il valore di FontSize, poiché maggiori sono le dimensioni dei caratteri del testo, migliore sarà l'effetto ottenuto.
Utilizzarla e verificarne il risultato, che non mancherà di entusiasmare.

Un attimo: non è finita qui.
In termini di "abilità", non siamo ancora sullo stesso livello: restano ancora alcuni segreti da svelare. Non è niente male questa funzionalità che consente di visualizzare il testo in Silverlight; ancora più straordinaria è la possibilità di disegnare rettangoli, ellissi e poligoni. Ma tutte queste funzionalità impallidiscono in confronto alle animazioni che è possibile aggiungere a un progetto Silverlight.
Tuttavia, lo spazio a disposizione in questo articolo ci consente solo di introdurre alcuni dei metodi con cui è possibile creare animazioni Silverlight; qualsiasi altro argomento esula dall'ambito dell'articolo (non possiamo farci nulla; continuiamo a suggerire che TechNet Magazine diventi Hey, Scripting Guy! Magazine, ma evidentemente i nostri messaggi non sono stati ricevuti).
Senza indugiare oltre, ecco un effetto straordinario che consente di eseguire una graduale dissolvenza in entrata del testo. Aggiungere il codice riportato nella Figura 4 tra i tag <TextBlock> e </TextBlock> nel file XAML.
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>
Non lasciarsi tuttavia impressionare dalla lunghezza del codice da inserire; si tratta per lo più di codice boilerplate. Per cominciare, non è sufficiente aggiungere un'animazione a un file XAML; è necessario indicare il momento in cui si prevede di eseguire l'animazione. Questo rende necessaria l'impostazione di un insieme di trigger per TextBlock. Nell'esempio verrà creato un trigger che consente di avviare l'animazione ogni volta che TextBlock viene caricato:
<EventTrigger RoutedEvent="TextBlock.Loaded">
In Silverlight le animazioni devono essere eseguite in uno storyboard (un termine preso in prestito dall'industria cinematografica). Questo spiega la presenza dei tag <BeginStoryboard> e <Storyboard>.
Per consentire la dissolvenza in entrata del testo, è necessario modificare la proprietà Opacity. Il valore dovrà essere gradualmente aumentato da 0.0 (trasparente) a 1.0 (colore a tinta unita). Poiché Opacity è una proprietà di tipo Double (una proprietà basata su un valore numerico a doppia precisione), verrà utilizzata un'animazione DoubleAnimation. Come si utilizza un'animazione DoubleAnimation? Indicando l'oggetto di cui si desidera eseguire l'animazione (in questo caso Test, il nome assegnato a TextBlock); impostando la proprietà di destinazione (Opacity); e specificando l'intervallo dell'animazione (opacità da 0.0 a 1.0) e la durata dell'intera animazione (5 secondi). In altre parole:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
Nota: per specificare una durata di 5 secondi, utilizzare la sintassi 0:0:5 (ore, minuti, secondi). Se si utilizza il valore 5, non verrà generato un errore ma il completamento dell'animazione richiederà 5 giorni.
Fatto? Ora provare a eseguire questa operazione: all'interno del tag DoubleAnimation impostare la proprietà AutoReverse su True:
AutoReverse="True"
Verrà quindi eseguita prima la dissolvenza in entrata e successivamente la dissolvenza in uscita dell'animazione.
Impostare la proprietà RepeatBehavior su Forever; in tal modo, la dissolvenza in entrata e in uscita del testo verrà eseguita letteralmente per sempre:
RepeatBehavior="Forever"
Forse "per sempre" è un periodo di tempo troppo lungo? Impostare RepeatBehavior su 3x, ad esempio, in modo che l'animazione venga eseguita tre volte, quindi uscire.
RepeatBehavior="3x"
Tutto questo è molto interessante. Tuttavia, quando non si desidera eseguire la dissolvenza in entrata e in uscita del testo ma si preferisce un effetto con cui cambiare gradualmente il colore del testo, è consigliabile utilizzare l'animazione ColorAnimation:
<ColorAnimation
 Storyboard.TargetName="test_brush"
 Storyboard.TargetProperty="Color"
 From="Red" To="Blue" Duration="0:0:5" />
Nota: in questo caso, iniziare con del testo di colore rosso. La procedura per applicare al testo il colore rosso è già stata illustrata nella prima parte dell'articolo.
Interessante, vero? Eppure si sente un po' di delusione. Ah, ecco perché: con la proprietà ColorAnimation si sono ottenuti degli effetti piacevoli, ma in realtà si sperava consentisse di spostare gli oggetti sullo schermo. Non è il caso di perdersi d'animo. Silverlight anche da questo punto di vista non delude le aspettative. Provare il codice che segue:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Left)"
 To="150"
 Duration="0:0:5" />
Come si può vedere, è possibile spostare lentamente l'oggetto TextBlock dalla posizione iniziale in un punto a una distanza di 150 pixel dal bordo sinistro dell'area di disegno (Canvas.Left). Per spostare TextBlock verso l'alto e verso il basso, è sufficiente utilizzare la proprietà Canvas.Top:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Top)"
 To="150"
 Duration="0:0:5" />
È possibile combinare queste animazioni e fare in modo che l'oggetto TextBlock si sposti da un lato all'altro e verso il basso o verso l'alto? Mistero! Ecco tuttavia un suggerimento: incollare entrambe le animazioni nel file XAML (una dopo l'altra) e restare a guardare.
Nota: ebbene sì, era una bugia. Abbiamo sempre saputo che era possibile combinare queste animazioni. Infatti, è possibile inserire un gruppo di animazioni in un singolo progetto Silverlight. Non è un'operazione semplice: potrebbe essere necessario includere tag aggiuntivi per terminare un'animazione prima dell'inizio dell'animazione successiva. È inoltre possibile creare animazioni personalizzate inserendo semplicemente alcuni tag XML.

Questo è tutto. Fine della presentazione.
Sì, è vero: è un dispiacere anche per noi, soprattutto adesso che eravamo giunti alla parte più divertente. Tuttavia, questo non è un addio, ma un arrivederci. Coloro che desiderano ottenere ulteriori informazioni su Silverlight possono inviarci un messaggio all'indirizzo scripter@microsoft.com. Se l'interesse sull'argomento sarà sufficiente, vedremo cosa si potrà fare negli articoli futuri. Visitare il sito Web di TechNet Script Center (microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx) in cui verranno pubblicati collegamenti utili per il completamento degli esempi XAML. Fino ad allora, come dissero Karl Marx e Frederick Engels alla fine del manifesto dal Comitato di corrispondenza comunista di Bruxelles a G. A. Kottgen: "Buona notte e guida con prudenza".

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: BitLocker e le complessit&#224; dei rapporti di fiducia
Controllo della protezione
BitLocker e le complessità dei rapporti di fiducia
Justin Troutman

Windows Vista. Non ho mai pronunciato queste due parole nei miei articoli precedenti; ecco perché scrivendo questo articolo mi sono sentito come un bambino di cinque anni con un assegno in bianco che entra in un negozio di giocattoli. Innumerevoli sono le funzionalità di cui discutere, enorme è il patrimonio di conoscenze che vale la pena esplorare e numerose sono le strade che una discussione può aprire.
Un po' di tempo fa, mentre leggevo il blog del guru della protezione, Bruce Schneier, mi sono imbattuto in una voce che esprimeva un concetto all'epoca completamente nuovo per me: BitLocker™. Dopo alcune rapide ricerche ho scoperto che si tratta di una tecnologia progettata per fornire funzionalità di crittografia in Windows Vista®. La mia reazione immediata di fronte a tale scoperta fu di sgomento: "Oh no. La crittografia in Windows Vista? Non ne verrà nulla di buono. Ma se anche consentisse di ottenere risultati discreti, da qualche parte nel sistema ci deve essere una backdoor".
Alcuni argomenti storici (validi o meno) forniscono una spiegazione del perché si potrebbe avere qualche esitazione prima di utilizzare le funzionalità di protezione integrate in Windows®. Questo tuttavia esula dall'ambito dell'articolo, con cui mi propongo invece di spiegare perché ritengo che esistano valide ragioni per dare una chance a BitLocker. Voglio inoltre spezzare una lancia a favore del tipo di filosofia che garantisce la vitalità del software o dell'hardware di crittografia.
Non bisogna fraintendere: non sto proponendo BitLocker come una panacea in grado di garantire la protezione nel suo complesso. BitLocker è semplicemente una delle tante tessere che compongono il puzzle della sicurezza. Si prefigge lo scopo di fornire flessibilità nell'ambito di determinati modelli di rischio.
In particolare BitLocker è utile per far fronte ai danni derivanti dalla perdita (o furto) di un computer portatile. I lavoratori mobili portano continuamente con sé ogni sorta di informazione riservata, ovunque: treni e aerei, ristoranti e alberghi, abitazioni private e uffici. Queste informazioni sono memorizzate in computer portatili e altri dispositivi mobili che, per natura, non garantiscono una reale protezione, rendendo i dati memorizzati estremamente vulnerabili agli attacchi. Cosa accade ai dati quando un utente dimentica un computer portatile in qualche luogo?
Non è possibile eliminare la negligenza della natura umana. Per fortuna, è possibile limitare il caos che ne potrebbe derivare. Il costo che un'azienda deve sostenere per la sostituzione di un computer portatile è minimo rispetto al costo associato alla gestione dei problemi che derivano dalla compromissione di dati riservati. Questo è il tipo di protezione che si intende fornire con la tecnologia BitLocker.

Le opinioni degli esperti
In questo articolo si illustra BitLocker da una prospettiva interessante. Personalmente non ho ancora provato a utilizzare la tecnologia BitLocker. Questa dichiarazione indurrà probabilmente molti utenti a fare commenti del tipo: come può esprimere un'opinione o scrivere qualcosa di utile su una tecnologia uno che non l'ha mai utilizzata? A chi è assalito dal dubbio, faccio presente quanto segue. Lo scopo principale dell'articolo è trattare la crittografia da una prospettiva più generale e illustrare le filosofie di progettazione che sono fondamentali per il successo di una soluzione.
Tutto è iniziato dopo aver letto il blog di Bruce Schneier. Si supponga ad esempio che al cinema venga proiettato un film che si desidera vedere. In base al trailer e agli attori principali del cast si sono già fatte alcune supposizioni sul film. È vero che un buon cast non è garanzia di un bel film. Tuttavia, l'elenco del cast può dire molto sul film e sulle proprie aspettative. Esiste un'alta probabilità che un film che prevede nel proprio cast attori di rilevo come Chris Rock e Ben Stiller o Kate Winslet e Johnny Depp non deluda le aspettative del proprio pubblico.
Allo stesso modo, quando ho visto che Bruce Schneier, considerato a livello internazionale un "guru" in materia di tecnologie di protezione, trattava di BitLocker sul suo blog, ho fatto alcune supposizioni. Innanzitutto, ho pensato che questa nuova tecnologia doveva essere o sufficientemente valida da meritare attenzione da parte di un personaggio così autorevole o così inutile da richiedere una divulgazione pubblica. Con mia grande sorpresa, il verdetto finale di Bruce Schneier è stato positivo.
Una frase in particolare mi ha colpito nella sua recensione: "Non esistono backdoor per la polizia". Questa affermazione racchiude in sé grande vigore. Mi ha colpito la certezza con cui è stata formulata. Nel suo articolo l'autore ha inoltre incluso un collegamento al blog di Microsoft® System Integrity Team. Ho seguito il collegamento e ho trovato un post di Niels Ferguson, uno sviluppatore Microsoft che opera nel settore della protezione, in cui venivano denunciate alcune voci speculative in base alle quali Microsoft aveva intenzionalmente incluso backdoor in BitLocker per ottemperare ai requisiti legali. Ferguson affermava che le backdoor sono inaccettabili e che non avrebbe mai partecipato a un progetto che prevedeva stratagemmi di questo tipo. Spiegava inoltre che, anche se Microsoft fosse stata obbligata dalle autorità competenti a includere una backdoor, la società lo avrebbe annunciato pubblicamente o avrebbe ritirato completamente la funzionalità dal mercato.
Il nome sul post, Niels Ferguson, spiega la fiducia riposta da Schneier in questa nuova tecnologia. E quel nome ha infuso una certa fiducia anche in me. Ferguson è un personaggio che sa il fatto suo e può vantare un curriculum di tutto rispetto che assicura l'elevato livello di attendibilità di ciò che dice. Bruce Schneier e Niels Ferguson sono coautori di Practical Cryptography (un libro che ha fatto scuola e in cui viene illustrato come applicare una tecnologia di crittografia efficace in modo semplice, corretto e sicuro) e co-progettisti della crittografia a blocchi, Twofish, una rete di Feistel a 128 bit conosciuta la sua robustezza alla crittoanalisi dopo essersi classificata come finalista nel processo di selezione del programma AES (Advanced Encryption Standard).
Ovviamente, la partecipazione a un progetto di un crittografo di grande esperienza non offre alcuna garanzia che il prodotto finale sarà sicuro. Anche i più esperti del settore possono talvolta mancare qualche colpo. Tuttavia, indipendentemente dagli sviluppi futuri di BitLocker, si può almeno confidare sul fatto che nella sua creazione hanno giocato un ruolo fondamentale efficaci strategie di progettazione.
Parlando di colpi mancati, si possono annoverare tentativi in buona fede degli sviluppatori che non dispongono di alcuna conoscenza in materia di crittografia e tentativi in cattiva fede degli sviluppatori che sono interessati semplicemente a lanciare sul mercato un prodotto. Entrambi i tentativi, indipendentemente dall'intento, sono destinati a dare risultati fallimentari nell'ambito della protezione. Nessuno dei due sembra, tuttavia, riguardare BitLocker. Il coinvolgimento almeno di un crittografo esperto e l'utilizzo di un'ampia gamma di risorse a supporto dello "sforzo" promette bene.

Qualche parola sulla fiducia
Non molto tempo fa, Phil Zimmerman, creatore della crittografia PGP, ha condiviso con me alcune regole generali. Se dovesse mai essere pubblicato un libro su un credo per gli sviluppatori in materia di protezione, il suo consiglio dovrebbe essere collocato in cima alle preferenze. Sebbene le sue considerazioni non riguardino specificamente la tecnologia BitLocker, le filosofie di progettazione che tali considerazioni promuovono possono essere applicate a qualsiasi soluzione di crittografia. Le sue argomentazioni potrebbero essere considerate ovvie o eccessivamente zelanti. Tuttavia, considerato lo stato della protezione oggi, vale la pena farne esplicita menzione.
Durante la progettazione di un'infrastruttura di crittografia, lo sviluppatore deve sempre aderire ai principi di semplicità, correttezza e protezione. Sebbene gli errori siano inevitabili, non devono essere accettati come un evento naturale e semplicemente minimizzati. Lo sviluppatore deve essere un convinto difensore di un meticoloso perfezionismo. Secondo Zimmerman, "progettare partendo dal presupposto che il minimo errore può costare la vita a un uomo". Un'esagerazione? Alla conferenza annuale sulle applicazioni per la protezione dei computer del 2005, il crittografo della NSA Brian Snow (che da allora si è ritirato) disse: "Funzioni e garanzie sono le due caratteristiche che cerco in un dispositivo di protezione. Noi non facciamo beta test presso il cliente. Se il prodotto fallisse, qualcuno potrebbe rimetterci la vita". Il costo di un errore non può, quindi, essere misurato solo in termini monetari.
Gli utenti meritano sicurezza. Guadagnarsi e mantenere la fiducia degli utenti è fondamentale. Zimmerman esprime questo concetto molto chiaramente quando afferma: "Guadagnati la fiducia degli utenti. Una volta assunta questa responsabilità, non puoi più tirarti indietro". Agendo in base a questo principio, l'azienda rafforzerà la fiducia dell'utente nei propri confronti e la propria reputazione come azienda attendibile. Se il rapporto di fiducia viene meno, non sarà più possibile recuperarlo.
Queste sono prospettive che spero Microsoft abbia tenuto in considerazione durante la progettazione di BitLocker (o qualsiasi altro prodotto per la protezione). Dopo la premessa, devo spiegare perché sono ottimista sull'adozione da parte di Microsoft del giusto comportamento e sulla creazione di una tecnologia di crittografia da prendere sul serio.

Autenticazione semplificata ed Elephant
Essenzialmente, BitLocker rappresenta la tecnica con cui Windows Vista (in particolare le edizioni Enterprise e Ultimate) garantisce la crittografia di tutti i dati del volume di sistema. Da questo punto di vista, l'applicazione potrebbe sembrare piuttosto semplice; occorre tuttavia prendere in considerazioni i vincoli dello strumento. Poiché BitLocker garantisce la crittografia dei dati a livello di settore e il testo crittografato non può superare la lunghezza del testo normale, questo limite non lascia spazio sufficiente per l'utilizzo di altri meccanismi come nonce (un numero o una stringa utilizzata una sola volta per l'autenticazione), il vettore di inizializzazione (IV) o il codice MAC (Message Authentication Code). Ho anticipato che erano probabili vincoli così rigidi e le condizioni imposte di conseguenza, ma nello stesso tempo sapevo che l'autenticazione dei messaggi sarebbe stata in un modo o nell'altro affrontata.
BitLocker si basa su un'autenticazione semplificata. Il compromesso su cui si basa non è affatto moderato poiché presuppone che il testo crittografato manipolato non dà come risultato testo normale significativo. In altre parole, se manipolato, il testo crittografato dovrebbe, ad esempio, causare un arresto anomalo del sistema anziché consentire a un utente malintenzionato di eseguire una funzione.
Il team Microsoft responsabile della tecnologia BitLocker era consapevole del fatto che l'analisi di una crittografia a blocchi completamente nuova avrebbe richiesto tempi eccessivamente lunghi, ma le progettazioni esistenti o non erano state analizzate in modo adeguato oppure non erano sufficientemente efficienti. Pertanto, per la crittografia, Microsoft ha scelto AES in modalità CBC (Cipher Block Chaining) a cui in questo articolo si farà riferimento come AES-CBC. Questo meccanismo è indistinguibile nell'ambito del modello di attacco chosen plaintext (abbreviato in IND-CPA) ma non garantisce l'integrità. Inoltre, poiché non viene fornito il supporto per il codice MAC e CBC è una modalità di riservatezza, non esiste alcuna garanzia di integrità. A questo proposito entra in gioco Elephant.
Il nuovo componente Elephant fornisce due diffusori progettati per ottenere un'autenticazione semplificata più efficace rispetto all'utilizzo del normale meccanismo AES-CBC. È tuttavia disponibile un'opzione che consente di eseguire AES-CBC senza Elephant per coloro che devono rispettare rigorosi criteri di conformità agli standard. Sebbene non sia sempre la soluzione ideale, considerati i vincoli, l'autenticazione semplificata rappresenta la soluzione più appropriata ed Elephant mira a sfruttarne al massimo le potenzialità. Come funziona esattamente?
Nella Figura 1 è illustrato il funzionamento del meccanismo. Quando viene eseguita la crittografia, il testo non crittografato viene combinato, tramite XOR, con una chiave settore. Il testo viene quindi trasmesso attraverso due diffusori senza chiave. Nei diffusori il testo viene codificato con AES-CBC. La chiave settore e AES-CBC richiedono entrambi il materiale della chiave e pertanto sono dotati in modo indipendente di chiavi. Con questo metodo si semplifica la formalizzazione di una prova per la riduzione del livello di protezione garantito dalla combinazione di AES-CBC ed Elephant al solo AES-CBC. Elephant è una nuova primitiva e le nuove primitive possono essere accolte con riluttanza fino a quando non vengono rigorosamente analizzate. Tuttavia, questo approccio consente di trovare il giusto equilibrio, poiché BitLocker può mostrare che l'utilizzo congiunto di AES-CBC ed Elephant garantisce una minore vulnerabilità ad attacchi rispetto all'utilizzo del solo meccanismo AES-CBC.
Figura 1 Autenticazione semplificata con Elephant
Figura 1 Autenticazione semplificata con Elephant
La chiave settore e i componenti AES-CBC ricevono 256 bit di materiale della chiave, determinando una lunghezza della chiave di 512 bit. Per impostazione predefinita, tuttavia, ciascuno di questi componenti utilizza solo 128 bit di materiale della chiave, vale a dire che una parte del materiale della chiave non viene utilizzato. La ragione di ciò risiede semplicemente nel fatto che è più semplice rimuovere i bit non necessari che modificare l'infrastruttura di gestione delle chiavi man mano che la lunghezza della chiavi cambia.
La lunghezza del blocco può essere pari a qualsiasi potenza di due, nell'intervallo compreso tra 512 e 8192 byte. Per garantire che un'eventuale manipolazione del testo crittografato determini la modifica casuale di tutto il testo normale di un settore, la crittografia a blocchi è progettata per soddisfare le esigenze di contesti con dimensioni di blocchi variabili. Inoltre, se si comporta come una crittografia a blocchi modificabile (come illustrato da Liskov, Rivest e Wagner), in cui l'algoritmo si modifica lievemente da un settore all'altro, un avversario non potrà spostare il testo crittografato di un settore in un altro settore.

Solo il tempo darà il verdetto finale
Le congetture sulla protezione crittografica di BitLocker non sono ancora inserite in un quadro più ampio. Per BitLocker, garantire una protezione valida non è necessariamente sufficiente perché questa tecnologia possa assolvere alla sua funzione. La ragione sta nel fatto che BitLocker non è una soluzione in se stessa, ma una delle tante appendici di Windows Vista. Secondo quanto afferma Microsoft, BitLocker è una funzionalità strettamente integrata in Windows Vista. Tuttavia, se esiste questa stretta integrazione con il sistema operativo, non è plausibile pensare che l'errore di un componente possa, a propria volta, causare il malfunzionamento o la compromissione di BitLocker?
Personalmente, credo nella modularità e nell'errore isolato. Una stretta integrazione senza modularità conduce alla complessità. Questo potrebbe non accadere con Windows Vista e BitLocker, ma solo il tempo, e un'analisi estesa, lo potranno confermare o smentire.
Cosa penso dunque di BitLocker? Apprezzo molto il progetto del Microsoft System Integrity Team per aver fatto affidamento su crittografi di tutto rispetto, che hanno operato con la massima professionalità. È ovvio che questa funzionalità è stata progettata per la crittografia e non per una campagna di marketing. Pertanto la mia risposta alla suddetta domanda è che BitLocker è una tecnologia da prendere sul serio. Questa affermazione non è un verdetto sulla capacità della tecnologia di garantire una protezione valida. Anche in questo caso, solo il tempo e la valutazione nel mondo reale potranno dare una risposta. Molti protocolli e primitive di crittografia non vengono più utilizzati. Ma, come minimo, il progetto Microsoft System Integrity Team ci ha fornito le conoscenze e le piattaforme su cui basare soluzioni anche migliori.

Justin Troutman è un crittografo e studente universitario di matematica. Il principale centro di interesse della sua attività è rappresentato dalla crittografia simmetrica. È inoltre il fondatore di Extorque, una società specializzata nella ricerca e nella consulenza crittografica.


 Desktop file: Guida per utenti esperti su WIM e ImageX
Desktop file
Guida per utenti esperti su WIM e ImageX
Wes Miller
Questo articolo è basato su una versione non definitiva di Windows Automated Installation Kit (WAIK) e Windows Server 2008. Tutte le informazioni riportate sono soggette a modifica.

La tecnologia ImageX e il formato WIM (Windows Imaging) sono stati illustrati in molti articoli precedenti. In Tech•Ed alcuni mesi fa ho avuto modo di ascoltare alcuni commenti e domande di professionisti IT che avevano iniziato a utilizzare Windows Deployment Services (WDS), ImageX e Windows Automated Installation Kit (WAIK) che mi hanno fatto riflettere sulla
necessità di maggiori delucidazioni in merito a questi argomenti. Nell'articolo di questo mese l'attenzione verrà pertanto focalizzata principalmente su ImageX e sul formato WIM e verrà illustrato come sfruttare al meglio queste tecnologie. ImageX e WIM consentono di semplificare la distribuzione sono solo di Windows Vista® e Windows Server® 2008, ma anche di Windows® XP, Windows Server 2003 e Windows 2000.

Modifiche apportate a WAIK
È possibile che molti utenti si domandino quali siano le implicazioni del rilascio della nuova versione di Windows Server 2008, disponibile a breve, per WAIK. Microsoft intende distribuire una versione aggiornata di WAIK nell'intervallo di tempo previsto per il rilascio della prossima versione di Windows Server 2008. Non sono previste modifiche significative al formato WIM (lo strumento ImageX e il formato restano invariati); anche WDS per Windows Server 2003 non subirà alcuna modifica. Contrariamente alle voci che corrono, il multicast non sarà disponibile per i server WDS che eseguono Windows Server 2003; solo i server WDS che eseguono Windows Server 2008 disporranno della nuova funzionalità di distribuzione multicast per WDS.
Windows PE 2.0 e il programma di installazione di Windows verranno modificati in modo da garantire il supporto per quanto riportato di seguito:
  • Distribuzione di Windows Server 2008 e Windows Vista
  • Distribuzione multicast tramite WDS da un server WDS per Windows Server 2008
  • Distribuzione delle versioni x64 e x86 di Windows Vista e Windows Server 2008 da Windows PE x86.
Innanzitutto, questo implica che Windows PE 2.0 sarà in grado di distribuire Windows Server 2008 con la stessa facilità con cui garantisce la distribuzione di Windows Vista: per entrambi i tipi di distribuzione è possibile utilizzare gli stessi strumenti e processi. Secondo, una volta installato Windows Server 2008 nei server WDS, sarà possibile utilizzare la distribuzione multicast tramite WDS. Infine, questo supporto implica la possibilità di utilizzare un disco di Windows PE 2.0 x86 e distribuire da tale disco un'immagine x86 o x64 di Windows.
Ho menzionato quest'ultimo punto in Tech•Ed nella mia sessione su Windows x64. Sfortunatamente sembra esistere molta confusione su questo punto nei blog e nella community tecnica di Windows. Questo non significa che Microsoft distribuirà Windows x64 e Windows x86 su ogni DVD di Windows Vista o Windows Server 2008, né che è necessario combinare le immagini di Windows x64 e Windows x86 in un singolo file WIM (sebbene sia possibile). L'esecuzione di un'operazione di questo tipo, sebbene consenta di trasmettere il formato WIM come un singolo file, non consentirà di realizzare alcun risparmio in termini di archiviazione a istanza singola.
L'implicazione più significativa di questo supporto è rappresentata dal fatto che i clienti aziendali e gli OEM che hanno dedicato anni allo sviluppo di processi di distribuzione basati su 86 (oltre che di strumenti e script personalizzati) ora saranno in grado di distribuire Windows x86 o x64 dall'interno di WIM mediante il programma di installazione a 32 bit, venendo incontro in tal modo a una richiesta avanzata dai clienti aziendali sin da quando Windows x64 è stato rilasciato per la prima volta nel 2005.

Esecuzione di attività quotidiane con ImageX
Utilizzo di /mount, /mountrw e /delete
Di seguito sono riportati alcuni importanti suggerimenti per l'utilizzo delle opzioni /mount, /mountrw e /delete con ImageX:
  • Montare un volume con /mountrw se si intende modificarlo.
  • È consigliabile montare un file WIM in una directory vuota, semplicemente per eliminare eventuali confusioni dai file archiviati in tale directory e impedire che in ImageX venga generato un messaggio di avviso non necessario.
  • Ricordare inoltre di utilizzare i comandi /unmount /commit per eseguire il montaggio o il commit delle immagini di lettura/scrittura nel caso in cui si desideri salvare le modifiche apportate. Mi è capitato di frequente di aver apportato delle modifiche ma di aver dimenticato di eseguirne il commit (e di conseguenza le modifiche sono andate perse).
  • L'eliminazione di file tramite /mountrw e di immagini del volume tramite /delete non consentirà di risparmiare spazio, ma al contrario potrebbe richiedere l'utilizzo di una maggiore quantità di spazio. Per ulteriori dettagli, vedere la sezione di questo articolo relativa a /export.
  • È possibile montare un singolo file WIM una sola volta per l'accesso in lettura/scrittura. Due utenti non possono modificare lo stesso file WIM contemporaneamente così come non è possibile modificare contemporaneamente due immagini del volume.
  • Anche in modalità di sola lettura (/mount), è consigliabile limitare il numero di immagini del volume montate simultaneamente in quanto il driver è dipendente dalla quantità di memoria del pool non di paging di Windows disponibile nel sistema per ciascuna immagine montata. Questo introduce una limitazione sul numero di immagini da utilizzare, che potrebbe variare in base al sistema (o all'architettura del sistema). È consigliabile non tentare di utilizzare più di cinque immagini contemporaneamente.
  • L'esecuzione di modifiche significative tramite /mountrw richiede pochissimo tempo, mentre il commit delle modifiche apportate tramite /commit potrebbe richiedere una notevole quantità di tempo in quanto è necessario comprimere e archiviare tutti i nuovi dati dei file.
  • Prestare particolare attenzione quando si utilizzano /delete e /mountrw in quanto, una volta eseguito il commit delle modifiche, non è possibile annullarle.
  • Non è possibile eseguire /delete se è presente una sola immagine del volume in un file WIM (è possibile invece eliminare l'intero file WIM o aggiungere un'altra immagine del volume).
  • Per ottenere rapidamente una struttura di directory del contenuto di un'immagine del volume, utilizzare in luogo di /mount il seguente comando:
ImageX /dir <path_to_wim_file> <image index>
  • Se si stanno modificando due file WIM contemporaneamente, è consigliabile non eseguirne lo smontaggio contemporaneamente tramite /unmount; organizzare in sequenza gli eventi di montaggio/smontaggio in modo che non si blocchino reciprocamente.

ImageX è stato progettato specificatamente per effettuare il mirroring della modalità di utilizzo degli strumenti da parte di OEM e clienti aziendali. Il processo viene descritto nella Figura 1.
Figura 1 Utilizzo di ImageX
Figura 1 Utilizzo di ImageX
Notare che il passaggio 5 riveste un'importanza fondamentale in quanto mette in rilievo che un'immagine viene modificata continuamente. È necessario pertanto che le operazioni di acquisizione e modifica dell'immagine vengano eseguite nel modo più rapido e semplice possibile.
A tal fine, è possibile aggiungere un'ulteriore immagine (mediante l'opzione /append) all'immagine già creata. Inizialmente, il team di sviluppo pensò che fosse utile poter aggiungere un'ulteriore SKU (versione di Windows) all'immagine precedente; tuttavia, collaborando a stretto contatto con i clienti aziendali nelle fasi iniziali del processo di sviluppo di Windows Vista, ho avuto modo di scoprire che l'immagine aggiuntiva veniva utilizzata per distribuire rapidamente X e successivamente acquisire di nuovo X1 in cui si erano apportate alcune delle modifiche riportate nel passaggio 2. Era dunque possibile riacquisire rapidamente l'immagine, poiché si era modificato solo un numero limitato di file.
Quando il team comprese questo, giunse alla conclusione che conservare l'immagine originale poteva non essere utile in tutti i tipi di situazioni. Più avanti in questo articolo verrà illustrata l'opzione /export che è stata aggiunta specificamente per soddisfare le esigenze di questo scenario e di quello successivo.

Modifiche costanti
Il team di sviluppo decise immediatamente che era necessario che i file WIM fossero modificabili. Poiché aveva già deciso che un formato di imaging basato su settore non avrebbe funzionato (per un'eventuale spiegazione vedere l'articolo di dicembre all'indirizzo technetmagazine.com/issues/2006/12/DesktopFiles), il team si trovò di fronte alla necessità di fornire una soluzione che consentisse di montare facilmente i file in modo nativo come parte del file system di Windows e apportare modifiche alle immagini del volume montate nel file WIM. Questo ha avuto come conseguenza la disponibilità di un maggior numero di "componenti mobili", come amo definirli. Il montaggio di un'immagine basata su settore è relativamente semplice, mentre il montaggio di un formato di archiviazione proprietario, come WIM, ha richiesto l'utilizzo di strumenti molto specifici.
Il formato richiedeva l'accesso dal prompt dei comandi, escludendo le estensioni shell di Windows comunemente utilizzate per gestire i file ZIP e CAB in modo nativo. Sfortunatamente, questi gestori consentono solo a Esplora risorse l'accesso astratto a un oggetto.
Di conseguenza, la soluzione WIM prevede un driver (wimfltr.sys) e lo strumento ImageX, che viene utilizzato per caricare il driver e gestire l'interfaccia per il montaggio del file WIM. Il driver viene utilizzato per aggiungere un'astrazione al file system di Windows, come illustrato nella Figura 2. Quando si esegue un comando come uno di quelli riportati di seguito, si indica a ImageX di caricare il driver wimfltr.sys e di impostare il driver in modo che si sovrapponga alla prima immagine del volume (corrispondente a 1 nei comandi utilizzati in questo articolo) nella directory di montaggio vuota, come illustrato di seguito:
Figura 2 Montaggio di un'immagine del volume WIM
Figura 2 Montaggio di un'immagine del volume WIM
ImageX /mount iso\sources\boot.wim 1 mount
ImageX /mountrw iso\sources\boot.wim 1 mount
Questo è il comportamento predefinito in WAIK. Pertanto, quando si esplora o si genera un elenco di directory nella directory di montaggio, è possibile visualizzare la directory radice dell'immagine del volume 1 in boot.wim. Naturalmente, l'utilizzo di /mountrw o /mount determinerà se questa directory è di sola lettura o di lettura/scrittura (per informazioni dettagliate vedere l'intestazione laterale "Utilizzo di /mount, /mountrw e /delete").
La funzionalità /mountrw è stata originariamente progettata per aggiungere con facilità driver e altri file o contenuti copiabili, impostare i file di risposta o modificare il Registro di sistema non in linea di un file WIM montato per modificarlo in base alle esigenze (vedere la Figura 3). Non è stata progettata per aggiungere o rimuovere intere applicazioni (in quanto le applicazioni installate in MSI non possono essere installate in modalità non in linea).
Figura 3 Modifica di un file WIM montato
Figura 3 Modifica di un file WIM montato
È fondamentale capire che quando si apportano modifiche al file WIM dopo che è stato montato, non si modifica direttamente il file WIM effettivo (almeno non immediatamente) ma si modifica una cache del file WIM che rappresenta in realtà un'unione della sovrapposizione e delle modifiche apportate. Sono stato colpito da questo in precedenza, come illustrato nell'intestazione laterale. Assicurarsi di utilizzare, dopo aver apportato le modifiche, le opzioni /unmount e /commit, in quanto solo in tal caso verrà eseguito il commit delle modifiche nel file WIM. In caso contrario, le modifiche andranno completamente perse.
Quando si salvano le modifiche apportate grazie al commit, si indica al driver di eseguire le modifiche nello stesso file WIM. Il driver aggiunge i nuovi dati dei file. Tenere presente che se si sono apportate numerose modifiche, il commit potrebbe richiedere una significativa quantità di tempo, in quanto l'aggiunta dei dati dei file al file WIM viene eseguita solo nel corso di tale operazione.
Inoltre, a differenza del formato di imaging basato su settore, è possibile che si sia modificato solo uno o più file nell'immagine del volume. Di conseguenza, i file non si presentano più nel formato a istanza singola (a meno che non siano già stati memorizzati una volta) e i dati dei file originali andranno persi. In WIM, a differenza del volume NTFS o FAT, un file non viene contrassegnato come eliminato; sebbene non vi venga più fatto riferimento, il file non viene eliminato. Di conseguenza, se si apportano modifiche frequenti tramite /mountrw o si aggiungono numerose immagini tramite /append oppure si utilizza /delete per eliminare un'immagine del volume, questa operazione consente al file WIM solo di ignorare i riferimenti ai dati dei file, ma non determina l'eliminazione dei dati dei file correlati.
Pertanto il team di sviluppo ha creato l'opzione /export, nota anche come "utilità di deframmentazione WIM".

Esportazione
Note importanti per /export
Quando l'opzione /export viene utilizzata per creare un nuovo file WIM, è possibile specificare il tipo di compressione da utilizzare anziché accettare il tipo di compressione predefinito correntemente utilizzato. Se si imposta un tipo di compressione differente da quello correntemente utilizzato, l'esportazione potrebbe richiedere una notevole quantità di tempo.
Quando utilizzata come /append (aggiungendo un'immagine del volume a un file WIM esistente), l'opzione /export non consente di modificare l'attributo /compression del file WIM.
È possibile specificare l'opzione /boot se si esporta un'immagine del volume di Windows PE 2.0 completamente nuova.

L'opzione /export è stata creata per soddisfare le esigenze di entrambi gli scenari menzionati in precedenza e un paio di altri scenari meno comuni scoperti dal team. In poche parole, /export consente di acquisire un'immagine del volume esistente (o anche più immagini) e di esportarla. Il risultato è la rapida acquisizione del file WIM X e X1 sopra riportato e la creazione di un nuovo file WIM contenente X, solo X1 o X1 e Y1, eseguendo l'esportazione da un altro file WIM.
Si immagini uno scenario in cui vengono apportate modifiche a X e tali modifiche vengono aggiunte tramite /append come X1. A un certo punto si decide di eliminare X in quanto la si è sostituita con una nuova immagine. È possibile utilizzare l'opzione /delete in modo da rimuovere l'immagine X da ImageX. Tuttavia, per risparmiare spazio eliminando tutte le informazioni correlate all'immagine X, occorre eseguire il seguente comando:
ImageX /export source.wim 2 destination.wim "New image for Q4CY07"
Questo comando consentirà di esportare la seconda immagine del volume in un nuovo file WIM con il nuovo nome, eliminando completamente le informazioni precedenti dall'immagine del volume 1. È inoltre possibile eseguire l'esportazione dalle immagini WIM con spanning se si desidera riassemblarle in un singolo file WIM (come verrà illustrato più avanti in questo articolo). Le immagini con spanning non possono essere modificate tramite /mountrw, uno dei motivi per cui è consigliabile riassemblarle. È importante notare che ImageX non prevede alcun comando /import in quanto /export consente di creare nuovi file WIM o di aggiungerli a quelli esistenti. Per ulteriori informazioni su questo argomento, vedere l'intestazione laterale "Note importanti per /export".
Questa opzione è fondamentale anche nel caso in cui si esegua peimg /prep: sebbene consenta di preparare l'immagine Windows PE da utilizzare, questo comando non determina l'eliminazione di alcuna informazione da WIM. L'ideale sarebbe preparare, nel corso del processo di rilascio di Windows PE, l'immagine ed esportarla in un nuovo file boot.wim. Tenere presente che il processo di avvio cerca il file WIM solo in \sources\boot.wim; assicurarsi pertanto di assegnare al file il nome corretto e che il file venga contrassegnato come immagine del volume di avvio.
Come menzionato in precedenza, è consigliabile ottimizzare le immagini eseguendo il comando /export quando si è pronti per rimuovere le autorizzazioni per le immagini del volume obsolete o combinare insieme più immagini. È opportuno inoltre eseguire questa operazione se si sono apportate numerose modifiche tramite /mountrw o /delete. In caso contrario, col passare del tempo il file WIM continuerà ad aumentare di dimensioni (in modi misteriosi che non si è in grado di diagnosticare). Se si utilizza /mountrw o /delete a intervalli regolari, valutare l'opportunità di aggiungere /export nel flusso di lavoro per assicurare che le immagini siano completamente ottimizzate.

Spanning
Un altro problema a cui il team ha dovuto immediatamente far fronte è stata la probabile necessità di adattare i file WIM alle dimensioni di più supporti scrivibili. Come anticipato, Windows verrà distribuito su più CD (e potenzialmente su più DVD), il che ha determinato la necessità per WIM e ImageX di fornire il supporto per lo spanning.
Come menzionato in precedenza, un'immagine con spanning creata tramite /split è in sostanza un'immagine di sola lettura; l'immagine non può essere acquisita tramite /capture direttamente in una nuova immagine con spanning, non può essere montata tramite ImageX né aggiunta a un'immagine esistente mediante /append. Di conseguenza, è consigliabile suddividere il file WIM solo dopo aver utilizzato il flusso di lavoro standard e quando si è pronti per il rilascio. In altre parole, apportare tutte le modifiche desiderate al normale file WIM e valutare l'opportunità di utilizzare la suddivisione come parte del processo di rilascio per lo scenario di distribuzione.
Per quanto riguarda l'applicazione dell'immagine, l'utilizzo di immagini con spanning può dar luogo a non poche difficoltà. È consigliabile utilizzare ImageX anziché il programma di installazione quando si utilizzano immagini con spanning. È opportuno inoltre applicare le immagini in rete (per ottenere prestazioni ottimali senza eseguire l'imaging del disco da cui si sta applicando l'immagine) o copiarle direttamente nell'unità e successivamente applicarle (tenere presente che si sarà vincolati al disco in quanto durante la fase di applicazione il disco esegue le operazioni di lettura e scrittura su se stesso).

Verifica della validità
Quando si utilizza ImageX, si sposta una notevole quantità di dati molto importanti. Una domanda che quest'anno è stata posta di frequente in Tech•Ed riguardava la necessità di disporre di un metodo appropriato per assicurare che le immagini siano valide. Non si tratta certo di un'operazione semplice ma in realtà non è neppure estremamente complessa.
L'aspetto principale da tenere presente riguardo a WIM è che, come la maggior parte dei formati di archiviazione, è soggetto a danneggiamento. Un file WIM viene in genere danneggiato quando viene trasmesso in rete. In Windows Vista si sono rilevati da subito problemi specifici con determinate schede di rete: se i pacchetti venivano ignorati, il file WIM si danneggiava e non era sempre semplice diagnosticare la causa di questo danneggiamento. Questa situazione era quasi identica a quanto si era verificato alcuni anni prima quando il file driver.cab era aumentato di dimensioni; anche in tal caso si era assistito a un danneggiamento casuale molto simile. In generale, se vengono visualizzati report relativi a immagini non valide o a errori di installazione, è consigliabile verificare il tipo di NIC in uso nei sistemi su cui vengono generati i report. È opportuno seguire questa procedura sia che si utilizzi ImageX da solo sia che si esegua WDS.
In che modo quindi è possibile verificare se un'immagine sia valida o meno? Innanzitutto, è possibile utilizzare l'opzione /check. Questa opzione consente di evitare ulteriori controlli di integrità nel file WIM e di verificare, prima dell'applicazione, che il file WIM non sia stato danneggiato. Assicurarsi di eseguire /check anche in fase di applicazione in modo che l'immagine venga convalidata (questa operazione potrebbe richiedere più tempo).
Inoltre, in caso di problemi o semplicemente per meticolosità, è possibile eseguire un'utilità hash sui file prima dell'acquisizione e dopo l'applicazione. È possibile eseguire la verifica anche dopo l'acquisizione montando l'immagine e generando un nuovo hash: un metodo efficace per assicurare che un'immagine sia stata acquisita in modo corretto.
È probabile che si desideri assicurarsi che le immagini siano state acquisite in modo corretto dall'inizio. L'opzione /check e lo stesso formato sono stati progettati come punti di controllo non come punti di ripristino per ripristinare un 'immagine acquisita in modo non corretto.

Avvio e flag
In precedenza si è affermato che è possibile utilizzare /boot per acquisire un'immagine del volume WIM di Windows PE e avviarla. Occorre pensare a questa opzione come un settore di avvio su una specifica immagine del volume. questo settore di avvio può essere presente solo su una singola immagine del volume per ogni file WIM ed è valido solo per Windows PE 2.0. Tenere presente che non è possibile eseguire l'avvio di Windows PE 1.x da WIM.
È possibile che nelle immagini del volume di Windows siano presenti riferimenti ai flag. I flag vengono utilizzati solo dal programma di installazione di Windows. Un flag su un'immagine del volume 2 indica che un'immagine del volume contiene Windows PE e il programma di installazione. Un flag 9 indica che l'immagine del volume contiene solo Windows PE. Qualsiasi altro flag o la mancanza di un flag indica che l'immagine non verrà e non può essere utilizzata dal programma di installazione. Tenere presente che è possibile impostare i flag su un'immagine dopo che è stata acquisita utilizzando ImageX per modificarli. È consigliabile utilizzare WAIK (e se necessario Business Desktop Deployment Solution Accelerator) per creare l'immagine di avvio WIM di Windows PE, in modo da impostare correttamente i flag.

Nota per gli utenti di HTA
Di recente ho sentito parlare di alcuni report relativi a problemi correlati all'esecuzione dei file HTA su Windows PE 2.0. Sfortunatamente sembra che si verifichi un errore durante l'esecuzione dei file HTA che contengono script significativi. Nella Figura 4, dare un'occhiata alla schermata del file di esempio creato e prendere nota dell'errore di script (senza informazioni) restituito. Questo problema è stato segnalato da diversi clienti e io stesso ho avuto modo di sperimentarlo.
Figura 4 Errore di script HTA
Figura 4 Errore di script HTA
Per fortuna il problema può essere risolto con facilità. Durante la fase di preparazione dell'immagine, aggiungere il supporto XML e il supporto HTA. La dipendenza mancante nel componente HTA è inclusa nel modulo aggiuntivo XML, risolvendo pertanto il problema.
Vorrei ringraziare per l'aiuto alla realizzazione di questo articolo Bruce Green, sviluppatore ImageX, e Minxiao Zhou e Raja Ganjikunta del team per il test della distribuzione di Windows.

Wes Miller è un responsabile di 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: Riciclaggio dei computer
Taccuino
Riciclaggio dei computer
Jim Lynch

Il programma Community Microsoft Authorized Refurbisher (MAR) (microsoft.com/mar) è un progetto straordinario e relativamente poco conosciuto dell'iniziativa Microsoft Unlimited Potential, in cui Microsoft supporta diversi progetti volti a migliorare i sistemi educativi, creare imprese e nuove opportunità di lavoro e generare opportunità economiche sostenibili per la maggior parte delle comunità più svantaggiate. Avviato nel 2000 nel Regno Unito, il programma Community MAR ora è composto da oltre 800 organizzazioni per la rigenerazione di computer in 50 paesi in tutto il mondo.
Uno degli aspetti più straordinari del programma Community MAR è rappresentata dalla capacità di fornire licenze per Windows® 2000 e Windows XP al costo di soli 5 dollari statunitensi. Il programma rende disponibile queste licenze, oltre 200.000 l'anno, per PC riciclati a organizzazioni no-profit, scuole, biblioteche, università e, negli Stati Uniti, fornisce programmi di accesso alle tecnologie a individui con reddito basso o disabili. L'obiettivo principale del programma Community MAR è fornire a chi sta dal lato sbagliato del "digital divide" accesso a opportunità didattiche e professionali.
Allo scopo di raggiungere i bambini più poveri, le organizzazioni Community MAR si espandono in tutto il mondo. Ad esempio, Operation Homelink fornisce computer alla famiglie di militari degli Stati Uniti a basso reddito; Computer Aid International nel Regno Unito è la più grande organizzazione non governativa che fornisce computer alle popolazioni africane; la rete di organizzazioni per la rigenerazione di PC Computers for Schools Canada fornisce una significativa parte dei computer donati alle scuole canadesi.
Valore del riutilizzo
L'agenzia degli Stati Uniti Environmental Protection Agency (EPA) in cooperazione con l'università del Tennessee ha di recente dimostrato il valore del riutilizzo dei dispositivi elettronici in termini di energia, materiali, anidride carbonica2ed emissioni tossiche. Avvalendosi dello strumento Electronics Environmental Benefits Calculator (eerc.ra.utk.edu/ccpct/eebc/eebc.html), l'agenzia ha dimostrato che il riutilizzo di un solo computer con un monitor CRT consente un risparmio di:
  • 13 kg di rifiuti pericolosi
  • 35 kg di rifiuti solidi
  • 35 kg di materiali
  • 80 litri di acqua inquinata
  • 32 tonnellate di aria inquinata
  • 605 kg di anidride carbonica2 in termini di emissioni
  • 7.719 chilowatt di energia

Infatti, il programma Community MAR è stato fondato nel 2000 per aumentare il flusso delle apparecchiature verso scuole e organizzazioni di beneficenza degli Stati Uniti che avevano tradizionalmente accesso limitato alla tecnologia. Il programma si è esteso nel 2003 a Stati Uniti e Australia e ha raggiunto la fama mondiale attuale nel 2005. Ora è disponibile a tutti i tipi di organizzazioni che si occupano del riciclaggio di PC (organizzazioni commerciali, non commerciali, governative e didattiche). Col tempo ha anche promosso la creazione di una vivace industria per il riciclaggio e il riutilizzo di computer.
Uno dei vantaggi meno ovvi del programma Community MAR è rappresentato dalla riduzione dei rischi in termini di ambiente. Il prolungamento del ciclo di vita delle apparecchiature elettroniche rappresenta la forma più efficiente di riciclaggio in quanto consente di mantenere tutte le potenzialità di un dispositivo e creare le massime opportunità di guadagno in termini economici, ambientali e sociali. Il riciclaggio di dispositivi al termine del ciclo di vita è certamente efficiente e necessario ma determina una perdita del 10-30% di materiali ed energia in ciascun elemento.
Non è una sorpresa il fatto che la produzione di computer abbia un costo enorme in termini di impatto ambientale. Secondo lo scienziato ambientale Eric D. Williams dell'Arizona State University, la produzione di un normale computer desktop con monitor dal peso di 24 chilogrammi richiede 240 kg di combustibile fossile, 23 kg di sostanze chimiche e 1.512 kg di acqua. Il prolungamento del ciclo di vita di un computer di due o tre anni consente di risparmiare una quantità di energia superiore da 5 a 20 volte rispetto a quella risparmiata con il riciclaggio al termine del ciclo di vita (per un elenco di cifre ancora più sorprendenti, vedere l'intestazione laterale "Valore del riutilizzo).
Nel complesso, attraverso questo innovativo programma, Microsoft consente di creare opportunità in grado di trasformare le comunità mettendo a disposizione delle popolazioni più bisognose i vantaggi della tecnologia. Un ulteriore sorprendente vantaggio del programma Community MAR è rappresentato dalla capacità di accrescere il supporto e la consapevolezza pubblica per il riutilizzo dei computer.

Jim Lynchè Program Director per il riciclaggio e il riutilizzo di computer presso TechSoup.org, una società senza scopo di lucro di San Francisco la cui missione è fornire hardware e software a basso costo oltre che conoscenze tecnologiche a organizzazioni di beneficenza in tutto il mondo.


 Windows Confidential: Quando arriva il Dr. Watson
Windows Confidential
Quando arriva il Dr. Watson
Raymond Chen

Qualcuno avrà notato che se si chiede al Dr. Watson (drwtsn32.exe) di estrarre un'immagine della memoria del processo Winlogon, Windows® viene chiuso non appena termina l'operazione. Alcuni si domandano: perché la connessione di un debugger a Winlogon provoca l'arresto del sistema?
Ma questo accade solo in apparenza. L'esecuzione di Dr. Watson su un processo non equivale a connettere un debugger a un processo. La connessione di un debugger prevede l'impiego di uno strumento simile a ntsd, procedimento che consente di ottenere i risultati desiderati, sempre che si disponga dei privilegi necessari. Questo è il modo in cui il team Windows esegue il debug con Winlogon. Quindi la risposta letterale alla domanda è che la connessione di un debugger a Winlogon non provoca l'arresto del sistema.
Ma il Dr. Watson è solo un analista, non un medico, e si limita a estrarre un'immagine della memoria di un processo che presenta dei problemi per poi interrompere il processo. Poiché Dr. Watson non tenta di risolvere effettivamente il problema, se si lasciasse continuare l'esecuzione del processo, si verificherebbe di nuovo il medesimo arresto anomalo. Sarebbe quindi necessario far intervenire di nuovo il dottore e così via, in un ciclo infinito. In un certo senso Dr. Watson è un debugger che non esegue un reale debug. Il bravo dottore si limita ad apparire sulla scena, prendere nota dell'accaduto ed eliminare il processo. È proprio questa operazione, ovvero l'eliminazione di Winlogon dopo l'estrazione dell'immagine della memoria, che provoca l'arresto anomalo del sistema.
Se si elimina Winlogon, il sistema si riavvia
Se si elimina Winlogon, il sistema si riavvia
Winlogon viene definito "processo di sistema critico" e l'interruzione di un processo critico forza il riavvio del sistema. Perché il sistema considera Winlogon fondamentale per il proprio funzionamento? Per iniziare, Winlogon gestisce la SAS (Secure Attention Sequence), vale a dire Ctrl+Alt+Canc. Se si elimina Winlogon, la SAS smette di funzionare, che è già una conseguenza molto negativa. Ciò che è peggio è che senza il custode ufficiale della SAS, un altro programma potrebbe restare in attesa dell'utilizzo da parte dell'utente della sequenza Ctrl+Alt+Canc per presentare una finestra di dialogo fasulla con una richiesta di immettere la password. La possibilità che l'output della sequenza possa essere falsificato mette a rischio l'intero sistema. La chiusura di Windows prima che un evento del genere possa verificarsi costituisce una misura protettiva.
Se si esegue Gestione attività, si evidenzia un processo di sistema critico come Winlogon, si fa clic su Termina processo e si conferma, si ottiene come risultato l'eliminazione di Winlogon e il riavvio del sistema (sempre che si stia eseguendo il sistema operativo con privilegi di amministratore sufficienti per eliminare il processo).
Nelle versioni di Windows precedenti Gestione attività tentava di dissuadere l'utente dall'eliminare i processi di sistema critici, ma l'algoritmo utilizzato per decidere quali processi fossero critici non era dei più brillanti. Con la giusta dose di perfidia, era possibile ingannare Gestione attività e creare un programma che veniva considerato critico e non eliminabile. Questo non è significativo per il caso preso in esame. Era comunque possibile eliminare il programma utilizzando un programma diverso da Gestione attività (ad esempio, con taskkill).
Per evitare inganni, Gestione attività ha semplicemente smesso di tentare di impedire l'eliminazione di processi di sistema critici. Dopotutto, se non si fa nulla non si rischia di sbagliare. Ne consegue che Gestione attività non tenta di indagare le ragioni che spingono un utente a eliminare un processo, né interviene in alcun modo per convincere l'utente a lasciare in pace un processo che è meglio non interrompere. Se si decide di eliminare un processo di sistema critico, si deve imparare a sopportarne le conseguenze.

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. Raymond lascia ad altri il compito di rendere operativi i meccanismi.