Agosto 2008 Agosto 2008
SQL Server: Suggerimenti per una manutenzione efficiente dei database
Molto spesso, la manutenzione di database viene affidata a utenti che non sono amministratori professionisti. Questi, non avendo una formazione e conoscenze adeguate per gestire database, incontrano vari problemi. Questo articolo è una panoramica per tutti gli amministratori di database involontari che necessitano di un corso intensivo sulle procedure consigliate per la manutenzione dei database. Paul S. Randal
Amministrazione di Windows: Misurazione dei battiti del server
Gli utenti lamentano un'esecuzione non corretta del server, come si può diagnosticare il problema? PerfMon può essere, in tal caso, uno strumento indispensabile poiché offre diverse funzionalità di diagnostica. In questo articolo viene fornita una panoramica sugli indicatori chiave da utilizzare per diagnosticare un gran numero dei più comuni colli di bottiglia che possono rallentare i server. Steven Choy
System Center: Windows PowerShell in System Center Operations Manager
Windows PowerShell è stato integrato in System Center Operations Manager 2007 e costituisce un potente strumento per l'automazione di molte operazioni di amministrazione. Panoramica su come è possibile utilizzare Windows PowerShell in OpsMgr per eseguire la manutenzione di routine, gestione degli agenti e molto altro ancora. Marco Shaw
Internet Information Services (in inglese): Scalare applicazioni ASP.NET: esperienza acquisita
La chiave per ottenere un'applicazione ASP.NET scalabile è da ricercare nello sforzo collaborativo tra gli amministratori di rete e gli sviluppatori, sin dall'inizio del ciclo di vita del progetto. Scopri quali sono i fattori necessari per scalare un'applicazione e vedi come la collaborazione può aiutare a creare un'applicazione affidabile. Richard Campbell
Columns
Dal redattore: In diretta da Tech•Ed: | Lettere: La parola ai lettori: | Toolbox: Nuovi prodotti per professionisti IT:
SQL Q&A: Partizionamento, verifiche di coerenza e altro ancora: Paul Randal risponde a domande relative a SQL Server, illustrando come eseguire verifiche di coerenza e altre operazioni di manutenzione su VLDB (Very Large Database), come gestire aggiornamenti accidentali e molto altro ancora.Paul S. Randal | Utility Spotlight: Utilità Windows Installer CleanUp: Le informazioni di configurazione residue di Windows Installer possono causare problemi quando si tenta di aggiornare o disinstallare un'applicazione. Per risolvere tali problemi, è possibile utilizzare l'utilità Windows Installer CleanUp, che consente di rimuovere le informazioni di Windows Installer di un'applicazione e di reinstallarla.Lance Whitney | Inside SharePoint: Risoluzione dei problemi di integrazione della messaggistica: L'integrazione di SharePoint in un ambiente di messaggistica protetto non è un compito facile, ma considerato l'impatto positivo sulla produttività, vale sicuramente la pena di tentare. Ecco una guida sulla risoluzione dei problemi che si possono verificare durante l'impostazione dell'ambiente.Pav Cherny
Windows PowerShell: Anteprima della versione 2.0 di Gestione remota: Windows PowerShell 2.0 è in fase di sviluppo e l'ultima CTP dispone di nuove proprietà eccezionali. In questo articolo viene esaminato il servizio remoto, una delle nuove funzionalità più interessanti della CTP2 di Windows PowerShell 2.0.Don Jones (in inglese) | Hey, Scripting Guy!: Scegliere la strada diretta: In Windows Vista, il controllo Activex di UserAccounts.CommonDialog per aprire una finestra di dialogo Apri non esiste più. Viene presentato un modo per risolvere tale problema utilizzando Visual Basic Express Edition.Microsoft Scripting Guys | File desktop: Servizi di distribuzione Windows 101: Esplora le diverse versioni dei Servizi di distribuzione Windows, impara come acquisire un'immagine del sistema operativo personalizzata e scopri cosa serve per eseguire diverse installazioni automatiche.Wes Miller
Security Watch: Password e carte di credito, Parte 2: Nella terza ed ultima parte di questa serie, Jesper Johansson analizza il modo in cui i fornitori di software, le suite di protezione, e gli sforzi del marketing ostacolano i veri sforzi della sicurezza e informa sulle modalità con cui queste pratiche possono condurre al crollo dell'ecosistema relativo alla sicurezza della tecnologia.Jesper M. Johansson | Sustainable Computing: Filtrare il "Greenwashing": La comprensione del consumo di energia è diventata una parte essenziale nella gestione di un'infrastruttura IT. Impara le strategie che è possibile utilizzare per implementare il controllo energetico nel tuo ambiente in modo da comprendere al meglio il consumo di energia dei dispositivi all'interno dell'azienda.Dave Ohara | Field Notes: IMAP salva il mondo: I messaggi di posta elettronica sono stati salvati in tanti posti, formati e sistemi operativi diversi? Dara Korra'ti spiega il modo in cui è possibile accedere a tutta la posta utilizzando IMAP4.R'ykandar Korra'ti
Windows Confidential: il futuro si costruisce sul passato: Raymond spiega come il sistema Alpha AXP, un tempo potente, sia stato riutilizzato per consentire lo sviluppo di una nuova generazione di sistemi a 64 bit.Raymond Chen


SQL Server
Suggerimenti per una manutenzione efficiente dei database
Paul S. Randal
Panoramica:
  • Gestione di file di registro delle transazioni e dati
  • Eliminazione della frammentazione dell'indice
  • Garanzia di statistiche accurate e aggiornate
  • Rilevamento di pagine di database danneggiate
  • Definizione di una strategia di backup efficace

Indice
Gestione di file di registro e dati
Frammentazione dell'indice
Statistiche
Rilevamento di danneggiamenti
Backup
Conclusioni
Spesso mi vengono chiesti suggerimenti su come gestire in modo efficiente un database di produzione. A volte, le domande sono poste da amministratori di database che stanno implementando nuove soluzioni e necessitano di
procedure di manutenzione dettagliate adatte per le caratteristiche dei nuovi database. Più spesso, tuttavia, le domande vengono poste da utenti che non sono amministratori di database professionisti, ai quali, per un motivo o per l'altro, è stata assegnata la proprietà e la gestione di un database. Mi piace definire questo ruolo "amministratore di database involontario". Lo scopo principale del presente articolo è fornire una panoramica sulle procedure consigliate di manutenzione dei database per tutti gli amministratori involontari.
Come per la maggior parte delle attività e delle procedure nel mondo dell'IT, anche per la manutenzione dei database non esiste un'unica soluzione valida in tutti i casi, ma esistono comunque alcune aree chiave di cui quasi sempre è necessario occuparsi. Le cinque principali aree di interesse che tratterò sono (l'ordine non corrisponde all'importanza):
  • Gestione di file di registro e dati
  • Frammentazione dell'indice
  • Statistiche
  • Rilevamento di danneggiamenti
  • Backup
La mancata manutenzione (o una manutenzione non accurata) dei database può generare problemi in una o più di queste aree, i quali, a loro volta, possono causare prestazioni inadeguate dell'applicazione o tempi di inattività e perdita di dati.
Nel presente articolo, chiarirò l'importanza di questi problemi e illustrerò semplici metodi per risolverli. Le spiegazioni saranno basate su SQL Server® 2005, ma metterò in risalto anche le principali differenze presenti in SQL Server 2000 e nella versione imminente SQL Server 2008.

Gestione di file di registro e dati
La prima area che suggerisco sempre di verificare a chi gestisce un database comprende le impostazioni relative alla gestione di file di registro (delle transazioni) e dati. In particolare, verificare che:
  • I file di registro e di dati siano separati tra loro e isolati dagli altri file
  • L'aumento automatico sia configurato correttamente
  • L'inizializzazione file immediata sia configurata
  • La compattazione automatica non sia abilitata e la compattazione non faccia parte di alcun piano di manutenzione
Quando i file di registro e dati (che dovrebbero idealmente trovarsi su volumi separati) condividono un volume con altre applicazioni che creano o espandono file, si può verificare la frammentazione dei file. Nei file di dati una frammentazione eccessiva può contribuire a prestazioni insufficienti delle query (in particolare, quelle che eseguono la scansione di grandi quantità di dati). Nei file di registro la frammentazione può avere un impatto assai più significativo sulle prestazioni, in particolare se l'aumento automatico è impostato in modo da espandere le dimensioni di ciascun file di una piccola quantità ogni qual volta sia necessario.
I file di registro sono divisi internamente in sezioni denominate VLF (Virtual Log Files): maggiore è la frammentazione nel file di registro (uso il singolare perché avere più file di registro non comporta alcun vantaggio: deve esisterne solo uno per database), maggiore sarà il numero di VLF. Quando un file di registro, ad esempio, contiene più di 200 VLF, questo può influire negativamente sulle prestazioni di operazioni relative al registro, quali letture (ad esempio, per replica/ripristino di transazioni), backup e, in SQL Server 2000, anche trigger (in SQL Server 2005, per l'implementazione dei trigger il registro delle transazioni è stato sostituito da un framework di controllo delle versioni a livello di riga).
La procedura consigliata per il dimensionamento di file di registro e dati consiste nel crearli con una dimensione iniziale adeguata. Per i file di dati, la dimensione iniziale deve tenere in considerazione la possibilità di aggiungere dati ulteriori al database nel breve periodo. Ad esempio, se la dimensione iniziale dei dati è pari a 50 GB, ma si prevede che nei sei mesi successivi questa aumenterà di altri 50 GB, è opportuno creare sin dall'inizio un file di dati pari a 100 GB anziché doverlo espandere più volte fino a raggiungere tale dimensione.
Per i file di registro, purtroppo, l'operazione è un po' più complessa e occorre tenere in considerazione fattori quali la dimensione delle transazioni (le transazioni a esecuzione prolungata non possono essere eliminate dal registro fino al completamento) e la frequenza di backup del registro (poiché è da questa che dipende la rimozione della parte inattiva del registro). Per ulteriori informazioni, consultare "8 Steps to Better Transaction Log Throughput", un post del noto blog all'indirizzo SQLskills.com, scritto da mia moglie, Kimberly Tripp.
Una volta impostate le dimensioni dei file, è necessario monitorarle in diversi orari e aumentarle manualmente in modo proattivo a una determinata ora del giorno. Inoltre, è consigliabile mantenere l'aumento automatico attivo come ulteriore protezione, in modo che le dimensioni dei file possano comunque aumentare nel caso si verifichino anomalie. Non è consigliabile affidare completamente la gestione dei file all'aumento automatico, poiché tale operazione, se eseguita per piccole quantità, può portare alla frammentazione dei file e richiedere tempi lunghi, rischiando di bloccare il carico di lavoro dell'applicazione a orari imprevedibili.
Al fine di limitare il tempo e lo spazio necessari per eseguire l'aumento automatico, la dimensione di quest'ultimo deve essere impostata su un valore specifico anziché su un valore percentuale. Ad esempio, è possibile impostare un file di dati di 100 GB in modo che aumenti automaticamente di una dimensione fissa pari a 5 GB, anziché del 10%. Questo significa che il file aumenterà sempre di 5 GB, indipendentemente dalla dimensione finale, anziché di una quantità sempre maggiore (10 GB, 11 GB, 12 GB e così via) ogni volta che le dimensioni crescono.
Quando viene aumentato (sia manualmente che automaticamente), un registro delle transazioni è sempre inizializzato a zero. In SQL Server 2000 i file di dati hanno lo stesso comportamento predefinito, ma a partire da SQL Server 2005, è possibile attivare l'inizializzazione file immediata, che salta l'inizializzazione a zero rendendo quindi aumento e aumento automatico dei file quasi istantanei. Contrariamente a quanto si pensa, questa funzionalità è disponibile in tutte le edizioni di SQL Server. Per ulteriori informazioni, inserire "inizializzazione file immediata" nell'indice della documentazione in linea di SQL Server 2005 o SQL Server 2008.
Infine, accertarsi che la compattazione non sia attivata. La compattazione può essere utilizzata per ridurre la dimensione di un file di registro o dati, ma è un processo particolarmente intrusivo, che comporta l'utilizzo di grandi quantità di risorse, causando un'elevata frammentazione di scansione logica nei file di dati (per informazioni dettagliate, vedere di seguito) e un calo delle prestazioni. Ho modificato la voce relativa alla compattazione nella documentazione in linea di SQL Server 2005, aggiungendo un'avvertenza relativa a questo effetto. Tuttavia, in circostanze particolari, è possibile eseguire la compattazione manuale di singoli file di registro e dati.
Video
In questo video, Paul Randal dimostra come compattazione e compattazione automatica possano causare gravi problemi di frammentazione per il database.

La compattazione automatica è il problema principale, poiché si avvia in background ogni 30 minuti e tenta di compattare i database in cui l'opzione corrispondente è impostata su True. Si tratta di un processo imprevedibile, in quanto vengono compattati solo i database con più del 25% di spazio libero. La compattazione automatica utilizza una quantità notevole di risorse, causando una frammentazione che provoca un calo delle prestazioni, pertanto non è un processo consigliabile in alcuna circostanza. Disattivare la compattazione automatica con il seguente comando:
ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;
Un piano di manutenzione regolare che includa una compattazione manuale del database è altrettanto sconsigliabile. Se il database aumenta costantemente una volta eseguita la compattazione nel piano di manutenzione, significa che è necessario ulteriore spazio.
La soluzione ottimale consiste nel consentire al database di aumentare fino a una dimensione stabile ed evitare del tutto di eseguire la compattazione. Ulteriori informazioni sugli svantaggi dell'utilizzo della compattazione e alcuni commenti sui nuovi algoritmi in SQL Server 2005 sono disponibili sul mio precedente blog MSDN® all'indirizzo blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx.

Frammentazione dell'indice
Oltre che a livello di file system e all'interno del file di registro, è possibile che si verifichi una frammentazione anche all'interno dei file di dati, nelle strutture in cui sono memorizzati i dati di tabelle e indice. All'interno di un file di dati, possono verificarsi due tipi fondamentali di frammentazione:
  • Frammentazione all'interno di singole pagine di dati e indice (a volte denominata frammentazione interna)
  • Frammentazione all'interno di strutture di indice o tabelle costituite da pagine (denominate frammentazione di scansione logica e frammentazione di scansione extent)
La frammentazione interna si verifica quando è presente una grande quantità di spazio vuoto all'interno di una pagina. Come indicato in Figura 1, ogni pagina all'interno di un database ha una dimensione pari a 8 KB e un'intestazione di 96 byte. Di conseguenza, in una pagina possono essere memorizzati circa 8096 byte di dati di tabelle o indice (informazioni specifiche relative a tabelle e indici per strutture di dati e righe sono disponibili sul mio blog all'indirizzo sqlskills.com/blogs/paul, nella categoria Inside The Storage Engine). Gli spazi vuoti sono presenti quando la dimensione di ciascun record di indice o tabella supera la metà di quella della pagina: in tal caso, infatti, è possibile memorizzare un unico record per pagina. Questa situazione può risultare difficile o addirittura impossibile da correggere, poiché richiederebbe una modifica dello schema di tabelle o indice, ad esempio tramite la variazione di una chiave dell'indice al fine di evitare punti di inserimento casuali, come nel caso di un GUID.
Figura 1 Struttura di una pagina di database (fare clic sull'immagine per ingrandirla)
Più spesso, la frammentazione interna è dovuta a modifiche di dati, quali inserimenti, aggiornamenti ed eliminazioni, che possono lasciare spazio vuoto in una pagina. Inoltre, anche una gestione inadeguata del fattore di riempimento può contribuire alla frammentazione. Per ulteriori informazioni, consultare la documentazione in linea. In base allo schema di tabelle/indice e alle caratteristiche dell'applicazione, una volta creatosi, lo spazio vuoto potrebbe non essere riutilizzato, causando un continuo aumento di spazio inutilizzabile nel database.
Si consideri, ad esempio, una tabella di 100 milioni di righe con record di dimensione media di 400 byte. Nel tempo, il modello di modifica dei dati dell'applicazione lascia di media 2800 byte di spazio vuoto in ogni pagina. Lo spazio totale necessario per la tabella è di circa 59 GB, risultato ottenuto con il seguente calcolo: 8096-2800 / 400 = 13 record per pagina da 8 KB, dividendo poi 100 milioni per 13 al fine di ottenere il numero di pagine. Se non si sprecasse spazio, ciascuna pagina potrebbe contenere 20 record, riducendo lo spazio totale necessario a 38 GB. Il risparmio è notevole.
Lo spazio sprecato nelle pagine di dati/indici, pertanto, può causare la necessità di un numero superiore di pagine per contenere la stessa quantità di dati. Questo non solo occupa più spazio su disco, ma significa anche che una query deve utilizzare più I/O per leggere la stessa quantità di dati. Inoltre, tutte le pagine aggiuntive occupano più spazio nella cache di dati, utilizzando quindi più memoria del server.
La frammentazione di scansione logica è causata da un'operazione denominata divisione di pagina, che si verifica quando un record deve essere inserito in una pagina di indice specifica (in base alla definizione della chiave dell'indice), ma nella pagina non è disponibile spazio sufficiente per l'inserimento dei dati. La pagina è divisa a metà e circa il 50% dei record viene trasferito su una nuova pagina riallocata. Tale pagina, in genere, non è fisicamente contigua alla precedente, pertanto è detta frammentata. Concettualmente, la frammentazione di scansione extent è simile. La frammentazione all'interno delle strutture di tabelle/indice influisce sulla capacità di SQL Server di eseguire scansioni efficienti, sia relative a una tabella/indice interi, sia limitata a una query con clausola WHERE (ad esempio, SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000).
Nella Figura 2 sono illustrate pagine di indice appena create con fattore di riempimento del 100% e prive di frammentazione (le pagine sono complete e il loro ordine fisico corrisponde a quello logico). Nella Figura 3 è illustrata la frammentazione che può verificarsi dopo inserimenti/aggiornamenti/eliminazioni casuali.
Figura 2 Pagine di indice appena create prive di frammentazione: pagine complete al 100% (fare clic sull'immagine per ingrandirla)
Figura 3 Pagine di indice con frammentazione interna e di scansione logica in seguito a inserimenti, aggiornamenti ed eliminazioni casuali (fare clic sull'immagine per ingrandirla)
A volte, è possibile evitare che la frammentazione modifichi lo schema di tabelle/indice ma, come affermato in precedenza, ciò potrebbe risultare complesso o addirittura impossibile. Quando non è possibile evitarla, esistono procedure per eliminare la frammentazione, in particolare mediante la ricostruzione e riorganizzazione degli indici.
Per ricostruire un indice, è necessario crearne una nuova copia, compattata in modo efficiente e il più contigua possibile ed eliminare la precedente versione frammentata. Poiché SQL Server crea una nuova copia dell'indice prima di eliminare la precedente, è necessario uno spazio libero nei file di dati che sia all'incirca equivalente alla dimensione dell'indice. In SQL Server 2000 la ricostruzione dell'indice era un'operazione non in linea. In SQL Server 2005 Enterprise Edition, tuttavia, è possibile eseguirla in linea, con alcune eccezioni. La riorganizzazione, invece, utilizza un algoritmo sul posto per compattare e deframmentare l'indice, richiede solo 8 KB di spazio aggiuntivo e viene sempre eseguita in linea. In effetti, in SQL Server 2000, ho scritto il codice per la riorganizzazione dell'indice affinché fosse una valida alternativa in linea alla ricostruzione e richiedesse poco spazio.
In SQL Server 2005 i comandi da utilizzare sono ALTER INDEX … REBUILD per la ricostruzione e ALTER INDEX … REORGANIZE per la riorganizzazione degli indici. La nuova sintassi sostituisce rispettivamente i comandi DBCC DBREINDEX e DBCC INDEXDEFRAG di SQL Server 2000.
Questi metodi comportano diversi compromessi, quali la quantità di registri di transazione generati, la quantità di spazio libero necessaria nel database e la possibilità di interrompere il processo senza perdere il lavoro. All'indirizzo microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx è disponibile un white paper in cui sono illustrati tali compromessi. Il documento è basato su SQL Server 2000, ma i concetti sono applicabili anche alle versioni successive.
Alcuni utenti si limitano a ricostruire o riorganizzare tutti gli indici ogni sera o ogni settimana (ad esempio, utilizzando l'opzione del piano di manutenzione) anziché determinare quali indici siano frammentati e se la rimozione della frammentazione comporterà effettivi vantaggi. Si tratta di una buona soluzione per gli amministratori di database involontari che desiderano semplicemente sistemare le cose con il minimo sforzo, ma può rivelarsi una scelta poco efficiente per database o sistemi di dimensioni maggiori in cui le risorse scarseggiano.
Un approccio più sofisticato comporta l'utilizzo della DMV sys.dm_db_index_physical_stats (o DBCC SHOWCONTIG in SQL Server 2000) per determinare periodicamente quali indici siano frammentati, scegliendo in seguito se e come operare su tali elementi. Nel white paper è inoltre descritto l'utilizzo di soluzioni mirate. Infine, nell'esempio D della voce nella documentazioni in linea relativa alla DMV sys.dm_db_index_physical_stats in SQL Server 2005 (msdn.microsoft.com/library/ms188917) o nell'esempio E della voce relativa a DBCC SHOWCONTIG in SQL Server 2000 e versioni successive (msdn.microsoft.com/library/aa258803), sono disponibili alcuni codici esemplificativi per l'applicazioni dei filtri.
A prescindere dal metodo utilizzato, è consigliabile esaminare e risolvere la frammentazione regolarmente.
Il processore di query è la parte di SQL Server che decide la modalità di esecuzione di una query, in particolare le tabelle e gli indici da utilizzare, nonché le operazioni da eseguire per ottenere i risultati. Tale procedura è denominata piano di query. Alcuni degli input più importanti in questo processo decisionale sono statistiche che descrivono la distribuzione di valori dei dati per le colonne all'interno di una tabella o indice. Ovviamente, al fine di risultare utili per il processore di query, le statistiche devono essere accurate e aggiornate. In caso contrario, potrebbero causare prestazioni insufficienti dei piani di query.
Le statistiche sono generate mediante la lettura dei dati di tabelle/indice e la successiva determinazione della distribuzione dei dati per le colonne rilevanti. È possibile creare statistiche eseguendo la scansione di tutti i valori di dati per una determinata colonna (scansione completa), ma è anche possibile basarle su una percentuale di dati specificata dall'utente (scansione parziale). Se la distribuzione di valori in una colonna è uniforme, è sufficiente una scansione parziale, che rende la creazione e l'aggiornamento delle statistiche più rapidi rispetto alla scansione completa.
È possibile creare e gestire le statistiche in modo automatico attivando le opzioni database AUTO_CREATE_STATISTICS e AUTO_UPDATE_STATISTICS, come indicato nella Figura 4. Per impostazione predefinita, tali opzioni sono attive, ma nel caso in cui si utilizzi un database per la prima volta, è consigliabile controllarle. Quando le statistiche diventano obsolete, è possibile aggiornarle manualmente utilizzando l'operazione UPDATE STATISTICS per specifici set di statistiche. In alternativa, è possibile utilizzare la stored procedure sp_updatestats, che consente di aggiornare le statistiche obsolete (in SQL Server 2000, sp_updatestats aggiorna tutte le statistiche, a prescindere dalla data).
Figura 4 Modifica di impostazioni del database mediante SQL Server Management Studio (fare clic sull'immagine per ingrandirla)
Per inserire l'aggiornamento di statistiche nel piano di manutenzione regolare, è opportuno conoscere le seguenti informazioni. Sia UPDATE STATISTICS che sp_updatestats per impostazione predefinita utilizzano il livello di campionamento specificato in precedenza (se presente, potrebbe trattarsi di una quantità inferiore alla scansione completa). La ricostruzione dell'indice aggiorna automaticamente le statistiche con una scansione completa. Se le si aggiornano manualmente dopo la ricostruzione di un indice, è possibile che le statistiche risultino meno precise. Questo può verificarsi se una scansione parziale dell'aggiornamento manuale sovrascrive la scansione completa generata dalla ricostruzione dell'indice. D'altro canto, la riorganizzazione di un indice non aggiorna le statistiche.
Anche in questo caso, molti utenti dispongono di un piano di manutenzione che aggiorna tutte le statistiche in un determinato momento, prima o dopo la ricostruzione di tutti gli indici. Quindi, inconsapevolmente, ottengono statistiche meno precise. Se si opta semplicemente per la ricostruzione a intervalli regolari di tutti gli indici, tale operazione garantirà anche statistiche precise. Se si sceglie la procedura più complessa con la rimozione della frammentazione, sarà necessario seguire questa strada anche per la manutenzione delle statistiche. Ecco alcuni suggerimenti:
  • Analizzare gli indici e determinare su quali di essi operare e come procedere alla rimozione della frammentazione.
  • Per tutti gli indici che non vengono ricostruiti, aggiornare le statistiche.
  • Aggiornare le statistiche per tutte le colonne non indicizzate.
Per ulteriori informazioni sulle statistiche, consultare il white paper "Statistiche utilizzate da Query Optimizer® in SQL Server 2005" (microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx).

Rilevamento di danneggiamenti
Ho trattato la manutenzione in relazione alle prestazioni. Ora intendo illustrare il rilevamento e l'attenuazione di danneggiamenti.
È del tutto improbabile che un database contenga informazioni inutili che non interessano a nessuno. Quindi, com'è possibile accertarsi che i dati non vengano danneggiati e siano recuperabili in caso di emergenza? I dettagli relativi alla pianificazione di una strategia di disponibilità elevata e un ripristino di emergenza completo esulano dagli obiettivi dell'articolo. Tuttavia, per iniziare, è consigliabile conoscere alcune semplici informazioni.
La maggior parte dei danneggiamenti sono causati dall'"hardware". Perché l'ho scritto tra virgolette? Perché hardware, in questo caso, è un termine breve per indicare "qualcosa nel sottosistema di I/O su cui si basa SQL Server". Il sottosistema di I/O è costituito da elementi quali sistema operativo, driver del file system, driver di dispositivi, controller RAID, cavi, reti e le stesse unità disco. I punti in cui possono verificarsi (e di fatto si verificano) problemi sono molti.
Uno dei problemi più comuni è il verificarsi di interruzioni di alimentazione mentre un'unità disco sta scrivendo una pagina di database. Se l'unità non riesce a completare la scrittura prima dell'interruzione dell'alimentazione (oppure se le operazioni di scrittura sono memorizzate nella cache e la batteria di backup non è sufficiente per cancellare la cache dell'unità), questo potrebbe causare un'immagine di pagina incompleta sul disco. Il problema può verificarsi perché una pagina di database da 8 KB è in realtà costituita da 16 settori del disco contigui da 512 byte. Un'operazione di scrittura incompleta potrebbe aver causato la scrittura di alcuni settori della nuova pagina, tralasciando tuttavia alcuni settori della pagina precedente. Una situazione denominata pagina incompleta. Com'è possibile rilevare questo fenomeno?
SQL Server dispone di un meccanismo apposito, che consiste nella memorizzazione di una coppia di bit di ciascun settore della pagina e nella sostituzione di tali bit con un modello specifico (prima che la pagina venga scritta sul disco). Se quando la pagina viene riletta, il modello non è lo stesso, SQL Server rileva che la pagina è "incompleta" e segnala un errore.
In SQL Server 2005 e versioni successive è disponibile un meccanismo più completo, denominato checksum di pagina, che può rilevare i danneggiamenti presenti su una pagina. Questa procedura prevede un checksum della pagina intera prima che sia scritta, quindi una verifica quando viene riletta, come per il rilevamento delle pagine incomplete. Una volta abilitati i checksum di pagina, prima che venga protetta da tali meccanismi, la pagina dev'essere letta nel pool di buffer, modificata e riscritta sul disco.
Pertanto, è consigliabile attivare i checksum di pagina per SQL Server 2005 e versioni successive e abilitare il rilevamento di pagine incomplete per SQL Server 2000. Per attivare i checksum di pagina, utilizzare:﻿
ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;
Per attivare il rilevamento di pagine incomplete per SQL Server 2000, utilizzare:
ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;
Questi meccanismi consentono di rilevare se una pagina è danneggiata, ma solo nel momento in cui questa viene letta. Com'è possibile fare in modo che tutte le pagine allocate vengano lette? Il metodo migliore per eseguire questa operazione (e identificare qualsiasi altro tipo di danneggiamento) è utilizzare il comando DBCC CHECKDB. A prescindere dalle opzioni specificate, il comando leggerà comunque tutte le pagine nel database, causando la verifica di checksum di pagina o rilevamenti di pagine incomplete. Inoltre, è consigliabile impostare degli avvisi, in modo tale da sapere quando gli utenti incontrano problemi di danneggiamento durante l'esecuzione di query. È possibile ricevere una notifica relativa a tutti i problemi descritti in precedenza utilizzando un avviso per gli errori con gravità 24 (Figura 5).
Figura 5 Impostazione di un avviso per tutti gli errori con gravità 24 (fare clic sull'immagine per ingrandirla)
Quindi, un'altra procedura consigliata è eseguire regolarmente il comando DBCC CHECKDB sui database per verificarne l'integrità. Esistono molte varianti di questo comando, nonché domande sulla frequenza con cui eseguirlo. Purtroppo, non sono disponibili white paper relativi a questo argomento. Tuttavia, poiché DBCC CHECKDB era la parte di codice principale che ho scritto per SQL Server 2005, nel blog ne ho discusso ampiamente. Per articoli dettagliati sulle verifiche della coerenza, procedure consigliate e suggerimenti sulle procedure, consultare la categoria "CHECKDB From Every Angle" del mio blog (sqlskills.com/blogs/paul). Per gli amministratori di database involontari, la regola generale è eseguire il comando DBCC CHECKDB con la stessa frequenza con cui si effettuano backup del database completi (ulteriori informazioni al riguardo di seguito). Suggerisco di eseguire il seguente comando:
DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS,
  ALL_ERRORMSGS;
Se in seguito all'esecuzione del comando vengono visualizzati output, DBCC ha identificato danneggiamenti nel database. In questo caso la domanda da porsi è: cosa fare quando DBCC CHECKDB identifica danneggiamenti? È qui che entrano in gioco i backup.
Quando si verificano danneggiamenti o altri malfunzionamenti, il metodo più efficace per risolvere la situazione è ripristinare il database dai backup. I presupposti sono, innanzitutto, disporre di backup e che tali backup non siano danneggiati. Molto spesso, gli utenti chiedono come sia possibile ripristinare un database danneggiato in assenza di backup. La risposta è semplice: non è possibile, non senza evitare perdite di dati che potrebbero creare problemi all'integrità di dati relazionali e logica aziendale.
Quindi, esistono ragioni più che sufficienti per eseguire backup regolari. Le complessità legate all'utilizzo di backup e ripristino esulano dagli obiettivi dell'articolo. Tuttavia, illustrerò brevemente i principi fondamentali per definire una strategia di backup.
Primo: eseguire regolarmente backup completi del database. Questo consentirà di disporre di una copia temporizzata con cui eseguire il ripristino. È possibile eseguire un backup completo del database utilizzando il comando BACKUP DATABASE. Per eventuali esempi, consultare la documentazione in linea. Per garantire ulteriore protezione, è possibile utilizzare l'opzione WITH CHECKSUM, che verifica i checksum (se presenti) delle pagine lette e calcola un checksum sull'intero backup. Selezionare una frequenza che corrisponde alla quantità di dati o lavoro che la propria azienda può permettersi di perdere. Ad esempio, se si esegue un backup completo del database una volta al giorno, in caso di emergenza, si perderà un volume di dati equivalente a un massimo di un giorno. Se si utilizzano solo backup completi del database, è consigliabile sfruttare il modello di recupero con REGISTRAZIONE MINIMA (comunemente denominato modalità di ripristino), al fine di evitare le complicazioni legate alla gestione dell'aumento del registro delle transazioni.
Secondo: conservare i backup per alcuni giorni, nel caso in cui uno venga danneggiato (disporre di un backup di qualche giorno prima è comunque meglio di non averne affatto). Inoltre, verificare l'integrità dei backup utilizzando il comando RESTORE WITH VERIFYONLY (consultare la documentazione in linea). Se durante la creazione del backup si è utilizzata l'opzione WITH CHECKSUM, eseguendo il comando di verifica sarà possibile controllare che il checksum del backup sia ancora valido, nonché ricontrollare tutti i checksum delle pagine all'interno del backup.
Terzo: se l'esecuzione di un backup completo al giorno non consente di rispettare la perdita massima di dati/lavoro che l'azienda può subire, è possibile considerare i backup differenziali. Un backup di database differenziale si basa su un backup completo e contiene un record di tutte le modifiche apportate dall'ultimo backup completo (in genere, si ritiene erroneamente che i backup differenziali siano incrementali: non lo sono). Ad esempio, è possibile utilizzare una strategia che preveda un backup di database completo al giorno e un backup differenziale ogni quattro ore. Il backup differenziale consente di disporre di un ripristino temporizzato supplementare. Se si utilizzano solo backup di database completi e differenziali, è comunque consigliabile sfruttare il modello di recupero con REGISTRAZIONE MINIMA.
Infine, l'ultima risorsa per il ripristino è rappresentata dall'uso di backup di registro. Questi sono disponibili solo nei modelli di recupero con REGISTRAZIONE COMPLETA (o REGISTRAZIONE MINIMA DELLE TRANSAZIONI DI MASSA) e consentono di eseguire il backup di tutti i record di registro generati dal backup di registro precedente. L'esecuzione di una serie di backup di registro con backup di database completi (e differenziali) periodici consente di avere un numero illimitato di backup temporizzati e aggiornati per il ripristino. Il compromesso necessario è che il registro delle transazioni continuerà ad aumentare, a meno che non sia "liberato" mediante un apposito backup. In questo caso, è possibile utilizzare una strategia che preveda un backup di database completo al giorno, un backup di database differenziale ogni quattro ore e un backup di registro ogni mezz'ora.
Decidere quale strategia di backup applicare e configurarla può risultare complesso. Come minimo, è consigliabile eseguire regolarmente backup di database completi al fine di avere almeno una copia temporizzata per il ripristino.
Come si può notare, per garantire che il database si mantenga in buone condizioni e sia sempre disponibile, è sufficiente eseguire alcune operazioni "obbligatorie". Di seguito è riportato un elenco di controllo finale per gli amministratori involontari che assumono il controllo di un database:
  • Eliminare l'eccessiva frammentazione dei file del registro delle transazioni.
  • Impostare correttamente l'aumento automatico.
  • Disattivare qualsiasi operazione di compattazione pianificata.
  • Attivare l'inizializzazione dei file immediata.
  • Definire una procedura regolare per rilevare e rimuovere la frammentazione dell'indice.
  • Attivare AUTO_CREATE_STATISTICS e AUTO_UPDATE_STATISTICS definendo una procedura regolare per l'aggiornamento delle statistiche.
  • Attivare i checksum di pagina (o almeno il rilevamento delle pagine incomplete in SQL Server 2000).
  • Definire una procedura regolare per l'esecuzione di DBCC CHECKDB.
  • Definire una procedura regolare per l'esecuzione di backup di database completi e differenziali, nonché backup di registro per il ripristino temporizzato.
All'interno dell'articolo ho citato comandi T-SQL, ma anche Management Studio consente di svolgere diverse operazioni. Spero di aver fornito alcuni suggerimenti utili per una manutenzione efficiente dei database. Per commenti, suggerimenti o domande, scrivere all'indirizzo: paul@sqlskills.com.

Paul S. Randal è Managing Director di SQLskills.com e MVP per SQL Server. Ha lavorato nel team di SQL Server Storage Engine in Microsoft dal 1999 al 2007 ed è esperto in ripristino di emergenza, disponibilità elevata e manutenzione di database. Il suo blog è disponibile all'indirizzo SQLskills.com/blogs/paul.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


Amministrazione di Windows
Misurazione dei battiti del server
Steven Choy
Panoramica:
  • Personalizzazione di Performance Monitor
  • Indicazioni sulla modalità e la frequenza della misurazione
  • Panoramica sui contatori principali e su cosa controllare

Indice
Creazione di risultati più leggibili
Modalità e frequenza della misurazione
Collo di bottiglia del disco rigido
Collo di bottiglia della memoria
Collo di bottiglia del processore
Collo di bottiglia della rete
Collo di bottiglia del processo
Conclusioni
È lunedì mattina, immagina di arrivare in ufficio e trovare un utente ansioso che lamenta un server troppo lento. Da dove iniziare per aiutarlo? Performance
Monitor, è uno strumento utile, integrato in Windows®, che può aiutarti a diagnosticare il problema.
Puoi accedere a Performance Monitor digitando perfmon nel prompt dei comandi o scegliendo Performance Monitor o Monitoraggio affidabilità e Performance Monitor (in Windows Vista® e Windows Server® 2008) dal menu Strumenti di amministrazione. Per aggiungere i contatori delle prestazioni e gli oggetti da monitorare, fai semplicemente clic sul segno più e seleziona una delle opzioni disponibili.
Allora, come si misura il battito di un server? Esistono più di 60 oggetti di prestazione di base e ogni oggetto contiene più contatori. In quest'articolo illustrerò i contatori che rivelano i segni vitali di un server e descriverò i tipici intervalli di campionamento che i tecnici del supporto di Microsoft® utilizzano di solito per risolvere i problemi relativi alle prestazioni.
Ovviamente, un valore di riferimento è un fattore critico durante la risoluzione dei problemi. Poiché il carico del server dipende dai requisiti aziendali e varia, inoltre, di tanto in tanto a seconda del ciclo aziendale, è importante stabilire un valore di riferimento che deriva dal carico di lavoro normale in un determinato periodo di tempo. Ciò consente di osservare le modifiche e identificare le tendenze.

Creazione di risultati più leggibili
Prima di tuffarmi nell'analisi dei contatori che rappresentano i segni vitali dei server, illustro due suggerimenti che renderanno più facile la misurazione dei segni vitali dei server utilizzando Performance Monitor. Questi suggerimenti non sono necessari in Windows Vista e Windows Server 2008, ma se si esegue Performance Monitor su versioni precedenti di Windows, allora queste due operazioni possono rivelarsi estremamente utili.
Innanzitutto, puoi rimuovere tutto il rumore di esempio che distrae e nasconde la vista grafica delle linee di tendenza. In Windows Vista e Windows Server 2008 lo strumento Performance Monitor è in grado di visualizzare fino a 1000 punti dati nella vista grafica. Nelle versioni precedenti di Windows il limite è fissato a 100 punti dati. Con un numero maggiore di 100 punti, Performance Monitor esegue il bucket dei punti dati. Un bucket è rappresentato da una linea verticale, che indica il punto minimo, medio e massimo dei punti di campionamento contenuti nel bucket.
Come si può vedere dal grafico nella Figura 1, è difficile individuare la linea di tendenza quando vengono visualizzati così tanti dati allo stesso tempo. Il grafico della Figura 2 mostra quanto sia più semplice individuare subito i dati una volta eliminate tutte le informazioni visive estranee. Per ulteriori informazioni sul metodo di eliminazione delle linee verticali, vedere l'articolo della Knowledge Base disponibile sul sito Web support.microsoft.com/kb/283110.
Figura 1 Dati sulle prestazioni mostrati con bucket dispersivi e senza virgole (fare clic sull'immagine per ingrandirla)
Figura 2 Una visualizzazione più chiara dei dati con virgole come separatore (fare clic sull'immagine per ingrandirla)
Il secondo suggerimento è quello di aggiungere le virgole come separatori nelle numerazioni, facilitando così la lettura dei valori nei contatori. In Windows Vista e Windows Server 2008 le virgole come separatori sono attivate per impostazione predefinita. Nelle precedenti versioni di Windows, tuttavia, lo strumento Performance Monitor non attiva le virgole per impostazione predefinita.
Sembra che questo non comporti una grande differenza, ma guarda la Figura 1, che mostra i contatori di prestazione senza le virgole e poi la Figura 2 che presenta i contatori con le virgole. La seconda figura è molto più leggibile. Per alcune semplici istruzioni sull'aggiunta delle virgole come separatori ai contatori delle prestazioni in Windows XP, vedere l'articolo della Knowledge Base all'indirizzo Web support.microsoft.com/kb/300884.

Modalità e frequenza della misurazione
I colli di bottiglia si verificano quando una risorsa raggiunge la propria capacità, causando un rallentamento delle prestazioni dell'intero sistema. I colli di bottiglia sono di solito causati da risorse configurate in modo errato o insufficienti, da componenti malfunzionanti e da richieste di risorse non corrette da parte di un programma.
Esistono cinque principali aree di risorsa che possono causare i colli di bottiglia e influire sulle prestazioni del server: il disco fisico, la memoria, il processo, la CPU e la rete. Se una qualsiasi di queste risorse è sovrautilizzata, il server o l'applicazione può diventare notevolmente lenta o addirittura bloccarsi. Analizzerò ciascuna di queste cinque aree, fornendo istruzioni sui contatori da utilizzare e offrendo delle soglie consigliate per misurare gli impulsi del server.
Poiché l'intervallo di campionamento ha un impatto significativo sulla dimensione del file di registro e sul carico del server, tale intervallo deve essere impostato sulla base del tempo medio trascorso prima del verificarsi del problema; in tal modo, puoi stabilire un valore di riferimento prima che il problema si verifichi di nuovo. Ciò ti consentirà di individuare qualsiasi tendenza che porta al problema.
Quindici minuti sono un buon lasso di tempo come valore di riferimento durante le operazioni normali. Se il tempo medio trascorso prima del verificarsi del problema è di circa quattro ore, imposta l'intervallo di campionamento su 15 secondi. Se il tempo medio trascorso prima del verificarsi del problema è di otto o più ore, imposta l'intervallo di campionamento su non meno di cinque minuti; altrimenti, si avrà un file di registro di dimensioni enormi, che rende più difficile l'analisi dei dati.

Collo di bottiglia del disco rigido
Poiché il disco di sistema memorizza e gestisce i programmi e i dati sul server, un collo di bottiglia che interessi la velocità e l'utilizzo del disco avrà un grande impatto sulle prestazioni globali del server.
Se gli oggetti del disco non sono stati attivati sul server, per attivarli è necessario utilizzare gli strumenti della riga di comando Diskperf. Tenere inoltre presente che % Tempo disco può superare il 100% e, quindi, è preferibile utilizzare % Tempo di inattività, Media letture disco/sec e Media scritture disco/sec per avere un'idea più esatta di quanto spazio è disponibile sul disco rigido. Maggiori informazioni su % Tempo disco sono disponibili nell'articolo della Knowledge Base all'indirizzo Web support.microsoft.com/kb/310067.
Di seguito sono riportati i contatori su cui i tecnici del supporto Microsoft fanno affidamento in materia di monitoraggio del disco.
Disco logico\ % Spazio disponibile indica la percentuale di spazio disponibile sull'unità disco logica selezionata. Se tale percentuale scende al di sotto del 15%, prenderne nota perché si rischia che il sistema operativo rimanga senza spazio disponibile per memorizzare i file critici. Una soluzione possibile è aggiungere maggiore spazio su disco.
Disco fisico\ % Tempo di inattività indica la percentuale di tempo di inattività del disco durante l'intervallo di campionamento. Se questo contatore scende al di sotto del 20%, il disco di sistema è saturo. Prendere in considerazione la possibilità di sostituire il disco di sistema corrente con un disco di sistema più veloce.
Disco fisico\Media letture disco/sec misura il tempo medio, in secondi, per le operazioni lettura dei dati da disco. Se il numero è maggiore di 25 millisecondi (ms), significa che sul disco di sistema si verifica latenza quando si esegue la lettura da disco. Per i server di importanza critica che ospitano SQL Server® ed Exchange Server, la soglia accettabile è molto più bassa, approssimativamente dieci millisecondi. La soluzione più logica è quella di sostituire il disco di sistema attuale con un disco di sistema più veloce.
Disco fisico\Media scritture disco/sec indica il tempo medio, in secondi, necessario per le operazioni di scrittura dei dati su disco. Se il numero è maggiore di 25 millisecondi, nel disco di sistema si verifica latenza quando si esegue la scrittura su disco. Per i server di importanza critica che ospitano SQL Server ed Exchange Server, la soglia accettabile è molto più bassa, approssimativamente 10 millisecondi. La soluzione possibile è sostituire il disco di sistema con uno più veloce.
Disco fisico\Lunghezza media coda del disco Questo valore indica il numero di operazioni I/O che aspettano che il disco rigido diventi disponibile. Se il valore è maggiore del numero di assi più due, significa che il disco stesso potrebbe essere il collo di bottiglia.
Memoria\Byte di cache Questo valore indica la quantità di memoria utilizzata per la cache del file system. Potrebbe essere presente un collo di bottiglia del disco se questo valore è maggiore di 200 MB.

Collo di bottiglia della memoria
Un'insufficienza di memoria di solito è dovuta a RAM insufficiente, a problemi di memoria o al parametro di memoria collocato nel file boot.ini. Prima di arrivare ai contatori di memoria, è bene analizzare l'opzione /3GB.
L'aumento di memoria riduce l'attività I/O del disco e, a sua volta, migliora le prestazioni delle applicazioni. L'opzione /3GB è stata introdotta in Windows NT® in modo da fornire maggiore memoria ai programmi di modalità utente.
Windows utilizza uno spazio degli indirizzi virtuale di 4 GB (a prescindere da quanta RAM fisica è presente nel sistema). Per impostazione predefinita, i 2 GB inferiori sono riservati ai programmi di modalità utente e i 2 GB superiori sono riservati ai programmi di modalità kernel. Con l'opzione /3GB, ai processi di modalità utente vengono assegnati 3 GB. Certamente, questo avviene a scapito della memoria kernel, che avrà soltanto 1 GB di spazio per gli indirizzi virtuali. Ciò può causare problemi perché i byte del pool non di paging, i byte del pool di paging, le voci libere della tabella delle pagine di sistema e l'heap del desktop sono tutti raggruppati nello spazio di 1 GB. Pertanto, l'opzione /3GB deve essere utilizzata solo dopo aver eseguito dei test approfonditi nell'ambiente in uso.
Ciò è importante nel caso in cui si verifichi un collo di bottiglia relativo alla memoria. Se l'opzione /3GB non rappresenta la causa del problema, puoi utilizzare questi contatori per diagnosticare un potenziale collo di bottiglia della memoria.
Memoria\% byte vincolati in uso indica la percentuale di Byte vincolati al Limite memoria vincolata, ovvero la quantità di memoria virtuale utilizzata. Ciò indica che la memoria è insufficiente se il numero è maggiore di 80%. La soluzione ovvia è aggiungere ulteriore memoria.
Memoria\ % Mbyte disponibili indica la quantità di memoria fisica, in megabyte, disponibile per i processi in esecuzione. Se questo valore è inferiore al 5% della RAM fisica totale, significa che la memoria è insufficiente e ciò può aumentare l'attività di paging. Per risolvere questo problema, devi solo aggiungere ulteriore memoria.
Memoria\Voci libere tabella pagine di sistema indica il numero di voci della tabella pagine non attualmente in uso dal sistema. Se il numero è inferiore a 5.000, è possibile che si verifichi una perdita di memoria.
Memoria\Byte del pool non di paging indica le dimensioni, in byte, del pool non di paging. Si tratta di un'area di memoria di sistema per gli oggetti che non possono essere scritti su disco, ma devono invece rimanere nella memoria fisica finché non vengono allocati. Possono verificarsi dei problemi di memoria se il valore è maggiore di 175 MB (o 100 MB con l'opzione /3GB). Un tipico ID evento 2019 è memorizzato nel registro eventi di sistema.
Memoria\Byte del pool di paging indica le dimensioni, in byte, del pool di paging. Si tratta di un'area di memoria di sistema utilizzata per gli oggetti che possono essere scritti su disco quando non vengono utilizzati. Si possono verificare dei problemi di memoria se questo valore è maggiore di 250 MB (o 170 MB con l'opzione /3GB). Un ID evento tipico 2020 è memorizzato nel registro eventi di sistema.
Memoria\Pagine liberate al secondo indica la frequenza di lettura o scrittura delle pagine da o su disco per risolvere gli errori di pagina di memoria hardware. Se il valore è maggiore di 1.000, a causa di paging eccessivo, si possono verificare dei problemi di memoria.

﻿Collo di bottiglia del processore
Un processore sopraffatto può dipendere dal processore stesso che non offre abbastanza potenza oppure da un'applicazione inefficiente. Verificare se il processore impiega molto tempo nell'esecuzione del paging a causa di memoria fisica insufficiente. Quando si esamina un potenziale collo di bottiglia del processore, i tecnici del supporto Microsoft utilizzano i seguenti contatori.
Processore\ % Tempo processore indica la percentuale di tempo impiegata dal processore per eseguire un thread attivo. Se la percentuale è superiore all'85%, il processore viene sopraffatto e il server potrebbe richiedere un processore più veloce.
Processore\ % Tempo utente indica la percentuale di tempo trascorso in cui il processore si trova in modalità utente. Se tale valore è elevato, il server è occupato con l'applicazione. In questo caso, una soluzione possibile è ottimizzare l'applicazione che esaurisce le risorse del processore.
Processore\ % Tempo di Interrupt indica il tempo trascorso dai processori ricevendo e servendo interrupt hardware durante intervalli di campionamento specifici. Tale contatore indica un possibile problema hardware se il valore è maggiore del 15%.
Sistema\Lunghezza coda processore indica il numero di thread nella coda del processore. Il server non dispone di abbastanza potenza di processore se il valore è maggiore del doppio del numero di CPU per un lungo periodo di tempo.

Collo di bottiglia della rete
Certamente, un collo di bottiglia della rete influisce sulla capacità del server di inviare e ricevere i dati attraverso la rete. Può verificarsi un problema con la scheda di rete sul server oppure la rete potrebbe essere satura ed è necessario segmentarla. Puoi utilizzare i seguenti contatori per eseguire una diagnosi dei possibili colli di bottiglia della rete.
Interfaccia di rete\Totale byte/sec indica la frequenza con cui i byte vengono inviati e ricevuti su ogni scheda di rete, inclusi i caratteri di framing. Se viene utilizzato oltre il 70% dell'interfaccia, la rete è satura. Per una NIC da 100 Mbps, l'interfaccia utilizzata è 8,7 MB/sec (100 Mbps = 100000 kbps = 12,5 MB/sec* 70%). In tal caso, potresti decidere di aggiungere una scheda di rete più veloce o segmentare la rete.
Interfaccia di rete\Lunghezza della coda di output indica la lunghezza della coda dei pacchetti in uscita, misurata in pacchetti. Se la lunghezza è superiore a due, si verifica una saturazione di rete. Per risolvere questo problema, aggiungi una scheda di rete più veloce o segmenta la rete.

Collo di bottiglia del processo
Le prestazioni del server peggiorano notevolmente se il processo presenta un funzionamento anomalo oppure i processi non sono ottimizzati. La perdita di handle e thread farà rallentare un server e un utilizzo eccessivo del processore porterà al blocco del server. I seguenti contatori sono indispensabili per diagnosticare i colli di bottiglia relativi al processo.
Processo\Conteggio degli handle misura il numero totale di handle che sono attualmente aperti da un processo. Questo contatore indica una probabile perdita di handle se il numero è maggiore di 10.000.
Processo\Conteggio dei thread indica il numero di thread attualmente attivi in un processo. Si potrebbe verificare una perdita di thread se tale numero è maggiore di 500 tra il numero minimo e massimo dei thread.
Processo\ Byte privati indica la quantità di memoria che questo processo ha allocato e che non può essere condivisa con altri processi. Se il valore è maggiore di 250 tra il numero minimo e massimo di thread, si potrebbe verificare una perdita di memoria.

Conclusioni
Ora conosci i contatori utilizzati dai tecnici del supporto Microsoft per diagnosticare i vari colli di bottiglia. Certamente, è probabile che utilizzerai un gruppo di contatori preferiti scelti apposta per soddisfare le tue esigenze specifiche. Puoi risparmiare tempo evitando di aggiungere i contatori tramite salvataggio manuale ogni volta che controlli i server. Fortunatamente, è presente un'opzione in Performance Monitor che consente di salvare in un modello tutti i contatori per un utilizzo futuro.
A coloro che si chiedono se è meglio eseguire Performance Monitor localmente o in modalità remota e quale peggioramento subiscono esattamente le prestazioni se Performance Monitor viene eseguito localmente, rispondo che tutto dipende dall'ambiente in uso. Il peggioramento delle prestazioni sul server è quasi trascurabile se gli intervalli sono impostati su un intervallo minimo di cinque minuti.
Performance Monitor può essere eseguito localmente se si è a conoscenza di un problema di prestazione sul server, poiché lo strumento potrebbe non essere in grado di acquisire i dati da un computer remoto quando le risorse sul server esauriscono. L'esecuzione in modalità remota da un computer centrale è più adatta quando si desidera monitorare o eseguire dei valori di riferimento per server multipli.

Steven Choy è Senior Premier Field Engineer presso la divisione Premier Field Engineering di Microsoft. Ha supportato agenzie governative e clienti commerciali nella gestione dei progetti di distribuzione desktop e migrazione, la gestione delle patch e i criteri di gruppo. Attualmente è impegnato con la virtualizzazione e l'integrità del server.


System Center
Windows PowerShell in System Center Operations Manager
Marco Shaw
Panoramica:
  • La shell dei comandi di OpsMgr
  • Il provider di monitoraggio di OpsMgr
  • Automazione di comuni operazioni di gestione
  • Alcuni esempi reali di Windows PowerShell

Indice
La shell dei comandi di OpsMgr
Il provider di monitoraggio di OpsMgr
Automazione delle operazioni comuni
Il mondo reale
Conclusioni
System Center Operations Manager 2007 (OpsMgr) consente agli amministratori di accedere a Windows PowerShell, un nuovo e potente linguaggio di script utile per l'automazione delle operazioni. Dalla data di rilascio al pubblico, nel novembre 2006, questo software è stato scaricato più di due milioni di volte.
In quest'articolo parlerò di Windows PowerShell® e della sua applicazione a Operations Manager. Tratterò alcune delle attività comuni che Windows PowerShell può aiutare a realizzare in tutta semplicità e in modo automatico. Inoltre, proporrò alcuni siti Web che forniscono script utili e spiegazioni. Ho raccolto pareri e post da svariati blog di esperti di Windows PowerShell.
Sebbene Microsoft abbia iniziato a rilasciare versioni CTP (Community Technology Preview) di Windows PowerShell 2.0, queste non sono ancora da considerare adatte a un ambiente di produzione e non sono state testate con OpsMgr.

La shell dei comandi di OpsMgr
In OpsMgr, si può accedere a Windows PowerShell attraverso la shell dei comandi. Questa è simile all'ambiente di Windows PowerShell predefinito, ma in più carica un file di console e uno script che inizializza l'ambiente con cmdlet e funzioni di OpsMgr e una connessione predefinita.
È possibile avviare la shell dei comandi dall'icona nel menu Start di OpsMgr o facendo clic col pulsante destro del mouse sul nome di un computer nella console dell'interfaccia utente di OpsMgr (vedere Figura 1). In questo modo ci si troverà direttamente nel percorso dell'unità di monitoraggio di OpsMgr (che discuterò a breve).
Figura 1 Apertura della shell dei comandi dall'interfaccia utente di OpsMgr (fare clic sull'immagine per ingrandirla)
Windows PowerShell si interfaccia con OpsMgr attraverso un SDK. Per la felicità degli amministratori, sono già disponibili molti cmdlet per le attività più comuni da automatizzare o da eseguire dalla riga di comando. Se non esiste un cmdlet per una particolare attività, è possibile utilizzare Windows PowerShell per interagire con l'SDK.
I comandi messi a disposizione dalla shell dei comandi di Operations Manager sono contenuti in uno snap-in, una DLL che viene caricata da Windows PowerShell e che contiene dei cmdlet per l'amministrazione di OpsMgr. Lo snap-in contiene inoltre il provider di monitoraggio di Windows PowerShell per Operations Manager. Noto anche come provider di monitoraggio, questo strumento consente l'esplorazione di connessioni, gruppi e oggetti, quasi come si naviga in un file system.
Come illustrato in Figura 2, è possibile ottenere un elenco di tutti i cmdlet propri di OpsMgr utilizzando il cmdlet Get-OperationsManagerCommand. (Nella prima versione questa era una funzione che non supportava il completamento tramite tab; dopo l'introduzione del SP1 è diventato un cmdlet.) La versione originale di Operations Manager conteneva 74 cmdlet, mentre con OpsMgr SP1 il numero è arrivato a 87.
Figura 2 Ottenere l'elenco dei cmdlet di OpsMgr (fare clic sull'immagine per ingrandirla)

Il provider di monitoraggio di OpsMgr
Utilizzando il cmdlet Set-Location o l'alias cd, è possibile navigare attraverso lo schema dei gruppi e dei computer. Lo schema di base dell'unità di controllo è simile a questo:
Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)
Da qui è possibile raggiungere oggetti più specifici. Notare che in questo esempio sto trattando un ambiente di base con soltanto un server di gestione singolo. Il primo server di gestione installato in un gruppo di gestione è chiamato server di gestione radice (RMS).
Dopo essere stata avviata, la shell dei comandi crea un'unità chiamata Monitoring e mappa l'unità alla directory principale del provider di monitoraggio di OperationsManager. Per concludere, imposta la posizione o il percorso attuale alla directory principale dell'unità di monitoraggio. A questo punto la shell dei comandi ricerca nel registro di sistema il nome dell'RMS predefinito al quale connettersi. Se la connessione all'RMS viene stabilita, la posizione o il percorso attuale vengono impostati alla connessione o all'RMS, come illustrato in Figura 3.
Figura 3 La posizione della shell dei comandi viene impostata all'RMS (fare clic sull'immagine per ingrandirla)

Automazione delle operazioni comuni
Vediamo adesso come Windows PowerShell può controllare alcune delle attività di gestione più comuni.
Controllare la modalità di manutenzione Qualunque sia l'operazione che si vuole eseguire, generalmente si vogliono specificare la data e l'ora di esecuzione. Darò adesso un breve sguardo al cmdlet Get-Date per illustrare la semplicità di questa operazione. Nella Figura 4 vengono mostrati alcuni esempi.
Figura 4 Utilizzo del cmdlet Get-Date (fare clic sull'immagine per ingrandirla)
Come si può vedere ho creato una variabile $date che contiene un oggetto con l'ora corrente. Successivamente, ho utilizzato alcuni dei metodi documentati e supportati dall'oggetto per mostrare come è possibile ottenere facilmente la data e l'ora, cinque minuti o cinque ore più avanti. Se avessi voluto ottenere un'ora precedente, avrei digitato semplicemente (-5) invece di (5).
Se si vogliono bloccare tutti gli avvisi provenienti da un computer, è possibile attivare la modalità di manutenzione. Se non si vuole agire su un computer o su un gruppo, OpsMgr 2007 consente di porre solamente un servizio di Windows® o anche un particolare database in modalità di manutenzione. Esistono tre cmdlet che si occupano in particolare delle operazioni con la modalità di manutenzione: Get-MaintenanceWindow, New-MaintenanceWindow e Set-MaintenanceWindow.
Per porre un computer in modalità di manutenzione dalla shell dei comandi, selezionare il computer o il controllo desiderato utilizzando il provider di monitoraggio e richiamare il cmdlet New-MaintenanceWindow, come illustrato in Figura 5. Come si vede, quest'azione pone il computer denominato Denver.contoso.com in modalità di manutenzione. Ho inoltre impostato l'ora di avvio della finestra di manutenzione sull'ora corrente e l'ora di interruzione esattamente a un'ora dopo. Notare che ponendo un computer in modalità di manutenzione utilizzando questo metodo non verranno interrotti tutti gli avvisi, poiché tutte le istanze di HealthService e HealthServiceWatcher per quest'oggetto sono ancora attivate.
Figura 5 Utilizzo del cmdlet New-MaintenanceWindow (fare clic sull'immagine per ingrandirla)
Boris Yanushpolsky, Program Manager nel team di Microsoft OpsMgr, ha fornito dell'utilissimo codice di Windows PowerShell che può essere utilizzato per porre tutti gli oggetti che fanno riferimento a un computer in modalità di manutenzione. Egli ha anche spiegato come utilizzare questo codice dopo avere creato uno script. Per avere più informazioni su questo argomento, visitare il suo blog a blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx.
A volte è necessario determinare se degli oggetti si trovano erroneamente in modalità di manutenzione. Tuttavia in casi come questo, scorrere tutti gli oggetti potrebbe essere un'operazione eccessivamente pesante da eseguire. Boris Yanushpolsky ci viene fortunatamente in soccorso ancora una volta con uno script di Windows PowerShell che utilizza l'SDK di OpsMgr. È possibile copiare il codice direttamente da un post del suo blog (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) e incollarlo in una finestra della shell dei comandi. In questo modo si otterrà un elenco di tutti gli oggetti che si trovano in modalità di manutenzione.
Quando un oggetto è in modalità di manutenzione, si potrebbe volere terminare il periodo di manutenzione prima dell'ora precedentemente specificata. Conoscendo bene Windows PowerShell, si potrebbe essere tentati di cercare un cmdlet che contenga le parole "remove" o "stop". In realtà, il cmdlet da utilizzare in questo caso è Set-MaintenanceWindow, come mostrato in Figura 6.
Figura 6 Utilizzo di Set-MaintenanceWindow per modificare l'ora di interruzione (fare clic sull'immagine per ingrandirla)
Gestione degli agenti Molto spesso gli amministratori lavorano con gli agenti. Esistono sei cmdlet e una funzione (in questa versione) che operano con gli agenti. È possibile ottenere un elenco degli agenti con questo comando:
Get-Command *-agent*
Dopo il rilascio della versione SP1, Install-AgentByName viene fornito come cmdlet, piuttosto che come funzione. Si consiglia di utilizzare il cmdlet Install-AgentByName, poiché esso fornisce un livello maggiore di supporto e coerenza.
La guida fornita con la shell dei comandi contiene alcuni buoni esempi dell'utilizzo dei cmdlet Install-Agent e Uninstall-Agent. Roger Sprague, Senior Software Design Engineer nel team di Microsoft OpsMgr, ha pubblicato un metodo alternativo sul suo blog che ripropongo in Figura 7 (trovate il post originale su blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx).
Questo script funziona in maniera ottimale con la versione RTM di OpsMgr (è necessario trovarsi nella directory principale del provider di monitoraggio, che in quest'articolo è monitoring:\oxford.contoso.com). Lo script non funziona invece con la versione SP1 di OpsMgr SP1. Per farlo funzionare con questa versione di OpsMgr, il primo comando in Figura 7 dovrebbe essere modificato come segue:
$managementServer = Get-RootManagementServer
Figura 7 Installazione di un agente
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects
A questo punto l'agente è installato sul sistema remoto da monitorare. Prima dell'avvio del monitoraggio, il server apposito deve accettare il nuovo agente. Se non si esegue nessun'altra operazione, il server di monitoraggio accetterà automaticamente il nuovo agente da monitorare. Questo processo di accettazione può anche essere velocemente individuato utilizzando il cmdlet Get-AgentPendingAction. Questa semplice riga di codice individua velocemente il processo di accettazione dell'agente:
Get-AgentPendingAction | Where Object {$_.AgentName –like
'computer*'} | Approve-AgentPendingAction
Inviando questo al Reject-AgentPendingAction, piuttosto che all'Approve-AgentPendingAction, è possibile bloccare l'accettazione di quest'agente dal server di OpsMgr, in caso l'azione sia ancora in sospeso. Se invece l'operazione è già stata eseguita, sarà necessario utilizzare il cmdlet Uninstall-Agent.
Come detto prima, è anche possibile utilizzare Install-AgentByName per specificare il computer sul quale installare l'agente direttamente dalla riga di comando.
Lavorare con i management pack Esistono quattro cmdlet che ci aiutano con le varie operazioni sui management pack. È possibile elencarli digitando quanto segue:
Get-Command –noun ManagementPack
Questo semplice comando fornisce i management pack attualmente installati e i relativi numeri di versione:
Get-ManagementPack | Format-Table –autosize
Adesso utilizzerò la shell dei comandi per installare due comuni management pack utilizzando questi programmi di installazione:
  • Internet Information Services System Center Operations Manager2007 Management Pack.msi
  • Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi.
Poiché il mio scopo è di mostrare come la shell dei comandi può semplificare l'esecuzione di operazioni periodiche, utilizzerò il numero minore di comandi possibile (come illustrato in Figura 8). Avrei potuto modificare la procedura di installazione e passare il flag "quiet" al programma di installazione (i file .msi), ma ho voluto scegliere la posizione dove i file sarebbero stati manualmente estratti.
Figura 8 Installazione dei management pack (fare clic sull'immagine per ingrandirla)
Adesso devo installare le librerie comuni col seguente comando:
Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
Successivamente, installo gli altri management pack richiesti:
Get-ChildItem –Path C:\MPs –filter *200?.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
Come mostrato in Figura 9, la guida fornita con la shell dei comandi propone un esempio eccellente su come esportare i management pack non sottoposti a sealing, utilizzando il cmdlet Export-ManagementPack. Se si vogliono esportare tutti i management pack, modificare questa riga
$mps=Get-ManagementPack |
Where-Object {$_.Sealed –eq $false}

$mps=Get-ManagementPack
Figura 9 Esportazione di un management pack (fare clic sull'immagine per ingrandirla)
Operare con i ruoli utente Il cmdlet Get-UserRole fornisce alcune funzionalità per l'amministrazione degli utenti. Stranamente, non fornisce un cmdlet Set, sebbene generalmente non si necessiti di fare modifiche o aggiornamenti (come specificato nella documentazione dell'SDK di Windows PowerShell). Come si può vedere in Figura 10, inizialmente ottengo un elenco dei ruoli utente correnti e poi aggiungo un utente al gruppo Read-Only Operators (vedere Figura 11).
Figura 10 Visualizzazione di ruoli utente (fare clic sull'immagine per ingrandirla)
Figura 11 Aggiunta di un utente (fare clic sull'immagine per ingrandirla)
Attivazione degli Audit Collection Services (ACS) Gli ACS rappresentano una nuova funzionalità opzionale presente in Operations Manager 2007 che fornisce una modo centralizzato di trattare informazioni di controllo della protezione. Gli ACS non sono attivati per impostazione predefinita, ma possono essere configurati in occasione di una nuova distribuzione di OpsMgr.
Windows PowerShell risulta estremamente utile nel caso si volesse automatizzare l'installazione e l'attivazione di un ampio numero di agenti per gli ACS. Durante la fase beta di OpsMgr, Microsoft ha rilasciato uno script che permette di attivare gli ACS su tutti gli agenti. Neale Browne, collaboratore e blogger di SystemCenterForum.org, è andato un passo più avanti, aggiungendo il supporto per parametri aggiuntivi.
Il sito SystemCenterForum.org (una community che fornisce soluzioni per Microsoft® System Center) ha rilasciato due script per Windows PowerShell che permettono di automatizzare l'installazione degli ACS. Per installare tutti gli agenti appartenenti a un gruppo ben preciso è possibile scaricare questo file systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Per installare tutti gli agenti monitorati, scaricare systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip.
Abilitare un proxy degli agenti L'ambiente di OpsMgr è in grado di contenere periferiche monitorate senza agenti. È necessario assegnare queste periferiche a un server di gestione o a una periferica gestita da agenti che fornirà il controllo remoto. In questa pagina systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell, è possibile trovare dettagli sul funzionamento di uno script di Windows PowerShell che permette di configurare numerosi agenti. Una versione aggiornata dello script è disponibile qui: systemcenterforum.org/wp-content/uploads/SetAgentProxyBulk_FQDN.zip.
Ci sono altri casi nei quali determinati management pack richiedono l'impostazione di un agente come proxy. Per ulteriori dettagli consiglio di consultare la documentazione del management pack.

Il mondo reale
Ecco alcuni esempi reali per dimostrare ancora come Windows PowerShell può essere estremamente utile per l'automazione di operazioni.
Risoluzione di avvisi Vi siete mai trovati a dovere cancellare numerosi avvisi per un determinato computer? In alcuni casi per qualche motivo, un'applicazione non riesce a completare un'operazione o gli avvisi non vengono risolti attivamente. Ecco qui un comando di una sola riga che risolverà tutti gli avvisi il cui stato di risoluzione si trova a zero:
Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null
Il prossimo esempio realizza la stessa operazione del precedente, ma lo fa molto più velocemente in un ambiente più grande e con molti più avvisi:
Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null
La differenza di prestazioni è dovuta al parametro di criteri utilizzato. Il valore passato viene inviato direttamente al database SQL Server® e soltanto i dati rilevanti vengono restituiti. In questo modo si riduce il numero degli oggetti da restituire alla console di Windows PowerShell.
Adesso si ha a disposizione un modo veloce per rimuovere tutti gli avvisi in sospeso per un determinato computer. A seconda dell'ambiente in uso, è possibile impostare questo script per l'esecuzione automatica.
Infine, ecco un comando veloce che permette di visualizzare tutti gli avvisi per una data specifica:
Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''
È molto semplice modificare il valore della data ed è inoltre possibile inviare l'output al cmdlet Resolve-Alert.
Testare gli avvisi A volte si vogliono monitorare alcuni eventi nel Visualizzatore eventi di Windows e fare dei test. Queste due righe creeranno velocemente una voce nel registro degli eventi:
$api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")
Per impostazione predefinita, questo script scriverà tuttavia sul registro eventi di Operations Manager, che non è probabilmente il primo posto dove si cerca un determinato evento. Fortunatamente, Stefan Stranger, Premier Field Engineer a Microsoft, ha scritto uno script che permette di creare eventi nel Visualizzatore eventi di Windows e fornisce maggiore flessibilità, dal momento che è capace di scrivere su un determinato registro. È possibile trovare questo script all'indirizzo go.microsoft.com/fwlink/?LinkId=120308. (Stefan ha compresso lo script in un file CAB. Sarà necessario scaricare il file e fare clic col tasto destro del mouse per estrarlo).
Si noti che utilizzando lo script di Stefan, il valore inserito per l'origine eventi determina il registro sul quale verrà effettuata la scrittura. Probabilmente il modo più facile per assicurarsi che l'avviso sia diretto verso il registro giusto è quella di aprire il Visualizzatore eventi di Windows e individuare la sorgente dell'ultima scrittura.
Impostazione del proprietario In alcuni casi può essere utile impostare automaticamente il proprietario di un avviso. Ecco qui un modo semplice per eseguire questa operazione dalla shell dei comandi:
$alert = Get-Alert
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")
La prima riga di questa porzione di codice ricava l'ID di un particolare oggetto avviso e lo passa alla variabile $alert. Nella seconda riga, questa variabile viene utilizzata per impostare il proprietario. Infine viene applicato l'aggiornamento al database di OpsMgr. Controllando il proprietario dell'avviso col seguente comando, è possibile vedere che esso è stato modificato:
Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner
Per impostare il proprietario per un'intera serie di avvisi, è possibile semplificare il codice come segue:
Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}
Ripristino dello stato di controllo Alcuni agenti non monitorati potrebbero subire dei cambiamenti. In questi casi potrebbe essere necessario ripristinare rapidamente tutti gli agenti a uno stato di controllo totale e poi cercare di determinare l'accaduto. Eseguendo lo script mostrato in Figura 12 direttamente dalla shell dei comandi si dovrebbe ripristinare il controllo totale di tutti gli agenti coinvolti.
Figura 12 Ripristino dell'archivio del servizio di integrità
$all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}
Osservare il codice riportato in Figura 12. Dopo avere dichiarato una variabile, si ottiene un elenco di tutti gli agenti su questo RMS e vengono filtrati quelli che sembrano presentare dei problemi. Poi viene eseguita un'attività in modo asincrono per riavviare l'archivio del servizio di integrità degli agenti presenti nell'elenco filtrato.
Associare avvisi ai management pack Nella Figura 13viene mostrato come ottenere un elenco di tutti gli avvisi e i management pack ai quali sono associati.
Alcuni piccoli accorgimenti applicati al codice hanno permesso di risolvere tutti i nomi di management pack. I cmdlet utilizzati potranno variare a seconda che l'avviso sia una regola o un controllo. (Notare che nella Figura 13 è stato necessario implementare una piccola soluzione alternativa per il cmdlet di Get-Monitor. Dalla versione SP1 di OpsMgr, il cmdlet supporta un nuovo parametro ID che permette di semplificare leggermente il codice).
Figura 13 Individuare il management pack
Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}
Creare report facilmente Quando si aggiorna il proprio ambiente, potrebbe essere utile controllare le versioni di tutti gli agenti installati. Basta soltanto un semplice script per stampare un report:
Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}
Nella Figura 14 viene mostrato l'output dello script. Questo script è una versione più elaborata degli esempi presenti in questa pagina systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.
Figura 14 Output che mostra le versioni di alcuni agenti (fare clic sull'immagine per ingrandirla)
Pianificazione di un'attività In alcuni casi risulta necessario eseguire regolarmente uno script di Windows PowerShell. Poniamo che si utilizzi un client per connettersi e gestire un server di OpsMgr e che si abbiano gli strumenti di amministrazione di OpsMgr installati in locale. Supponiamo inoltre che si voglia creare un report sulla versione dell'agente ogni giorno e salvare l'output in un file, il cui nome sarà la data corrente. È possibile utilizzare l'utilità di pianificazione di Windows per eseguire lo script dal proprio computer locale.
Per fare ciò, è necessario semplicemente creare un'attività nuova, specificando powershell.exe come programma da eseguire (in genere si trova in C:\Windows\System32\WindowsPowerShell\v1.0). Successivamente, è necessario modificare l'attività e impostare il comando con qualcosa del genere:
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
Come si vede in Figura 15, è stato necessario fare alcune modifiche al codice originale di Windows PowerShell. È stato necessario aggiungere lo snap-in di PowerShell di OpsMgr, creare un'unità di controllo mappata al provider di OperationsManagerMonitoring e infine creare una connessione all'RMS. Per avere a disposizione funzioni specifiche di OpsMgr, ho inoltre caricato lo script personalizzato di Windows PowerShell OpsMgr (Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1).
Figura 15 Pianificazione dello script agent-version
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file
Ma non è tutto. Come si può vedere ogni volta che viene eseguita l'attività, se qualcuno ha eseguito l'accesso al computer, una finestra della console appare sullo schermo. Un piccolo trucco per evitare ciò è fornito da Don Jones e Jeffery Hicks della Sapien. Il codice è disponibile qui blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell.
Fondamentalmente è necessario incorporare lo script all'interno di un VBScript. È quindi necessario è necessario utilizzare il codice mostrato in Figura 16 piuttosto che richiamare il seguente dall'attività pianificata:
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
Figura 16 Nascondere i popup
Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34)

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0
L'attività utilizza quindi il programma wscript.exe e il comando dovrebbe assomigliare a qualcosa del genere:
C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs
Infine, posso creare dei report automatici e il processo è nascosto agli utenti connessi.

Conclusioni
Ho dato uno sguardo alle nuove caratteristiche disponibili in OpsMgr 2007. Questo non è altro che una minima parte di ciò che è possibile fare con Windows PowerShell per l'amministrazione di OpsMgr.
Vorrei ringraziare tutti gli utenti citati nell'articolo, come pure Pete Zerger, fondatore di MOM MVP e SystemCenterForum.org, per il tuo notevole contributo.

Marco Shaw è un analista di sistemi informatici per un'azienda di telecomunicazioni canadese. Lavora nel mondo dell'informatica da più di 10 anni ed è stato recentemente riconosciuto come MVP per Windows PowerShell. Marco è anche vice direttore della nuova community di PowerShell powershellcommunity.org. Trovate Il suo blog su marcoshaw.blogspot.com.


Internet Information Services (in inglese)
Scalare applicazioni ASP.NET: esperienza acquisita
Richard Campbell
Panoramica:
  • L'importanza della collaborazione tra sviluppatori e professionisti IT
  • Capire le strategie di scalabilità principali
  • Condividere la conoscenza tra i team
  • Concordare le competenze di base

Indice
I fondamenti della scalabilità
Riunire i team
Cosa hanno bisogno di sapere gli amministratori dagli sviluppatori?
Cosa hanno bisogno di sapere gli sviluppatori dagli amministratori?
Ancora sulla scalabilità
Uno sforzo comune
In qualità di consulente, la scalabilità dell'applicazione ASP.NET di cui mi sono occupato è sempre stata il risultato di uno sforzo congiunto fra gli sviluppatori (i realizzatori) e gli amministratori di rete (gli utilizzatori). Sfortunatamente, non sempre all'inizio dello sviluppo di un'applicazione
si considera indispensabile questa collaborazione. Non ho mai avuto l'opportunità di essere coinvolto sin dall'inizio dello sviluppo di un'applicazione. Sono stato chiamato in causa sempre verso la fase finale, cioè quella critica.
La verità è che nessuna applicazione scala efficacemente sin dall'inizio, è impossibile ottenere un risultato impeccabile nella prima versione. Per scalare un'applicazione in modo soddisfacente è necessario capire come è stata creata e l'ambiente nel quale viene eseguita. In altre parole, si ha bisogno di informazioni sia da parte degli sviluppatori che di coloro che si occupano della rete. Senza condividere entrambe le conoscenze non si può raggiungere un buon risultato.

I fondamenti della scalabilità
Prima di lanciarci nel pieno della questione, iniziamo vedendo cosa è necessario per scalare un'applicazione ASP.NET. Generalmente vengono utilizzate due strategie fondamentali: specializzazione e distribuzione. Le applicazioni ASP.NET scalabili più grandi fanno uso generalmente di entrambe le strategie. Tutte le dritte sulla scalabilità delle applicazioni ASP.NET presenti nei testi rientrano in qualche modo in una delle due strategie.
La specializzazione prevede la separazione degli elementi dell'applicazione così che essi possano essere scalati separatamente. Si potrebbero ad esempio creare server di immagini dedicati piuttosto che utilizzare gli stessi server impiegati per il rendering delle pagine di ASP.NET. La configurazione ottimale di un server di immagini è infatti abbastanza diversa da quella di un server ASP.NET. Separare le richieste di immagini dal resto dell'applicazione dà inoltre la possibilità di utilizzare risorse di terze parti. Lo stesso approccio può essere applicato ad altri tipi di risorse.
L'altra strategia menzionata prima, prevede invece la distribuzione simmetrica dell'applicazione su più server, i quali costituiscono una cosiddetta Web farm. Le applicazioni ASP.NET sono particolarmente adatte alla distribuzione perché ogni richiesta di pagina singola è abbastanza piccola e le interazioni tra gli utenti sono indipendenti. La strategia di distribuzione è la vera manifestazione della scalabilità orizzontale, dove più server dalle prestazioni medie lavorano insieme alle richieste degli utenti. Con la scalabilità verticale invece abbiamo un server con prestazioni altissime che si occupa di tutto.
Utilizzando contemporaneamente entrambi gli approcci si aumenta l'efficienza. È possibile ad esempio distribuire soltanto gli elementi dell'applicazione che richiedono prestazioni aggiuntive. Se si è creato un server di immagini dedicato, ma questa soluzione non risulta tuttavia adeguata, è possibile aggiungere altri server dello stesso tipo, piuttosto che per l'intera applicazione. È importante tenere presenti queste strategie per migliorare le prestazioni e la scalabilità della propria applicazione ASP.NET.

Riunire i team
Ad un certo punto del ciclo di vita di ogni applicazione ASP.NET è molto probabile che gli sviluppatori e il personale di rete/IT si debbano incontrare. Nel migliore dei casi questa riunione si terrà prima della distribuzione dell'applicazione. In alcuni casi però le due parti si incontrano soltanto dopo il sorgere di alcuni problemi, ad esempio quando l'applicazione funziona benissimo nell'ambiente di test, ma è lenta quando distribuita agli utenti. (È in casi come questi che consulenti come me vengono chiamati in causa).
Quando gli sviluppatori e gli amministratori di rete si incontrano, l'obiettivo primario è quello di confrontarsi. Gli sviluppatori conoscono l'applicazione nei dettagli, mentre gli amministratori di rete hanno una conoscenza più approfondita dell'ambiente di funzionamento. Gli uni devono capire i dati degli altri e prima si incontrano meglio è.
Questa riunione non dovrebbe essere organizzata soltanto al sorgere dei problemi. Senza una profonda sinergia fra i due team è estremamente difficile identificare le cause delle scarse prestazioni dell'applicazione. Inoltre, è troppo facile decidere a priori che il problema è causato da una mancanza da parte dell'altro team. Di fatto non è mai così. Entrambi i team devono cooperare per risolvere qualsiasi problema estremamente complicato.
Anche quando non ci sono problemi notevoli da affrontare, tali riunioni possono tuttavia essere realmente stimolanti. Le riunioni che ho seguito si sono generalmente svolte con gli amministratori da un lato del tavolo e gli sviluppatori dall'altro. Sembra che guardarsi negli occhi aiuti a risolvere i problemi. Per ottenere una discussione costruttiva, io sottolineo sempre lo scopo della riunione, appunto quello di scambiarsi conoscenza. Non importa chi inizia. Inizierò qui con ciò che gli amministratori hanno bisogno di sapere dagli sviluppatori.

Cosa hanno bisogno di sapere gli amministratori dagli sviluppatori?
Ogni applicazione ASP.NET ha le sue sfumature, ma ci sono degli elementi fondamentali comuni a tutte. Il file web.config è uno di questi (vedere Figura 1). Il file Web.config è un punto di incontro tra gli sviluppatori e il personale di rete. A volte sono i primi a configurarlo, mentre in altri casi sono gli amministratori a farlo. In ogni caso, ciò che è contenuto nel file web.config mette dei limiti alla configurazione hardware e di rete e ha un notevole impatto sul modo di operare dell'applicazione. Per analizzare ogni piccolo aspetto del file web.config non basterebbe un libro intero; ciò che è importante nella nostra discussione è che entrambi i team devono analizzare il file web.config e convenire sulla configurazione. Devono inoltre stimare l'impatto che le varie impostazioni avranno sull'applicazione e sull'ambiente.
Figura 1 Un file web.config di base che mostra alcune impostazioni dell'applicazione e la configurazione personalizzata degli errori (fare clic sull'immagine per ingrandirla)
Ad esempio, la sezione <authorization> del file web.config specifica come gli utenti saranno autenticati nell'applicazione e definisce così una dipendenza. Se l'applicazione utilizza l'autenticazione di Windows®, allora essa potrebbe dipendere da Active Directory®. Se invece utilizza l'autenticazione basata su moduli, la dipendenza è su un archivio dati di account utente. Discutere tutto ciò è certamente estremamente utile.
È inoltre importante discutere la sezione <customErrors> in quanto essa riguarda il modo in cui gli errori verranno visualizzati agli utenti. Questa non è un'impostazione complessa, ma vale la pena discuterne per capire quali saranno le pagine di errore. All'inizio del ciclo collaborativo probabilmente non ci sono pagine di errore personalizzate e anche questo è un argomento da discutere.
Anche la sezione <appSettings> del file web.config può essere fonte di significative discussioni. È qui in genere che gli sviluppatori mettono in rilievo valori globali, come le stringhe di connessione ai database. Da questo argomento possono scaturire molte dipendenze e strategie per la pianificazione di failover, migrazione e così via. Dal momento che la sezione <appSettings> è interamente personalizzabile e di conseguenza può contenere moltissime impostazioni, un'ampia discussione potrebbe essere necessaria. Spesso in questa sezione si trovano valori che in realtà non vengono utilizzati in nessuna parte dell'applicazione.
Anche se gli sviluppatori non utilizzano <appSettings>, il personale di rete potrebbe volere utilizzare questa sezione. Infatti, avendo tutte le stringhe di connessione ai database, si potrebbe creare un'efficace e semplice strategia di failover. Se il server di database cessa di funzionare, può essere inserita una stringa di sostituzione per indicare a quale server alternativo puntare. Cogliere quest'opportunità nelle prime fasi del ciclo di sviluppo può aumentare l'affidabilità e la gestibilità dell'applicazione.
Un altro valore estremamente importante del file web.config per quanto riguarda la scalabilità è <sessionState>. Questo tag determina la posizione dove verranno memorizzati i dati della sessione dell'applicazione. Per impostazione predefinita, i dati della sessione vengono memorizzati "InProc" o nello spazio del processo dell'applicazione ASP.NET. Se i dati della sessione sono configurati come in-process il bilanciamento del carico di lavoro deve essere rafforzato. Le richieste di un utente verranno servite dal server nel quale risiedono i dati della sessione. Su questo argomento ci sarà una lunga conversazione tra gli sviluppatori e gli amministratori di rete dal momento che questa scelta ha un notevole impatto sulla scalabilità e sul failover. Discutere questo fattore nelle prime fasi del ciclo di vita dell'applicazione può risparmiare notevoli grattacapi in fase di debugging.
Quando la conversazione arriva allo stato della sessione, è facile definire i requisiti del bilanciamento del carico. Alcuni ambienti dispongono di hardware dedicato con varie funzionalità per gestire il bilanciamento del carico. Queste funzionalità avranno una certa valenza solo se l'applicazione sarà in grado di gestirle. Ho già visto casi in cui hardware per il bilanciamento del carico era utilizzato in abbinamento ad applicazioni ASP.NET con dati della sessione in-process. Di conseguenza, occasionalmente le sessioni venivano perse senza alcun motivo. Ciò che sembrava un bug nell'applicazione era in realtà un errore di configurazione.
Il personale di rete deve naturalmente sapere dagli sviluppatori quale schema di bilanciamento del carico può funzionare con l'applicazione. Entrambe le parti hanno qualcosa da aggiungere quando si tratta di discutere quali schemi di bilanciamento del carico sono disponibili e quali possono funzionare con l'applicazione. Discutere di questa parte della configurazione in una fase preliminare del ciclo di vita dell'applicazione potrebbe già aiutare a scartare uno schema in-process.
Quando un'applicazione ASP.NET è pronta per la distribuzione (o è già nella sua fase iniziale di distribuzione), lo staff degli sviluppatori avrà già un'idea abbastanza chiara sulle aree dell'applicazione che sono veloci o lente. E soprattutto sapranno quali parti dell'applicazione potrebbero costituire dei colli di bottiglia o fonti di errori. Se il personale di rete è a conoscenza di questi colli di bottiglia, può già prepararsi ad affrontare questi problemi e forse anche bloccarli sul nascere.
Ho lavorato una volta con un'applicazione che doveva caricare un enorme carico di dati ogni notte, durante i tempi di inattività dell'applicazione. Gli sviluppatori avevano creato il meccanismo di caricamento dei dati, l'avevano testato e ne conoscevano molto bene il funzionamento. Sapevano che era molto pesante per il database, ma allo stesso tempo lo ritenevano un metodo efficace e ottimale per la risoluzione del problema.
Ma non avevano mai comunicato al team di rete che questo processo esisteva o che era pianificato per l'esecuzione all'una del mattino, proprio quando veniva eseguito il backup del database. Il database è rimasto online, ma durante la fase di backup operava molto più lentamente, dal momento che tutte le transazioni dovevano essere trattenute nell'apposito registro.
Il problema venne identificato solo quando la concomitanza del processo di backup e del caricamento dei dati risultò nella mancanza di spazio libero su disco. Il problema venne risolto, dopo giorni di problemi, semplicemente spostando il caricamento dei dati alle tre del mattino.
Avere una conversazione preliminare su come gestire il carico di lavoro nell'applicazione può salvare una notevole mole di lavoro.

Cosa hanno bisogno di sapere gli sviluppatori dagli amministratori?
Il mio punto preferito in questo caso è il diagramma di rete. Troppo spesso gli sviluppatori vedono la rete come indicato in Figura 2, cioè non una vera è propria rete, ma semplicemente server Web, browser e Internet.
Figura 2 La rete vista dagli sviluppatori (fare clic sull'immagine per ingrandirla)
La realtà, si sa, è invece molto più complessa. Un diagramma come quello in Figura 3, se pur semplificato, è già più vicino alla realtà. Guardando Figura 3 sorgono subito delle domande. Ad esempio: "In che modo gli utenti di una rete privata virtuale (VPN) lavorano con l'applicazione?" oppure "In che modo l'autenticazione di un utente interno differisce da quella di un utente pubblico?" e così via.
Figura 3 La rete reale che gli sviluppatori devono capire (fare clic sull'immagine per ingrandirla)
Mostrare un diagramma di rete naturalmente non basta. È importante anche spiegare la rete nei dettagli, poiché è impossibile sapere esattamente quali elementi avranno impatto sull'applicazione, soltanto guardando un diagramma. È necessario spiegare a fondo l'effettivo processo di connessione degli utenti pubblici, VPN e interni. Discutere le varie regole di firewall che esistono, soprattutto in architetture di rete perimetrali più complesse, solleverà potenziali problemi dell'applicazione.
Sarebbe certamente meglio discutere di tutto ciò prima della distribuzione dell'applicazione o addirittura prima dell'inizio dello sviluppo. Ciò che è certo è che di tutto ciò a un certo punto bisogna parlare ed è fondamentale che tutti capiscano l'intero diagramma di rete.
I modelli di failover e ridondanza sono anch'essi competenza del team di rete. Senza alcun supporto software o almeno la conoscenza del funzionamento, questi modelli funzionano raramente come previsto. Un'altro argomento importante che merita una discussione dettagliata, riguarda i vari scenari di errore. Se è a disposizione un servizio di clustering sul database, questo avrà impatto sul codice utilizzato per accedere allo stesso. Le query, per esempio, possono essere eseguite nuovamente dopo un cambio di server? Se è disponibile un sito ridondante, come verranno replicati su questo sito? Come avviene il passaggio da un sito a un altro?
Ancora una volta, mettere a punto questi requisiti all'inizio del ciclo di sviluppo è consigliabile. Ma meglio tardi che mai. Tutti coloro che lavorano su un'applicazione devono conoscere questi aspetti. Non c'è niente di più frustrante che avere una soluzione di failover che non funziona quando ce n'è bisogno.
C'è infine un'altra risorsa di rete fondamentale che bisogna discutere insieme: i registri di produzione. Io consiglio sempre di mettere a disposizione i registri di produzione al team di sviluppo. La reazione tipica dei team di rete è "Richiedeteli e ve li inviamo". Non penso che questo sia un approccio adeguato. Infatti, è molto più efficace dare agli sviluppatori la possibilità di recuperare i registri stessi, generalmente da un backup.
I registri di produzione sono essenziali quando si presenta un problema. Sono spesso la migliore (e l'unica) fonte di veri dati empirici su ciò che è veramente successo. E sono ugualmente importanti in molte circostanze comuni. Quando gli sviluppatori hanno accesso costante ai registri di produzione, possono analizzarli per controllare come opera una nuova funzionalità. E questo è un modo molto potente per scoprire che la funzionalità non stia facendo qualcosa che non dovrebbe ed eventualmente correggere il problema. Quando tutti hanno accesso ai registri, si possono risolvere i problemi molto più rapidamente.

Ancora sulla scalabilità
La riunione tra gli sviluppatori e il personale di rete è fondamentalmente un occasione per discutere tutte le possibili questioni riguardanti la scalabilità di un'applicazione ASP.NET. L'ambiente effettivo nel quale opera l'applicazione ha impatto sul codice. Tutte le strategie sulla scalabilità influenzeranno il funzionamento all'interno dell'ambiente di esecuzione. Applicare una determinata strategia, come ad esempio separare le parti relative a SSL, potrebbe richiedere delle modifiche all'ambiente di rete e forse anche delle modifiche ai server stessi.
Perfino una modifica che riguarda apparentemente soltanto il codice, come ad esempio la memorizzazione nella cache, può avere impatto sull'ambiente. Questo perché se si memorizzano dati nella cache dell'applicazione ASP.NET, si diminuiscono le chiamate al database ma allo stesso tempo si aumenta l'utilizzo della memoria. Ne risulta che si potrebbe aumentare il numero di server ASP.NET a disposizione o il riciclo di thread di lavoro sul server, che avvierebbe eventi di controllo della rete.
Scalare un'applicazione ASP.NET ha un impatto sia sul team di rete che sugli sviluppatori e quindi è bene prendere decisioni condivise da tutti. Spesso da questa collaborazione verranno fuori soluzioni originali che i team non riuscirebbero a realizzare lavorando indipendentemente. Ad esempio, coloro che si occupano della rete potrebbero essere a conoscenza di soluzioni hardware disponibili nell'azienda in grado di aiutare gli sviluppatori a garantire le prestazioni e la scalabilità. Solo discutendo di tutti questi dettagli dell'applicazione e dell'ambiente verranno messe in luce queste possibilità.

Uno sforzo comune
Risorse per la scalabilità di applicazioni ASP.NET

  • Sviluppare applicazioni ASP.NET ad alte prestazioni
  • Procedure: Scalare applicazioni .NET
  • Procedure: Regolare e scalare le prestazioni delle applicazioni create su .NET Framework
  • Implementare un'architettura scalabile
  • Massimizzare le prestazioni di IIS
  • Strategie di scalabilità per applicazioni ASP.NET
Non bisogna necessariamente pensare a un problema di scalabilità come a una cosa negativa. Solitamente, infatti, questo è un segno positivo in quanto causato da un numero eccessivo di utenti collegati all'applicazione. Questo è indice che l'applicazione è apprezzata dagli utenti! Ma tuttavia bisogna che l'applicazione funzioni.
Altre volte il problema è causato da altri fattori: l'azienda può aver lanciato una promozione, qualcuno può aver scritto un post su un blog riguardante il sito o ancora un social network può avere indirizzato un altissimo numero di utenti verso il sito Web. Ci si trova all'improvviso a dovere difendere l'applicazione da questo picco di accessi. Come ci si può immaginare, è preferibile considerare questo scenario prima che esso si presenti nella realtà. Dimostrare come la collaborazione può aiutare un'organizzazione a superare questo genere di problemi è un modo straordinario per chiudere la riunione tra gli sviluppatori e gli amministratori di rete.
La prima domanda da porsi per fronteggiare il problema è "Come rilevare che il sito sta cedendo a causa del carico di accessi?" Troppo spesso la risposta è: "Ci arriva una segnalazione dal CTO (Chief technology officer)". Se il primo segno di un malfunzionamento al proprio sito Web è una chiamata dall'esterno, allora c'è veramente qualcosa che non va. Alcuni indici dovrebbero segnalare il problema prima che squilli il telefono. Di certo non aiuterà a evitare la telefonata, ma almeno ci sarà il tempo per prepararsi una risposta. Dire "Davvero?" al CTO non è propriamente una di quelle mosse che fa scattare la promozione.
Prossima domanda: "Chi viene chiamato prima?" Chi si occuperà della situazione? Generalmente un membro del team di rete riceve il primo avviso e quella persona potrebbe essere inesperta. È quindi necessario avere pronto un piano di riassegnazione del problema. Chi viene chiamato dopo? La vera sfida è avere una diagnosi rapida per scoprire la natura del problema. Se si tratta di un'interruzione di rete è una questione. Ma se è un problema di scalabilità, allora ci troviamo in tutt'altra situazione. Per quanto riguarda i problemi di scalabilità è opportuno coinvolgere un membro del team di sviluppo al più presto possibile.
Tutti coloro che sono coinvolti nella risoluzione del problema necessitano di informazioni chiare e quindi avere dei diritti di accesso efficaci è un fattore chiave. Lo scopo è raccogliere quante più informazioni possibili in modo da avere una diagnosi esaustiva e di conseguenza la possibile soluzione.
Spesso, se l'unica soluzione è quella di scrivere del codice, allora il problema sarà già sparito prima che gli sviluppatori avranno fatto il proprio dovere. È consigliabile prendere nota del problema per definire le priorità del codice e prevenire casi del genere nel futuro. Non ha molto senso tuttavia scrivere un blocco massiccio di codice e metterlo in produzione senza avere eseguito un test accurato. Regola numero uno da seguire quando si affronta un problema: mai peggiorare la situazione.
In casi di problemi di scalabilità, a volte la soluzione è semplicemente attendere. Si tratta di uno degli approcci possibili.
Allo stesso tempo, avere pianificato delle strategie per casi del genere aiuta ad avere molteplici piani d'azione. Avere uno sforzo congiunto da parte degli sviluppatori e del team di rete può risolvere problemi di scalabilità in brevissimo tempo. Forse anche in un tempo così breve da rendere quell'evento promozionale ancora più efficace.
In conclusione, il team di rete ha imparato che un'applicazione ASP.NET ben fatta e altamente scalabile rappresenta il risultato della collaborazione tra i creatori e gli utenti della stessa.
La collaborazione è inevitabile, dunque è meglio per iniziare prima con le riunioni tra i team per condividere informazioni. Lo scopo delle riunioni è creare intesa e accordo su tutti gli elementi dell'applicazione: cosa fa, come lo fa, da cosa dipende, come si comporta sotto sforzo e come fa fronte ai problemi che sorgeranno in un futuro.
Quando questa collaborazione è realmente efficace, il risultato è un'azienda agile che può affrontare rapidamente problemi e che è in grado di stabilire con chiarezza i punti chiave dell'applicazione che la renderanno stabile nel futuro.

Richard Campbell è un Microsoft Regional Director, MVP di ASP.NET e presentatore di .NET Rocks, un programma radiofonico trasmesso su Internet e rivolto agli sviluppatori .NET (visita dotnetrocks.com). Lavora da anni come consulente per le aziende e si occupa di prestazioni e scalabilità delle applicazioni ASP.NET. Richard è anche uno dei fondatori di Strangeloop Networks.


From the Editor In diretta da Tech•Ed
Joshua Hoffman

Ho sempre qualche difficoltà quando, una volta la mese, mi accingo a scrivere la nota del redattore. Decidersi per un argomento in generale non è difficile, perché ci sono sempre molte tematiche interessanti di cui discutere. Il fatto è che la nota del redattore dev'essere scritta almeno sei settimane prima che chiunque altro la legga (in parte per avere il tempo di stampare il giornale, ma principalmente perché i redattori abbiano il tempo di correggere tutti i miei errori). A differenza dei blog, in cui i commenti possono andare di pari passo con gli eventi, in questo caso è difficile trattare di "novità", perché nel momento in cui verranno lette, non saranno più tali.
Però eccomi qui, a Tech•Ed 2008, nell'"assolata" Orlando, e al momento si tratta davvero dell'avvenimento più importante per il mondo dell'IT. Quindi, anche se quando queste notizie verranno lette saranno un po' datate... ne parlo ugualmente.
Tech•Ed è un evento entusiasmante per numerose ragioni. Innanzitutto, è una delle poche occasioni dell'anno in cui abbiamo la possibilità di vedere così tanti dei nostri lettori (e anche autori) di persona. Abbiamo il piacere di comunicare tramite posta elettronica, messaggistica istantanea e chiamate per tutto l'anno, ma niente è paragonabile all'insieme di idee e conversazioni interessanti che l'incontro di così tante persone può generare.
Tech•Ed è anche un momento importante per iniziare a discutere delle novità dell'anno seguente. I dirigenti illustreranno la strategia di fondo, fornendo molte informazioni utili. Sentiremo parlare delle nuove direzioni in ambito di virtualizzazione, prossima generazione del Web, concetti rivoluzionari nella gestione dei sistemi e molto altro ancora.
Tuttavia, è per gli aspetti più dettagliati che sono qui. Mark Russinovich, un collega tecnico in Microsoft e un collaboratore di TechNet Magazine in qualità di redattore, parlerà della ridefinizione dei limiti di sicurezza. Steve Riley, un altro redattore, discuterà della scomparsa dei limiti della rete in generale: un concetto particolarmente interessante ed entusiasmante. Infine Mark Minasi, Romi Mahajan, Dharmesh Godha e io terremo un dibattito sul progressivo scivolamento dell'informatica verso il mercato di consumo.
Io discuterò inoltre di come diventare collaboratori di TechNet Magazine, una presentazione che ho avuto il piacere di proporre negli ultimi anni e che ha ispirato un numero notevole di autori alla loro prima esperienza. Nel momento in cui quanto scrivo verrà letto, le diapositive del mio discorso saranno state pubblicate sul nostro blog all'indirizzo blogs.technet.com/tnmag, quindi chiunque sia interessato può dare un'occhiata. Chi lo sa? Forse qualcuno dei lettori potrebbe partecipare alla conferenza Tech•Ed del prossimo anno in qualità di autore.
Oh, e non dimentichiamo le feste Tech•Ed. Ci piacciono anche le feste.
-Joshua Hoffman

Si ringraziano i seguenti esperti tecnici Microsoft: Sunil Agarwal, Eric Charran, Trina Gorman, Sanjeev Nair, Isaac Roybal, Jez Sadler, Roger Sprague, Stefan Stranger, Kevin Sullivan, Jim Truher, Alan von Weltin, Michael Walsh e Buck Woody.


Letters La parola ai lettori

Tipi di contenuto SharePoint
Sto cercando informazioni che forniscano una descrizione dettagliata sull'utilizzo dei tipi di contenuto in Microsoft® SharePoint®. Dove posso trovarle?
—E.A.

Un'ottima fonte per questo tipo di informazioni è il Blog del team dei prodotti e tecnologie Microsoft SharePoint (disponibile all'indirizzo blogs.msdn.com/sharepoint), inoltre Pav Cherny ha scritto un articolo sulla standardizzazione della gestione dati con tipi di contenuto personalizzati, disponibile all'indirizzo technet.microsoft.com/magazine/cc194408. All'indirizzo technet.microsoft.com/library/cc262729 è disponibile un white paper sulla gestione di metadati aziendali che potrebbe essere utile.
Un'altra risorsa che suggerisco di esplorare è il blog di Andrew May, all'indirizzo blogs.msdn.com/andrew_may. Andrew è un programmatore Microsoft responsabile della scrittura della documentazione per sviluppatori relativa alle funzionalità di gestione dei contenuti aziendali in Windows® SharePoint Services 3.0 e Microsoft Office SharePoint Server 2007. Sul blog descrive i tipi di contenuto e offre poster di illustrazioni tecniche su questo tema, che chiariscono gli aspetti più complessi della gestione di contenuti aziendali in un ambiente SharePoint.

Potenziamento della sicurezza
Ho molto apprezzato l'articolo "Il grande dibattito: la sicurezza tramite segretezza" (giugno 2008, technet.microsoft.com/magazine/cc510319). Tuttavia, mi ha deluso il fatto che il tutto si concentrasse semplicemente sulla ridenominazione dell'account amministratore. In merito al dibattito sul nome dell'amministratore, sono d'accordo con Roger Grimes e Aaron Margosis, in quanto credo anch'io che sia comunque meglio di niente e non crei molti problemi gestionali. Tuttavia, esistono molte altre soluzioni interessanti: le condivisioni di amministrazione, ad esempio, sono state citate, ma non esaminate approfonditamente dal gruppo e neppure il fatto che, quando sono bloccate, creano seri problemi a livello gestionale.
Inoltre, mi piacerebbe che il gruppo discutesse i pro e i contro dei tentativi di "ridurre la superficie di attacco". Questa opzione è una leggera variante della sicurezza tramite segretezza, in quanto la maggior parte dei dati eliminati si riferisce a operazioni che trasmettono informazioni relative a posizione o identità. Ad esempio, ho molti clienti che eliminano IPv6 in nome della sicurezza tramite segretezza. La rimozione dei servizi spesso viene eseguita come facevano i medici nel medioevo: si chiudono gli occhi, si procede all'operazione e si spera che il paziente sopravviva.
- Shelly B.

Siamo completamente d'accordo con te sull'approccio limitato alla ridenominazione dell'account amministratore. Le prime bozze contenevano molti altri esempi, ma se non fossero stati tagliati, l'articolo sarebbe stato di 20 pagine! Quindi, abbiamo scelto un esempio su cui concentrarci e la questione degli account amministratore sembra essere una delle più frequenti. In ogni caso, non preoccuparti: gli autori sono già stati sollecitati a scrivere più articoli su questa tematica.

Segretezza inadeguata
"Il grande dibattito: la sicurezza tramite segretezza" era un articolo interessante. Riflettendoci, ho capito due cose. Primo, credo che, finché il rendimento degli investimenti (ROI, Return on Investment) sulla segretezza è sufficientemente elevato, la segretezza sia un ottimo affare. Secondo, ho realizzato che gran parte della sicurezza IT ha sempre avuto una componente di segretezza.
Consideriamo le password, ad esempio. Con il tempo, le abbiamo rese sempre più segrete. Agli inizi, sulla maggior parte dei PC non era necessario disporre di password. Poi, quando la connettività dei computer è aumentata, è stato sufficiente impostare una semplice password. Con lo svilupparsi della connettività, è diventato importante avere password di almeno otto caratteri. Quando gli otto caratteri sono diventati insufficienti, si è dovuto ricorrere a caratteri di diverso tipo, poi a passphrase e così via. Sospetto che in futuro troveremo sempre meno adeguate le nostre vecchie protezioni segrete.
—Tom B.

Grazie per i commenti davvero significativi, Tom. Sarà interessante esaminare lo sviluppo di questa tendenza, in particolare a mano a mano che concetti di sicurezza quali l'autenticazione a più fattori (smart card più password, ad esempio) diventeranno sempre più comuni.

Poster TechNet Magazine
Vorrei procurarmi i poster Microsoft inclusi in alcuni numeri di TechNet Magazine per gli sviluppatori della mia azienda. Come posso acquistarli?
—Helen G.

I tre poster disponibili sono: Architettura dei componenti di Microsoft Exchange Server 2007, Componenti di Windows Server® 2008 Active Directory® e Componenti di Windows Server 2008. È possibile acquistarli chiamando il numero 800-444-4881 negli Stati Uniti e in Canada e il numero 785-838-7500 in tutti gli altri paesi.


Toolbox Nuovi prodotti per professionisti IT
Greg Steen

Monitoraggio dei server
PA Server Monitor Pro
poweradmin.com/servermonitor
Mantenere sotto controllo tutte le parti dell'infrastruttura è un'esigenza di primaria importanza. Sapere che qualcosa va storto prima che se ne accorgano gli utenti finali è fondamentale per la comunicazione e il controllo dei danni (senza contare che avere il capo col fiato sul collo non è molto divertente). Uno strumento utile per tenere sotto controllo l'infrastruttura dei server è PA Server Monitor Professional Edition di Power Admin LLC.
Iniziare a utilizzare PA Server Monitor è relativamente semplice, soprattutto grazie al processo di configurazione intelligente integrato nell'applicazione, in grado di rilevare i computer presenti nella LAN e configurare automaticamente un insieme di attività di monitoraggio per ciascuno di essi. Se non si è interessati al processo di rilevamento, è possibile importare un elenco di computer per i quali si desidera configurare i controlli di monitoraggio. Una volta configurato un computer, è possibile esportare la configurazione mediante la GUI per riutilizzarla come modello per altri computer o come backup in caso di reinstallazione.
PA Server Monitor offre 18 diversi monitoraggi che è possibile assegnare a ciascuno dei server. Questi includono verifiche standard, quali il monitoraggio di spazio su disco, errori del registro eventi, esecuzione di script remoti, modifiche di file e directory, utilizzo di CPU e memoria, risposta dell'ICMP (Internet Control Message Protocol, ping) e stato dei servizi Windows®.
Sono inoltre presenti molti altri monitoraggi particolarmente utili, incluso il controllo delle porte TCP, che consente di verificare lo stato delle porte di base, inviare comandi e controllarne la risposta in relazione a un valore predefinito. Il monitoraggio dei file di registro consente di controllare al loro interno la presenza di un determinato testo che è possibile definire come espressione regolare o testo semplice. Il monitoraggio delle quote di directory consente di accertarsi che gli utenti finali non superino i propri limiti. Quando eccedono le quote assegnate, gli utenti ricevono una notifica tramite messaggio di posta elettronica. È possibile monitorare l'esecuzione di script per qualsiasi attività personalizzata che si desidera effettuare. Infine, è possibile utilizzare il monitoraggio dell'età dei file per controllare la coda di posta e assicurarsi che non ne venga eseguito il backup.
Dopo aver definito un monitoraggio per un server, occorre specificare un'operazione da eseguire quando viene raggiunta la soglia di tale monitoraggio. PA Server Monitor offre 15 azioni integrate, inclusi posta elettronica, registro eventi, finestre di messaggi, file di registro, servizi di riavvio, SNPP (Simple Network Paging Protocol) e script personalizzati per operazioni definite dall'utente. Durante la definizione delle operazioni, è possibile specificare un'escalation di azioni supplementari da eseguire se il monitoraggio permane in uno stato di errore per una durata superiore alla quantità di tempo impostata. Ad esempio, è possibile impostare una prima azione che consista nel riavvio automatico del sito Web. Quindi, se dopo altri cinque minuti il controllo non ha esito positivo, si può impostare l'invio di un messaggio di posta elettronica al proprio dispositivo portatile per notificare lo stato del sito.
Nel tempo, è probabile che si desideri visualizzare statistiche sui monitoraggi configurati. PA Server Monitor dispone di funzionalità di report integrate che consentono di inviare le informazioni ai destinatari previsti. I report integrati comprendono un riepilogo dei server che mostra le statistiche e lo stato di un determinato server, un riepilogo generale che include una riga per ciascuno dei computer monitorati e una mappa grafica che mostra indicatori di stato per le installazioni in diverse aree geografiche. I report sono generati in HTML in modo che siano accessibili mediante un browser Web, funzionalità che può risultare utile nel centro operativo. Inoltre, è possibile generare report ad hoc con grafici di facile lettura o esportarli in un file CSV per utilizzi futuri. I report possono inoltre essere pianificati, consentendo di impostare l'applicazione per l'invio automatico a intervalli regolari di messaggi di posta elettronica relativi alle ultime statistiche sul server.
PA Server Monitor è senza agente. Uno dei vantaggi è la possibilità di rendere l'applicazione operativa in modo rapido, se il contesto del servizio per l'applicazione stessa dispone di autorità sufficiente per la connessione ai computer sulla rete per l'esecuzione tramite WMI (Windows Management Instrumentation) e altri servizi amministrativi remoti, come l'RPC (Remote Procedure Call). Uno degli svantaggi, tuttavia, è l'elevato livello di account necessario per la connessione ai computer remoti. Naturalmente, esistono altri tipi di monitoraggi di protocolli server, compresi HTTP e SMTP, che non richiedono autorizzazioni elevate.
Un altro potenziale svantaggio è che la connessione a computer tramite un'infrastruttura e una topologia di rete complesse e disperse può risultare difficile e dipende dall'affidabilità di dominio e rete. Per concludere, l'idoneità di questo approccio senza agente al proprio ambiente dipende dal layout dell'infrastruttura e dalle operazioni specifiche che si intende eseguire con la soluzione per il monitoraggio del server.
Prezzo: 99 dollari (acquisto diretto) per 20 monitoraggi attivi o 349 dollari (acquisto diretto) per 100 monitoraggi attivi.
Monitoraggio del server con PA Server Monitor Professional Edition (fare clic sull'immagine per ingrandirla)

Eliminazione di file duplicati
dupeGuru
hardcoded.net/dupeguru
Chi opera con utenti finali o gestisce spazio su disco condiviso da più utenti avrà indubbiamente notato che, col tempo, tale spazio tende a congestionarsi di materiale. La causa è che spesso uno o più utenti salvano lo stesso file in più posizioni. Al fine di consolidare e ripulire lo spazio utenti, può risultare indispensabile un programma di ricerca duplicati. Un'ottima soluzione è dupeGuru, prodotto da Hardcoded Software.
Questo strumento esegue la scansione della cartella o dell'unità di destinazione, esaminando nomi e contenuti dei file per individuare i duplicati. Tuttavia, dupeGuru va oltre il semplice confronto di stringhe, utilizzando un algoritmo per le corrispondenze fuzzy al fine di identificare duplicati che altrimenti potrebbero non essere rilevati. Una volta contrassegnati i duplicati, è possibile scegliere di inviarli al cestino, eliminarli in modo permanente, spostarli in un'altra cartella o aprirli con l'applicazione predefinita per una verifica finale. Per riesaminare i risultati in seguito, è possibile esportarli in XHTML.
Nelle preferenze, è possibile impostare i valori del filtro per il nome e il contenuto dei file durante la scansione; questo può incrementare il numero di duplicati rilevati, ma può anche aumentare la probabilità di falsi positivi. dupeGuru può inoltre contrassegnare tutti i duplicati il cui nome contiene un termine specifico. Questa funzione è particolarmente utile per rilevare tutti i file del tipo "Copia di" creati accidentalmente dagli utenti, nonché le cartelle vuote denominate "Nuova cartella" sparse nelle directory.
Sono disponibili versioni per Windows 2000 e successive e per Mac OS X. Se si intende ridurre i duplicati di file di musica o immagini, vale la pena di dare un'occhiata alle apposite versioni, denominate rispettivamente dupeGuru ME e dupeGuru PE.
Prezzo:19,95 dollari (acquisto diretto).
Eliminazione di file duplicati con dupeGuru (fare clic sull'immagine per ingrandirla)

Monitoraggio degli ambienti
pt360 Tool Suite PRO
packettrap.com
Disporre di un'unica interfaccia che consenta di visualizzare e gestire diversi strumenti di manutenzione e monitoraggio di rete può essere molto vantaggioso. Oltre a permettere di risparmiare tempo (e risorse desktop), una suite integrata può facilitare la condivisione di dati tra diversi strumenti di controllo, consentendo al contempo di esaminare più monitoraggi e fornendo una panoramica più completa dello stato dell'infrastruttura.
pt360 Tool Suite PRO di PacketTrap Networks racchiude tutte le funzionalità citate. L'applicazione offre un'interfaccia utente integrata per gli strumenti PacketTrap Networks, con l'aggiunta di funzionalità di produzione di report consolidati e di centralizzazione. L'utente può creare e organizzare la visualizzazione all'interno di un pannello personalizzato, che consente un accesso immediato agli strumenti più utilizzati e a informazioni sullo stato dell'infrastruttura. Il pannello pt360 può inoltre passare alla modalità a schermo intero. Questa funzione è particolarmente utile nel centro operativo, in quanto consente ai membri del team di visualizzare rapidamente lo stato delle risorse di diverse reti e server. L'applicazione supporta più pannelli, quindi è possibile creare diverse visualizzazioni nell'ambiente in uso in base alle proprie esigenze.
Per configurare un pannello, è sufficiente selezionare i gadget desiderati da un elenco a discesa e fare clic su ciascuno di essi per definirne le impostazioni. I gadget sono raggruppati in cinque categorie (Application, Networking, Devices, Availability e Other) e si basano su SNMP (Simple Network Management Protocol) e WMI per il monitoraggio di server, applicazioni e dispositivi di rete. I gadget relativi all'applicazione consentono di accedere ad Active Directory®, Microsoft® Exchange Server e SQL Server®, oltre a fornire uno strumento browser. I gadget relativi alla rete offrono informazioni sulle interfacce dei dispositivi e forniscono le 10 visualizzazioni più frequenti su perdita di pacchetti media, latenza più elevata e utilizzo interfacce per client. I gadget relativi ai dispositivi forniscono indicatori di prestazioni sull'utilizzo di CPU e memoria, spazio disponibile su disco, elenchi di volumi, uso dell'interfaccia di rete e molte altre informazioni utili per tenere sotto controllo le prestazioni dei propri server in tempo reale mediante le relative query WMI configurabili. I monitoraggi sulla disponibilità consentono di visualizzare i tempi di attività dei computer sotto forma di grafici, indicatori, testo o elenchi. Infine, in "Other" è presente un grande orologio digitale.
Oltre al pannello, la suite pt360 offre strumenti di rete. Ad esempio, è presente un configuratore Cisco. Questo strumento consente di archiviare, modificare, caricare, scaricare e paragonare file di configurazione dall'apparecchiatura Cisco. Inoltre, sono disponibili tre diversi strumenti ping: il primo fornisce una visualizzazione tabulare ordinabile, il secondo fornisce una visualizzazione grafica e il terzo consente di eseguire una rapida scansione ping di un gruppo di indirizzi IP. Altri tipi di strumenti di scansione disponibili includono uno scanner di indirizzi MAC, uno strumento di scansione porte, uno scanner SNMP e uno strumento di scansione WMI.
La suite può inoltre svolgere la funzione di server Syslog e inviare, ricevere, registrare e visualizzare messaggi Syslog provenienti e indirizzati a qualsiasi dispositivo sulla rete che supporti tale funzione. È possibile applicare filtri alla visualizzazione, che consentono di isolare rapidamente messaggi di interesse, accelerando il processo di risoluzione dei problemi.
La suite funge da server TFTP (Trivial File Transfer Protocol), consentendo di spostare rapidamente file da e verso i dispositivi presenti in rete. Altri strumenti includono funzionalità quali routing di traccia, Whois e riattivazione LAN. Naturalmente, trattandosi di una soluzione di gestione centralizzata con connessioni agli host tramite WMI e SNMP, la modalità con cui la suite memorizza le credenziali per la connessione è fondamentale. Per fortuna, la suite utilizza un archivio di credenziali con crittografia AES (Advanced Encryption Standard) a 256 bit, per il quale è possibile aggiungere, aggiornare o eliminare informazioni relative al monitoraggio dell'infrastruttura.
Prezzo: 999 dollari (acquisto diretto) per licenza.
Figura 36 Monitoraggio dei sistemi con pt360 Tool Suite PRO

Gestione dell'utilizzo del disco
TreeSize Professional
jam-software.com/treesize/index.shtml
"Cos'è che occupa tutto quello spazio su disco sul server?" È una lamentela che suona familiare? Un utente che abbia appena ricevuto dalla propria applicazione di monitoraggio un messaggio di posta elettronica che notifica il raggiungimento della soglia minima di spazio su disco si chiederà quale sia la procedura migliore per ripulire la macchina e come sia possibile identificare rapidamente il "colpevole" da eliminare con "MAIUSC+CANC" (si tratta della combinazione dei tasti di scelta rapida per saltare il cestino). Uno strumento che può risultare utile a questo scopo è TreeSize Professional di JAM Software.
L'applicazione viene eseguita su Windows 2000 e successivi per entrambi le versioni a 32 e 64 bit e fornisce una panoramica dettagliata dei file che occupano spazio sulle unità. È sufficiente selezionare l'unità da interrogare e l'applicazione eseguirà automaticamente la scansione della struttura di cartelle. Una volta terminata l'operazione, l'utente potrà accedere a sette diverse visualizzazioni dell'unità. La prima è una visualizzazione grafica, che a sua volta consente di esaminare tre tipi di grafico: a torta, a barre e a scatole di dimensioni relative. Ciascuno di questi grafici consente di scendere in dettaglio nelle diverse cartelle, in modo da poter identificare rapidamente gli elementi che occupano più spazio. Inoltre, è possibile personalizzare colore e stile dei grafici.
Nella visualizzazione dettagliata, viene mostrata una tabella ordinabile di file, all'interno della quale è possibile selezionare diverse colonne da visualizzare. Le scelte più significative tra gli utenti includono l'autore dei file Microsoft Office, la dimensione media di file in una cartella, la percentuale di directory principale occupata da tale file o cartella e i collegamenti fissi.
La visualizzazione relativa alle estensioni indica quali tipi di file occupano la maggior quantità di spazio in ciascuna directory man mano che si scende più in dettaglio nelle cartelle. La visualizzazione relativa agli utenti indica la quantità di spazio occupata dai file di account di sistema o utenti, che è essenziale per consentire di individuare gli utenti problematici. La visualizzazione relativa all'età dei file mostra, sotto forma di grafico, le percentuali di file che sono stati modificati, creati o aperti nell'ultimo giorno, mese, anno, a seconda delle esigenze dell'utente, consentendo di identificare i file meno recenti, che è possibile archiviare o eliminare in sicurezza. Inoltre, è disponibile una visualizzazione che consente di identificare i 100 file di dimensioni maggiori presenti sull'unità. Infine, è presente la visualizzazione di tipo cronologico, che indica i modelli di utilizzo dell'unità nel tempo.
Ciascuna delle sette visualizzazioni può essere stampata, salvata e copiata negli Appunti per utilizzo futuro. Inoltre, TreeSize accelera le comuni attività di ripulitura mediante la barra degli strumenti, consentendo di isolare rapidamente i file di dimensioni maggiori, meno recenti, temporanei, di cache Internet e duplicati grazie alla funzione di ricerca file. TreeSize Professional può anche eseguire scansioni sulla rete mediante condivisioni UNC, ma le prestazioni sono notevolmente penalizzate a causa dell'overhead di rete.
L'applicazione supporta inoltre la modalità a riga di comando, particolarmente utile per pianificazioni e attività eseguite durante la notte. L'utente può anche creare una scansione di operazioni pianificata, configurando le impostazioni affinché sia eseguita la scansione di un percorso e venga generata una serie di report secondo una pianificazione standard. Questo è utile per monitorare ogni sera lo spazio utenti condiviso e tenere sotto controllo l'utilizzo dello spazio su disco.
Per chiunque si stia chiedendo com'è possibile che tutti i terabyte di spazio utenti siano stati completamente occupati, TreeSize rappresenta una valida soluzione per scoprire come lo spazio su disco è usato e per iniziare a gestirlo con maggiore efficienza.
Prezzo: 49,95 dollari (acquisto diretto) per licenza.
Gestione dell'utilizzo del disco con TreeSize Professional (fare clic sull'immagine per ingrandirla)

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


SQL Q&A Partizionamento, verifiche di coerenza e altro ancora
Paul S. Randal

Ho collegato accidentalmente un database di produzione a un server SQL Server® 2005 e ora sto tentando di collegarlo al server corretto, su cui è installato SQL Server 2000. Ho provato semplicemente a scollegare il database e a ricollegarlo al server SQL Server 2000 e ho tentato di fare lo stesso con backup e ripristino, ma nessuna delle due procedure ha funzionato. Perché non ottengo il risultato desiderato sul server SQL Server 2000? Questa è l'unica copia del database di cui dispongo.
R Il primo punto da sottolineare è l'importanza di disporre di backup. In genere, gli amministratori di database ritengono che i backup siano necessari solo per recuperare i dati che hanno subito danneggiamenti o in altri casi di emergenza. Tuttavia, può capitare di imbattersi in problemi meno ovvi, ad esempio qualcosa che va storto durante un aggiornamento, sebbene in questo caso si tratti di un aggiornamento accidentale. Resta comunque il fatto che è opportuno disporre sempre di un backup di database completo recente nel caso in cui si verifichino imprevisti.
L'aggiornamento, che sia intenzionale o accidentale, è un'operazione unidirezionale e annullarne gli effetti è estremamente complesso. Quando si esegue l'aggiornamento da una versione di SQL Server a un'altra, il database è sottoposto a una serie di fasi di aggiornamento. In genere, ciascuna fase comprende modifiche fisiche al database e ne incrementa il numero di versione.
Ad esempio, una delle principali modifiche eseguite durante l'aggiornamento di un database da SQL Server 2000 a SQL Server 2005 è la variazione della struttura dei cataloghi di sistema del database stesso (spesso denominati tabelle di sistema o metadati del database) che contengono diversi metadati relativi a tabelle, indici, colonne, allocazioni e altri dettagli inerenti alla struttura fisica e relazionale del database.
Con il procedere delle fasi di aggiornamento, il numero di versione del database viene incrementato. Ad esempio, i database SQL Server 7.0 hanno il numero di versione 515, i database SQL Server 2000 il numero di versione 539 e i database SQL Server 2005 il numero di versione 611 (o 612 se è attiva la funzionalità vardecimal). Ciò consente a SQL Server di riconoscere l'ultima fase di aggiornamento eseguita sul database.
Le versioni precedenti di SQL Server non sono in grado di leggere i database aggiornati a versioni più recenti (ad esempio, SQL Server 2000 non può leggere un database aggiornato a SQL Server 2005). Questo perché le versioni precedenti non dispongono del codice necessario per interpretare le strutture e il layout aggiornati del database. Ed è proprio questo il problema del caso in questione: il database è stato aggiornato a SQL Server 2005 e non è in grado di ricollegarsi a SQL Server 2000.
In mancanza di un backup di database completo, l'unica possibilità è esportare tutti i dati dal database aggiornato e trasferirli manualmente a un nuovo database SQL Server 2000. Se non sono state utilizzate nuove funzionalità in SQL Server 2005, è possibile eseguire uno script della struttura del database, creare un database in SQL Server 2000, quindi esportare/importare i dati.
Per eseguire lo script del database in SQL Server 2005, è possibile utilizzare la funzione Esplora oggetti in SQL Server Management Studio (fare clic con il pulsante destro del mouse sul database, selezionare Attività, quindi l'opzione Genera script). La procedura guidata è molto semplice e genera uno script per la creazione di tutti gli oggetti, gli indici, i vincoli, i trigger e così via.
D Di recente abbiamo riprogettato il nostro schema per l'utilizzo del partizionamento tabelle sulla tabella principale, poiché ci è stato detto che potrebbe migliorare le prestazioni. Il database è memorizzato su un'unica unità da 120 GB e la tabella è contenuta in un singolo filegroup. Non vengono utilizzate finestre scorrevoli, semplicemente vengono aggiunte nuove partizioni ogni settimana e tutti i dati devono essere disponibili in linea. La maggior parte delle query elaborano i dati di una sola settimana e alcune operano nell'arco dell'ultimo anno. L'operazione sembra più semplice se eseguita in un unico filegroup. Queste informazioni sono corrette o c'è altro da sapere?
R Sebbene possa sembrare più semplice utilizzare un unico filegroup, in questo modo è improbabile che il partizionamento risulti vantaggioso. Il partizionamento è per lo più utilizzato per garantire una manutenzione più efficiente del database e per aumentare la disponibilità di dati in situazioni di emergenza, oltre a consentire di creare uno schema che migliori le prestazioni.
L'esempio archetipo del partizionamento è una tabella vendite con 12 partizioni, ognuna delle quali rappresenta un mese dei dati delle vendite dell'ultimo anno. Alla fine del mese, la partizione meno recente viene estromessa (e archiviata o eliminata) e viene immessa una nuova partizione. Si tratta dello scenario a finestra scorrevole citato. Per la partizione del mese corrente è consentito l'accesso in lettura/scrittura, mentre quelle dei mesi precedenti sono in sola lettura. Ciascuna partizione è memorizzata in un filegroup separato. Questo schema offre tutti i vantaggi del partizionamento, ma non è la soluzione ottimale in tutte le circostanze.
Mia moglie, Kimberly, ha elaborato una modifica dello schema descritto in precedenza che consente un'indicizzazione più efficiente. Innanzitutto, suddividere la tabella vendite in due tabelle, una per l'unica partizione in lettura/scrittura e l'altra per le 11 partizioni in sola lettura, con una vista partizionata su entrambe le tabelle.
Questo consente alla tabella in lettura/scrittura di avere un numero ridotto di indici e a quella in sola lettura di avere più indici per supportare le query di report. Le operazioni DML (Data Manipulation Language) sui dati in lettura/scrittura risultano di conseguenza molto più efficienti, in quanto non devono mantenere un numero elevato di indici non cluster.
Inoltre, le query sui dati in lettura/scrittura non devono elaborare anche i dati in sola lettura. L'eliminazione di partizioni nei piani di query non è ottimale in SQL Server 2005, in particolare in presenza di predicati complessi, ma è stata molto migliorata in SQL Server 2008. Per ulteriori informazioni al riguardo, consultare il post del blog di Kimberly all'indirizzo sqlskills.com/blogs/kimberly/default,month,2007-10.aspx#a71c70243-3d57-4940-9af7-a802b73f2f93.
Per dimostrare quanto illustrato, spiegherò alcune delle funzionalità abilitate dal partizionamento su più filegroup.
Disponibilità parziale del database Si tratta della capacità di un database di restare in linea e accessibile durante una situazione di ripristino di emergenza, a condizione che il filegroup principale sia in linea. Se si dispone di un unico filegroup, durante il ripristino l'intero database non sarà disponibile. Se i dati sono suddivisi tra più filegroup, invece, durante il ripristino solo quelli danneggiati non saranno in linea e l'applicazione potrà continuare a operare.
Ripristino a fasi Questo schema è simile alla disponibilità parziale del database. Con un unico filegroup, l'unità di ripristino può essere una sola pagina o l'intero database. Con più filegroup, è possibile ripristinarne uno solo, consentendo in tal modo una disponibilità parziale del database.
Manutenzione partizionata del database Con uno degli schemi di partizione indicati in precedenza, è possibile rimuovere la frammentazione degli indici per ogni singola partizione, anche se si trovano tutte in un unico filegroup. Tuttavia, con un unico filegroup, viene meno la possibilità di eseguire verifiche di coerenza per filegroup. Ciò può ridurre notevolmente la quantità di dati che le verifiche di coerenza del database (DBCC, Database Consistency Checking) devono elaborare (e, al contempo, la quantità di risorse di I/O e CPU utilizzate).
Detto in parole semplici, è possibile utilizzare più partizioni nello stesso filegroup, ma una corrispondenza 1-1 tra partizioni e filegroup presenta numerosi vantaggi.
D Di recente si è verificato un grave problema in uno dei nostri server di database di fascia alta: una scheda di memoria malfunzionante causava danneggiamenti. Ce ne siamo resi conto quando nell'applicazione hanno iniziato a comparire dati casuali. Abbiamo eseguito DBCC CHECKDB, rilevando ogni genere di danneggiamento. Purtroppo, questi interessavano anche i backup, dai quali abbiamo dovuto eliminare i dati danneggiati manualmente.
In breve, abbiamo sostituito l'hardware che causava problemi e attivato i checksum di pagina. Vorremmo eseguire regolarmente verifiche di coerenza, ma non disponiamo di una finestra di manutenzione estesa e per eseguire il controllo del nostro database da 2,4 TB è necessario molto tempo. Cosa possiamo fare?
R Le domande relative alle modalità di esecuzione di verifiche di coerenza e altre operazioni di manutenzione sui VLDB (Very Large Database) sono sempre più frequenti. Molti amministratori di database rinunciano dopo aver scoperto che per l'esecuzione di DBCC CHECKDB è necessario più tempo di quanto consentito dalla finestra di manutenzione (in alcuni casi, il database è utilizzato 24 ore su 24, 7 giorni su 7 e non si trovano momenti per rinunciare all'overhead di I/O e CPU richiesto da DBCC CHECKDB per un lungo periodo di tempo).
A parte la possibilità di rinunciare e non eseguire affatto verifiche della coerenza (soluzione che non suggerisco), è possibile utilizzare quattro metodi. Ho personalmente aiutato alcuni clienti a utilizzare tutti e quattro i metodi.
Utilizzo dell'opzione WITH PHYSICAL_ONLY di DBCC CHECKDB Il comando DBCC CHECKDB esegue una grande quantità di verifiche di coerenza logica, con una notevole occupazione della capacità della CPU (trattandosi, fondamentalmente, di un'operazione associata alla CPU). L'utilizzo dell'opzione WITH PHYSICAL_ONLY consente di eseguire solo le verifiche della coerenza dei bitmap di allocazione DBCC CHECKALLOC, che sono molto rapide, e di leggere e controllare tutte le pagine allocate nel database, causando la verifica di eventuali checksum di pagina presenti. Questo trasforma DBCC CHECKDB in un'operazione associata all'I/O, con tempi di esecuzione molto più brevi (infatti, a volte è assai più rapida di un DBCC CHECKDB completo, con un notevole risparmio di tempo).
Suddivisione del carico di lavoro delle verifiche di coerenza Questo metodo comporta la suddivisione delle tabelle nel database in gruppi di uguali dimensioni (l'approccio più semplice è utilizzare i numeri di pagine) e il successivo utilizzo dei comandi DBCC CHECKTABLE per eseguire ogni sera verifiche di coerenza su tutte le tabelle di un singolo gruppo. Così, ad esempio, creando sette gruppi e controllandone uno al giorno, con un DBCC CHECKALLOC e un DBCC CHECKCATALOG una volta la settimana, è possibile eguagliare un DBCC CHECKDB, sebbene ripartito nell'arco di una settimana.
Utilizzo del partizionamento tabelle con più filegroup Le tabelle di maggiori dimensioni nel VLDB possono essere suddivise in più filegroup. Un esempio di schema di verifica della coerenza potrebbe essere eseguire un DBCC CHECKFILEGROUP giornaliero sul filegroup che contiene la partizione in lettura/scrittura e un DBCC CHECKFILEGROUP settimanale sui filegroup che contengono partizioni in sola lettura. La logica è che per i dati in sola lettura viene eseguito un backup completo e non sono utilizzati nell'elaborazione giornaliera. Di conseguenza, non devono essere sottoposti spesso a verifiche di coerenza, in quanto i danneggiamenti al loro interno non sono critici.
Ripartizione del carico di lavoro delle verifiche di coerenza su un altro server Questa opzione comporta il ripristino dei backup regolari del database completi su un altro server e l'esecuzione di DBCC CHECKDB su tale server. Ovviamente, questo consente di scaricare completamente il carico di lavoro delle verifiche di coerenza dal server di produzione. Tuttavia, lo svantaggio è che, qualora sia rilevato un danneggiamento, è necessario eseguire una verifica di coerenza sul server di produzione, sebbene ciò si verifichi di rado.
Come è evidente, gli amministratori di sistema hanno a disposizione numerose opzioni per eseguire verifiche della coerenza su un VLDB, consentendo di ridurre il carico necessario per un DBCC CHECKDB completo. Come detto in precedenza, ho personalmente aiutato alcuni clienti a utilizzare tutti e quattro gli approcci citati. Quindi ritengo che queste opzioni saranno adatte anche al caso in questione.
Suggerimento: utilizzo di trigger per l'implementazione della logica sul lato server
In alcuni scenari è necessario implementare la logica sul lato server mediante trigger. Tuttavia, esistono alcuni inconvenienti che è bene conoscere. Di seguito sono indicati alcuni elementi importanti da tenere in considerazione.
  • I trigger sono avviati da istruzioni, non per riga. Detto ciò, assicurarsi di inserire logica aggiuntiva all'interno della logica trigger per gestire il caso in cui più righe o nessuna riga siano interessate dall'istruzione (i trigger sono avviati in base all'istruzione, anche se nessuna riga è interessata). I dati interessati sono contenuti in tabelle virtuali per le istruzioni DML (Data Manipulation Language). Tali tabelle possono essere unite, consentendo di elaborare i dati.
  • L'esecuzione dei trigger all'interno della transazione è sincrona. Ricordare questo punto ogni volta che si desidera richiamare un'applicazione esterna o accedere a una risorsa esterna e non si ha la certezza che la velocità di risposta sarà breve o ragionevole. Ad esempio, se si attiva un'istruzione di aggiornamento per una tabella e in quell'operazione viene attivato un trigger, la transazione (la parte implicita dell'istruzione di aggiornamento) non terminerà finché tutta la logica del trigger non sarà completa. Se l'applicazione o il processo esterni restituiscono un codice di errore, SQL Server potrebbe annullare la transazione ed eseguirne il rollback (a seconda della gestione errori implementata e del codice di errore). Pertanto, se si devono eseguire operazioni esterne all'interno di un trigger e questo non è fondamentale per la transazione (o non deve essere eseguito entro lo stesso ambito), occorre scalarlo in un altro processo, prelevando i dati in modo asincrono. SQL Server 2005 ha introdotto SQL Server Service Broker, che può eseguire tali operazioni in modo asincrono.
  • Gli errori causati da un'istruzione all'interno di un trigger sono estremamente difficili da individuare. Se la transazione comprende più tabelle, in caso di errore, assicurarsi di ispezionare i trigger e implementare una gestione errori adeguata. Se si modifica lo schema all'interno del proprio database, accertarsi di tenere traccia della logica dei trigger. In caso contrario, un semplice trigger può avere un forte impatto su prestazioni e stabilità globali. È possibile verificare la maggior parte delle conseguenze relative a modifiche dello schema mediante Visual Studio® for Database Professionals, che esegue verifiche di schema automatiche mentre si modifica il progetto ed effettua analisi di codice statico per controllare la presenza di incongruenze nei tipi di dati.
- Jens K. Suessmeyer, Database Consultant presso Microsoft

Paul S. Randal è Managing Director di SQLskills.com e MVP per SQL Server. Ha lavorato nel team di SQL Server Storage Engine in Microsoft dal 1999 al 2007, ha scritto il comando DBCC CHECKDB/repair per SQL Server 2005 ed è stato responsabile di Core Storage Engine durante lo sviluppo di SQL Server 2008. Paul, che vanta una notevole esperienza nell'ambito del ripristino di emergenza, della disponibilità elevata e della gestione dei database, partecipa regolarmente a conferenze in qualità di relatore. Il suo blog è disponibile all'indirizzo SQLskills.com/blogs/paul.


Utility Spotlight Utilità Windows Installer CleanUp
Lance Whitney

Quando si tenta di disinstallare o aggiornare un'applicazione su uno dei computer nel proprio ambiente, il comando inserito non viene eseguito ma viene visualizzato un messaggio di errore che indica l'impossibilità di effettuare tali operazioni. Chiunque si riconosca in questa situazione, indubbiamente si sarà domandato quale sia la causa di questa anomalia.
I software installati utilizzando la tecnologia MSI (Microsoft® Windows® Installer) scrivono determinati file e impostazioni del Registro di sistema. Se alcuni di questi file o impostazioni sono danneggiati o mancanti, risulta impossibile rimuovere, aggiornare o persino reinstallare il programma. In questi casi, la soluzione è rimuovere tutte le informazioni di Windows Installer, al fine di poter reinstallare il programma senza problemi. A tale scopo, Microsoft offre l'utilità gratuita Windows Installer CleanUp.
Questa utilità elimina tutti i file e le impostazioni del Registro di sistema associati alla configurazione di Windows Installer di un programma. È importante sottolineare che lo strumento non rimuove i file di installazione o le impostazioni del Registro di sistema reali del programma, né sostituisce il comando Installazione applicazioni.
Piuttosto, è consigliabile ricorrere a quest'utilità quando non è possibile disinstallare o aggiornare un'applicazione mediante Installazione applicazioni o altri metodi. Eliminando le informazioni di Windows Installer, dovrebbe essere possibile reinstallare l'applicazione. Quindi, si potrà lasciare il programma installato invariato, aggiornarlo o rimuoverlo.
Nell'utilità Windows Installer CleanUp viene visualizzato un elenco di tutte le applicazioni basate su Windows Installer presenti sul computer (fare clic sull'immagine per ingrandirla)
Alcuni dei lettori avranno famigliarità con il programma Microsoft da riga di comando Msizap, che consente di rimuovere i dati di Windows Installer di un programma. Bene, quel programma è ancora utilizzato: l'utilità Windows Installer CleanUp è semplicemente un front-end di facile utilizzo di Msizap, che elimina la necessità di utilizzare complesse righe di comando.
Dopo aver installato l'utilità, in Programmi sarà presente una sottodirectory denominata Windows Installer CleanUp. Questa contiene tre file: msicuu.exe, msizap.exe e readme.txt. Il file msicuu.exe consente di visualizzare un elenco di tutte le applicazioni basate su Windows Installer presenti sul computer e di selezionarle, deselezionarle e rimuoverle. Il programma trasmette quindi le selezioni dell'utente al comando msizap.exe, che rimuove le informazioni di Windows Installer per le applicazioni desiderate.
Per eseguire Windows Installer CleanUp, selezionare il menu Start | Tutti i programmi e la relativa cartella, quindi fare clic sul collegamento a Windows Installer CleanUp. Sarà visualizzato un elenco di tutte le applicazioni basate su Windows Installer presenti sul computer (come illustrato nello screenshot). Selezionare l'applicazione che ha creato problemi e fare clic sul pulsante Rimuovi. L'applicazione sarà eliminata dal database di Windows Installer, consentendo la reinstallazione.
Dopo aver eseguito lo strumento di pulitura, l'applicazione non sarà più visualizzata in Installazione applicazioni. Quindi, se si desidera rimuoverla del tutto, occorrerà prima reinstallarla. Windows Installer CleanUp opera solo con software che utilizzano la tecnologia Windows Installer. In genere, si tratta di installazioni nel formato di file MSI.
Infine, per eseguire Windows Installer CleanUp è necessario disporre dei diritti di amministratore. Lo strumento è compatibile con tutte le versioni a 32 e a 64 bit di Windows. Per ulteriori informazioni sull'utilità e per scaricare il software, visitare il sito support.microsoft.com/kb/290301.

Lance Whitney è un consulente IT, docente e technical writer. Ha dedicato molto tempo alle modifiche di workstation e server di Windows. In origine era un giornalista, ma circa 15 anni fa ha fatto un salto nel buio lanciandosi nel mondo dell'IT.


Inside SharePoint Risoluzione dei problemi di integrazione della messaggistica
Pav Cherny

Download codice disponibile in: SharePoint2008_08.exe (416 KB)
Indice
Approccio generale alla risoluzione dei problemi
Architettura di messaggistica SharePoint
Come ottenere informazioni diagnostiche
Trasferimento di messaggi in uscita
Trasferimento di messaggi in entrata
Gestione directory
Conclusioni
In un ambiente SharePoint ben progettato, gli information worker non devono modificare le proprie abitudini a livello di comunicazione o le routine di lavoro per collaborare. Anziché controllare manualmente i siti di collaborazione a intervalli regolari, con SharePoint è possibile ricevere documenti e altri tipi di informazioni, quali avvisi e promemoria, direttamente nelle cassette postali.
Gli utenti, inoltre, possono prendere parte a flussi di lavoro rispondendo a tali messaggi o inviando nuovi elementi, sotto forma di messaggi di posta elettronica, a elenchi e raccolte di documenti.
Tuttavia, l'integrazione di SharePoint® in un ambiente di messaggistica protetto crea alcune difficoltà e dà l'opportunità ai componenti diversi da SharePoint di avere un impatto sulla collaborazione basata su tale software. La sfida consiste nell'isolare ed eliminare in modo efficiente le cause principali dei problemi nell'ambiente integrato, ovunque si presentino.
Nel presente articolo, illustrerò l'integrazione della messaggistica SharePoint basata su una strategia di risoluzione dei problemi comprovata che fornisca rapidamente risultati. Il principio è individuare con efficienza l'area problematica, per scendere quindi nel dettaglio con procedure di risoluzione dei problemi specifiche e mirate.
In un'organizzazione di grandi dimensioni, la presenza di più fasi potrebbe richiedere, dopo una prima analisi generale, la consulenza di altri specialisti, in particolare se il problema riguarda componenti diversi da SharePoint. Nelle organizzazioni di piccole e medie dimensioni, invece, non è insolito che un unico amministratore IT debba risolvere i problemi di tutti i sistemi utilizzati. Ciò rende ancora più necessario l'utilizzo di approcci strutturati.
Al fine di fornire esempi pratici nell'articolo, sarà utilizzato un ambiente di test con Active Directory®, Exchange Server 2007 e WSS 3.0. Le istruzioni dettagliate per la creazione di questo ambiente, nonché gli strumenti per la risoluzione dei problemi trattati nell'articolo, sono inclusi nel materiale di accompagnamento disponibile nella sezione di scaricamento del codice del sito Web TechNet Magazine.

Approccio generale alla risoluzione dei problemi
La risoluzione dei problemi legati all'integrazione di messaggistica SharePoint richiede un approccio estremamente strutturato, forse più che in altri scenari di interoperabilità. Diversi fattori rendono complessa tale operazione.
È ovviamente necessario utilizzare tecnologie complesse e, mentre si è occupati a gestire problemi legati al trasferimento di messaggi, conversioni del formato dei messaggi, aspetti relativi alla sicurezza e problemi inerenti alla gestione di directory, alcuni messaggi di errore di SharePoint possono risultare poco chiari. Nei newsgroup in Internet sono presenti molti thread di discussione irrisolti e suggerimenti che possono portare sulla cattiva strada, come eseguire tutte le applicazioni Web sotto l'identità di pool di applicazioni per l'Amministrazione centrale di SharePoint al fine di rendere l'integrazione della messaggistica operativa.
Ma ci sono anche aspetti positivi. SharePoint è molto flessibile. Infatti, se si sa dove cercare, può fornire informazioni dettagliate per la risoluzione dei problemi. Con alcuni script di base, è possibile migliorare notevolmente l'efficienza nella risoluzione dei problemi.
Il primo obiettivo di questa operazione consiste nel capire il problema da affrontare, identificando l'area in cui si trova e i componenti interessati. È inoltre possibile tentare di riprodurre il problema in configurazioni di sistema differenti ed esaminare i file di registri basati su testo e dei registri eventi di Windows®. Tuttavia, ciò può risultare difficile, in quanto alcuni problemi si verificano solo sporadicamente. In ogni caso, più accurata è la riproduzione di un problema, più rapida sarà l'identificazione e l'eliminazione della relativa causa. Un altro obiettivo importante, spesso trascurato, consiste nel documentare tutte le modifiche e le correzioni di configurazione e nell'assicurarsi che siano applicate a tutti i sistemi rilevanti nell'ambiente, ad esempio su tutti i server front-end di una Web farm.

Architettura di messaggistica SharePoint
Quando si deve affrontare un problema legato all'integrazione di messaggistica, prima di tentare di risolverlo, è consigliabile prepararsi una tazza di tè o caffè ed esaminare l'architettura dell'integrazione di messaggistica SharePoint. In caso contrario, si rischierebbe di correggere il problema o il componente sbagliato. Ad esempio, un errore di accesso negato che impedisca la creazione di un oggetto di contatto in Active Directory non indica esclusivamente che è necessario correggere le autorizzazioni di accesso al suo interno, come si vedrà in seguito.
In ogni caso, è fondamentale comprendere il ruolo di ciascun componente coinvolto nell'integrazione di messaggistica e la modalità con cui i singoli componenti interagiscono tra loro. Nella Figura 1 sono illustrati i componenti rilevanti in uno scenario di connettività SharePoint-Exchange, argomento trattato approfonditamente nelle sezioni seguenti.
Figura 1 Architettura dell'integrazione di messaggistica SharePoint (fare clic sull'immagine per ingrandirla)

Come ottenere informazioni diagnostiche
Uno degli strumenti più importanti per la risoluzione dei problemi è la disponibilità di informazioni diagnostiche affidabili. Lo strumento per eccellenza è il registro eventi di Windows. Tra le altre funzioni, è possibile controllare il livello di dettaglio con cui SharePoint scrive nel registro eventi di Windows sui server Web, utilizzando l'Amministrazione centrale di SharePoint (nella pagina Operazioni, all'interno della sezione Registrazione e report, fare clic su Registrazione diagnostica). È possibile specificare l'evento meno critico che dovrà essere riportato nel registro eventi e nel registro di traccia. Il registro di traccia (posizionato, per impostazione predefinita, in %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs) è molto utile se si ricercano informazioni di basso livello, ma può riempirsi molto rapidamente, pertanto è bene utilizzare questa funzione con parsimonia.
Un altro metodo per ottenere informazioni diagnostiche consiste nell'attivare il debug per l'applicazione Web interessata configurando il relativo file web.config, come illustrato nel documento pdf sulla configurazione di applicazioni Web nel materiale di accompagnamento. SharePoint consente di visualizzare informazioni di traccia dettagliate direttamente nell'interfaccia utente. Un vantaggio di questo approccio è la possibilità di visualizzare le informazioni di errore rilevanti senza dover analizzare megabyte di dati. Uno svantaggio è la necessità di modificare la configurazione di sistema dell'applicazione Web. Non dimenticare di eseguire il backup del file web.config originale e di ripristinare la configurazione iniziale una volta terminata la risoluzione dei problemi.
È inoltre possibile configurare il servizio SMTP per la scrittura di informazioni di elaborazione dettagliate nel registro del protocollo SMTP (in Gestione IIS, sulla scheda Generale, selezionare la casella di controllo Consenti registrazione attività). Accertarsi di installare il modulo di registrazione ODBC, anche se non si prevede di utilizzarlo, con la funzionalità del servizio SMTP, come illustrato nel documento pdf relativo all'integrazione della messaggistica SharePoint nel materiale di accompagnamento. In caso contrario, il servizio SMTP non scriverà il registro di protocollo. Per impostazione predefinita, il registro di protocollo SMTP si trova in %SystemRoot%\System32\LogFiles\SmtpSvc1. Si tratta di un file di testo che consente di analizzare la comunicazione SMTP in dettaglio e di determinare se un messaggio ha lasciato il server SharePoint.
Sul server Trasporto Hub che comunica con il servizio SMTP, è inoltre possibile attivare la registrazione protocollo nella configurazione di connettore di invio e di ricezione (vedere il documento pdf sull'integrazione della messaggistica SharePoint). Per seguire il percorso dei messaggi nell'ambiente Exchange Server 2007 attraverso i server Trasporto Hub e i server Cassette postali, è possibile utilizzare molti altri strumenti, quali il rilevamento messaggi, il visualizzatore code e la traccia della pipeline. Per informazioni dettagliate sulla risoluzione di problemi relativi al flusso di posta in Exchange Server 2007, consultare l'articolo "Problemi di trasporto e flusso di posta" all'indirizzo go.microsoft.com/fwlink/?LinkID=120145.
Sui controller di dominio Active Directory, è possibile ottenere informazioni dettagliate sulla risoluzione dei problemi attivando la registrazione diagnostica per l'accesso a directory e altre categorie, impostando le relative voci di registro in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Il valore 0x0 per una categoria indica che saranno registrati solo gli eventi critici, mentre il valore 0x5 rappresenta tutti gli eventi, incluse le informazioni di debug. L'utilizzo di un livello di registrazione superiore a 0x3 può ridurre le prestazioni del server e causare il rapido riempimento del registro eventi di Windows. Quando si eseguono operazioni normali, tutti i valori devono essere impostati su 0x0.
Durante la risoluzione dei problemi, raccogliere informazioni diagnostiche dettagliate su server SharePoint, Exchange e Active Directory può consentire di individuare in modo rapido e affidabile l'area interessata. Inoltre, possono risultare utili strumenti per la risoluzione dei problemi aggiuntivi, quali gli strumenti TCP/IP (ping, tracert, telnet e così via) e Network Monitor, in quanto gran parte delle comunicazioni tra questi sistemi avviene tramite la rete di computer. Microsoft® Network Monitor 3.1 è disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=120143.

Trasferimento di messaggi in uscita
Risorse
  • Sito Web Prodotti e tecnologie SharePoint
  • Windows SharePoint Services TechCenter
  • Centro per sviluppatori di Windows SharePoint Services
  • Blog del team Prodotti e tecnologie Microsoft SharePoint
Una volta dotati di registri eventi, registri di traccia, registri di protocollo, registri per il rilevamento di messaggi e tracce di rete, è possibile passare alla risoluzione dei problemi relativi all'integrazione di messaggistica SharePoint. Per iniziare, sarà analizzata la parte più semplice, il trasferimento di messaggi in uscita. SharePoint supporta il trasferimento di messaggi in uscita in diverse configurazioni e non richiede un servizio SMTP locale sui server Web. Tuttavia, in uno scenario di integrazione di messaggistica completa, la configurazione consigliata prevede l'utilizzo del servizio SMTP locale. Nella Figura 2 sono illustrati i componenti principali dello scenario.
Figura 2 Trasferimento di messaggi in uscita (fare clic sull'immagine per ingrandirla)
Questo scenario di messaggistica comprende quattro fasi: SharePoint deve trasferire il messaggio al servizio SMTP, il servizio SMTP deve elaborarlo, il server Trasporto Hub deve ricevere il messaggio ed Exchange Server 2007 deve trasferirlo alla destinazione finale.
Se SharePoint non riesce a trasferire il messaggio al servizio SMTP, in genere sarà visualizzato un errore nell'interfaccia utente, poiché l'invio di una notifica tramite posta elettronica non è possibile. La causa può essere la mancata esecuzione del servizio SMTP. In alternativa il registro di protocollo SMTP potrebbe comunicare che il servizio SMTP ha rifiutato il tentativo di invio con il codice di errore 550 (L'azione richiesta non è stata eseguita: cassetta postale non disponibile), il quale indica che il problema interessa il servizio SMTP.
Per verificare che non si tratti di un problema relativo a SharePoint, è possibile utilizzare uno script di base (vedere SMTP.vbs nel materiale di accompagnamento) per inviare un messaggio di test tramite SMTP con le stesse informazioni su mittente e destinatario. Se si tratta di un problema relativo al servizio SMTP, lo script non avrà esito positivo. In effetti, questo script potrebbe fornire utili indizi sulla causa principale del problema, che purtroppo non è possibile ottenere da SharePoint neppure se il debug è attivo, come illustrato in Figura 3.
Figura 3 Inoltro dei messaggi impossibile (fare clic sull'immagine per ingrandirla)
Concedendo al server Web le autorizzazioni di inoltro nella configurazione del servizio SMTP e riavviando quest'ultimo, è possibile risolvere il problema di invio dei messaggi SharePoint. Ora il messaggio può raggiungere il servizio SMTP e la domanda seguente è se il servizio SMTP può eseguire il routing al server Trasporto Hub.
Se il messaggio rimane nella cartella della coda, il servizio SMTP non è in grado di contattare il server Trasporto Hub. Questo si verifica perché il servizio Microsoft Exchange Transport non è in esecuzione oppure a causa di un problema di configurazione o comunicazione di rete. Il client Telnet consente di verificare in modo rapido e semplice se è possibile connettersi alla porta di destinazione di un connettore di ricezione configurato per la comunicazione interna.
Non si tratta necessariamente della porta TCP 25. Infatti, se il servizio SMTP utilizza questa porta, è possibile trasferire i messaggi al connettore di ricezione predefinito per i server Trasporto Hub, configurato in modo da bloccare l'invio di messaggi anonimi. In questo caso, sarà visualizzato un messaggio nella cartella di ricezione (arrestare il servizio Windows SharePoint Services Timer; in caso contrario, il messaggio scomparirà dopo alcuni secondi). Il file del messaggio è una notifica sullo stato del recapito indicante che il messaggio è stato rifiutato con "Codice diagnostica: smtp;530 5.7.1 Il client non è stato autenticato".
Per risolvere il problema, occorre creare un connettore di ricezione dedicato per i server SharePoint. Poiché i server SharePoint sono sistemi interni, selezionare l'opzione di autenticazione con protezione esterna. In tal modo, non è necessario concedere autorizzazioni estese all'account di ACCESSO ANONIMO. Inoltre, valutare l'utilizzo di IPsec per proteggere la comunicazione tra i server SharePoint e il server Trasporto Hub.
Se i messaggi lasciano la cartella di coda SMTP e i registri del protocollo SMTP sul server SharePoint e sul server Trasporto Hub (verificare la cartella %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive) indicano che il trasferimento è stato eseguito correttamente, è possibile considerare l'operazione terminata, a patto che Exchange Server 2007 riesca a eseguire il routing del messaggio alla destinazione. Come accennato in precedenza, utilizzare gli strumenti per la risoluzione dei problemi di flusso della posta inclusi in Exchange Server 2007 per verificare eventuali cause nel caso in cui i messaggi non raggiungano i destinatari Exchange. In questa fase informazioni inesatte sui destinatari, filtri antispam e restrizioni di dimensione dei messaggi possono impedire la consegna finale.

Trasferimento di messaggi in entrata
Nella direzione opposta il trasferimento dei messaggi è un po' più complesso, poiché i potenziali problemi sono meno evidenti. Ad esempio, nella documentazione sui prodotti SharePoint, si consiglia di configurare i record MX in DNS per i domini di posta elettronica SharePoint, per favorire il routing errato dei messaggi in un'organizzazione Exchange.
Exchange Server 2007 utilizza connettori di invio con spazi di indirizzi associati per il trasferimento dei messaggi. Potrebbe quindi instradare i messaggi SharePoint ai server Trasporto Edge per il trasferimento tramite Internet, anche se i server SharePoint dell'utente sono interni. Per il trasferimento di messaggi interni, preferire l'utilizzo di connettori di invio con spazi degli indirizzi dettagliati e specificare i server SharePoint che eseguono il servizio SMTP come smart host nella configurazione dei connettori (vedere il documento pdf sull'integrazione della messaggistica SharePoint nel download complementare). Stabilire una tipologia di routing ben definita con server di testa di ponte dedicati garantisce che il trasferimento di messaggi da Exchange a SharePoint avvenga in modo affidabile.
Al fine di verificare che i messaggi giungano ai server SharePoint, arrestare il servizio Windows SharePoint Services Timer. I messaggi si accumuleranno nella cartella di ricezione, poiché è il servizio Timer a elaborarli e a collocare i file di allegati in raccolte documenti associate agli indirizzi di posta elettronica dei destinatari, come indicato nella Figura 4. Se i messaggi non raggiungono la cartella di ricezione, utilizzare il visualizzatore code sul server Trasporto Hub per verificare se Exchange esegue correttamente il routing. Quindi, analizzare i problemi relativi alla comunicazione di rete che potrebbero impedire al server Trasporto Hub di comunicare con il servizio SMTP sul server SharePoint.
Figura 4 Trasferimento di messaggi in entrata (fare clic sull'immagine per ingrandirla)
Quando si riavvia il servizio Timer, i messaggi vengono rimossi dalla cartella di ricezione. Tuttavia, se gli allegati dei messaggi non vengono inseriti nelle raccolte di destinazione, sebbene SharePoint indichi nel registro eventi di Windows che l'elaborazione è stata eseguita correttamente, significa che Exchange ha inviato i messaggi in formato RTF. Per esaminare questo problema, arrestare nuovamente il servizio Timer, inviare un altro messaggio con un allegato dal client Outlook® in uso, quindi, una volta presente nella cartella di ricezione, aprirlo in Blocco note. A questo punto, ricercare la stringa "winmail.dat". Se è presente, Exchange Server invia i messaggi nel formato sbagliato.
Per SharePoint, infatti, gli allegati di messaggi devono essere codificati nei formati MIME o UUENCODE. Inoltre, nel registro eventi di Windows, SharePoint non visualizza problemi di elaborazione legati a winmail.dat (vedere Figura 5). Semplicemente, gli allegati dei file non saranno visualizzati nella raccolta documenti. Utilizzare Blocco note come strumento per la risoluzione dei problemi ed eliminare i problemi di formattazione configurando una definizione di dominio remoto in Exchange Management Console per il dominio di posta elettronica SharePoint. In corrispondenza dell'opzione Formato del messaggio originale inviato come allegato al rapporto del journal, per Formato RTF di Exchange, selezionare Never use (Mai).
Figura 5 Elaborazione di messaggi winmail.dat (fare clic sull'immagine per ingrandirla)

Gestione directory
Uno degli eventi più utili del servizio Timer è il 6873, il quale indica che si è verificato un errore durante l'elaborazione di un messaggio di posta elettronica in entrata a causa di un alias sconosciuto. Ciò accade se un utente Exchange specifica un indirizzo di posta elettronica SharePoint non corretto durante l'invio di messaggi, ad esempio una raccolta documenti inesistente.
È possibile ridurre al minimo l'impatto di questo problema configurando il servizio di gestione directory nelle impostazioni dei messaggi di posta elettronica in entrata nell'Amministrazione centrale di SharePoint per la creazione di oggetti destinatario per le raccolte documenti abilitate alla posta in Active Directory. Gli utenti Exchange potranno quindi selezionare comodamente dalla rubrica gli oggetti destinatario con informazioni relative all'indirizzo corrette.
Tuttavia, in questo modo, si apre una nuova area di tematiche legate alla risoluzione dei problemi. In una configurazione di sistema protetta basata sul principio del privilegio minimo, il servizio di gestione directory non opera correttamente, in quanto questa funzionalità ha requisiti di autorizzazione elevati sul server Web. Per di più, quando nella documentazione del prodotto (ad esempio technet.microsoft.com/library/cc262947.aspx) viene suggerito di concedere all'account del pool di applicazioni dell'Amministrazione centrale il diritto di "creare, eliminare e gestire gli account utente" nell'unità organizzativa specificata per gli oggetti destinatario SharePoint in Active Directory, la situazione è sopravvalutata.
Il servizio di gestione directory crea oggetti di contatto e gruppo, pertanto, l'account del pool di applicazioni di Amministrazione centrale richiede il controllo completo sugli oggetti di questo tipo in tale unità organizzativa, ma non necessita di autorizzazioni amministrative per gli account utente. Se si configura il servizio di gestione directory in una Web farm come indicato e si tenta di abilitare alla posta una raccolta documenti, sussistono buone probabilità che si verifichi un errore di "Accesso negato".
Le informazioni dell'errore indicano problemi relativi all'autorizzazione di Active Directory e gli amministratori SharePoint non esitano ad assegnare il controllo completo relativo all'unità organizzativa SharePoint a tutti gli utenti. Tuttavia, questo indebolisce la sicurezza di Active Directory, oltre a non risolvere il problema.
Una risoluzione dei problemi strutturata prevede che venga dapprima localizzata l'area interessata e poi siano applicate modifiche della configurazione adeguate. Seguendo questo approccio, se si verifica il registro eventi di Windows sul controller di dominio e si esegue una traccia della comunicazione di rete tramite Network Monitor, si potrà scoprire che SharePoint non accede ad Active Directory quando si verifica questo problema. Quindi, è improbabile che eventuali modifiche alla configurazione di Active Directory risolvano il problema che, in effetti, si verifica sul server SharePoint.
Purtroppo, ottenere ulteriori informazioni utili su questo problema di autorizzazione è estremamente difficile. SharePoint, infatti, non registra ulteriori informazioni nel registro eventi di Windows. Tuttavia, se si attiva il debug di SharePoint, è possibile visualizzare lo stack di chiamate (come illustrato nella Figura 6), il quale suggerisce che il servizio di gestione directory utilizza il metodo CreateContact di un servizio Web SharePoint. L'SDK SharePoint indicherà che si tratta del servizio Web di integrazione di messaggi di posta elettronica (<WSS_server>:<admin_port>/_Vti_bin/SharepointEmailWS.asmx).
Figura 6 Output del debug
Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters)
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags)
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias)
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration)
   at Microsoft.SharePoint.SPList.Update()
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args)
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)
Ora è utile esaminare SharepointEmailWS.asmx in un browser Web per visualizzare l'elenco di operazioni supportate. È possibile vedere il metodo CreateContact: facendo clic sul relativo collegamento, saranno visualizzati i messaggi SOAP da inviare a questo servizio Web per creare un contatto in Active Directory. Questa informazione è molto utile, poiché consente di creare uno strumento per la risoluzione dei problemi basato su script (vedere SharepointEmailWS.vbs nel materiale di accompagnamento) per operare al di fuori dell'interfaccia utente SharePoint, semplificando la definizione di diversi account utente durante l'esecuzione dei test. Nella Figura 7 sono indicate le informazioni visualizzate se si esegue lo script utilizzando l'account del pool di applicazioni di Amministrazione centrale (sinistra) e l'account di amministratore SharePoint (destra).
Figura 7 Due diversi errori di "Accesso negato" (fare clic sull'immagine per ingrandirla)
I messaggi di errore sono diversi. Entrambi i messaggi indicano che l'accesso è negato, ma l'errore sulla sinistra indica un problema di elaborazione, mentre quello sulla destra no. Quindi, qual è la differenza tra gli account del pool di applicazioni e l'account di amministratore SharePoint?
L'amministratore SharePoint è un amministratore locale sul server SharePoint, mentre gli account di pool di applicazioni non lo sono. Aggiungere gli account di pool di applicazioni della propria applicazione Web al gruppo di amministratori locali e riavviare il server risolve il problema, ma questa non è una novità. Considero inaccettabile la gestione di account di pool di applicazione con privilegi di amministratore sui server Web di produzione.
Perché un account di pool di applicazioni richiede queste autorizzazioni elevate? Di nuovo, è lo script a fornire la risposta. Se si concedono a tutti gli utenti autorizzazioni di amministratore locale sul server Web a scopo di verifica, si scoprirà che gli account di pool di applicazioni possono utilizzare il servizio Web di integrazione della posta elettronica, mentre l'accesso continua a essere negato a tutti gli altri account, inclusi gli amministratori SharePoint. Ciò significa che il servizio Web di integrazione dei messaggi di posta elettronica utilizza la configurazione del pool di applicazioni come base per le decisioni sul controllo dell'accesso.
La configurazione del pool di applicazioni fa parte della metabase IIS (o il file applicationHost.config in IIS 7.0) e l'accesso alla metabase è limitato agli amministratori locali per impostazione predefinita. Per fortuna, è possibile concedere l'accesso alla metabase ad account non amministrativi utilizzando il Metabase Explorer contenuto negli strumenti del Resource Kit IIS 6.0. Su IIS 7.0 è ancora più semplice concedere il controllo completo al file applicationHost.config. È sufficiente eseguire i comandi seguenti:
CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config"
/G "<application pool account>" :F /E iisreset /noforce
Per riassumere, al fine di creare oggetti di contatto in Active Directory, il pool di applicazioni di Amministrazione centrale richiede il controllo completo sugli oggetti di contatto e gruppo nell'unità organizzativa di destinazione. Anche gli account di pool delle applicazioni Web richiedono un accesso completo alla metabase sui server SharePoint nella Web farm. A questo punto, è possibile creare oggetti di contatto utilizzando l'interfaccia utente SharePoint.
Ma non è finita qui. La creazione di oggetti destinatario in Active Directory è solo una metà dell'operazione di integrazione delle directory. L'altra metà consiste nel generare attributi destinatario relativi a Exchange e nell'aggiornare rubriche basate su server. Ad esempio, se si aggiorna l'elenco di indirizzi globale sul proprio server Exchange utilizzando il comando di Exchange Management Shell Update-GlobalAddressList "Elenco indirizzi globale predefinito", sarà possibile trovare nuovi oggetti destinatario per le raccolte documenti SharePoint all'interno della rubrica Outlook. Tuttavia, l'invio di messaggi a questi destinatari genererà report di mancata consegna a causa delle informazioni sull'indirizzo non corrette, come illustrato nella Figura 8.
Figura 8 Impossibile recapitare il messaggio a una raccolta documenti (fare clic sull'immagine per ingrandirla)
L'acronimo IMCEAEX significa Internet Mail Connector Encapsulated Address for Exchange (indirizzo di connettore di posta elettronica Internet incapsulato per Exchange) e indica un indirizzo di destinatario diverso da Exchange incapsulato in un formato che il precedente connettore di posta Internet Exchange è in grado di gestire. Tuttavia, oggi vengono utilizzati Exchange Server 2007 e connettori di invio nativi basati su SMTP.
Il punto è che il servizio Web di integrazione di posta elettronica SharePoint non scrive gli attributi dell'indirizzo che Exchange Server 2007 richiede per il trasferimento dei messaggi, Il servizio scrive solo gli attributi relativi a nome, cognome, nome visualizzato e indirizzo di destinazione (e, facoltativamente, l'msExchRequireAuthToSendTo), ma non imposta un nome alternativo di posta, oppure indirizzi proxy o DN Exchange legacy, e non associa l'oggetto destinatario a un criterio sui destinatari Exchange.
Per risolvere questo problema, utilizzare il cmdlet Get-Mailbox in Exchange Management Shell al fine di ottenere tutti gli oggetti destinatario con un indirizzo di destinazione che indichi il dominio di posta elettronica SharePoint. Quindi, inviare l'output al cmdlet Set-MailContact per attivare i criteri destinatario come segue:
Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True
In alternativa, utilizzare Exchange Management Console e selezionare la casella di controllo "Aggiorna automaticamente indirizzi in base al criterio dell'indirizzo di posta elettronica" nelle proprietà dell'oggetto di contatto.

WSS 3.0 e MOSS 2007 supportano l'integrazione di messaggistica completa per l'abilitazione di avvisi e notifiche basati su messaggi di posta elettronica, flussi di lavoro e invio di documenti. La corretta configurazione dei sistemi non è un compito facile, ma l'integrazione dei messaggi può aumentare la produttività. In particolare, occorre assicurarsi che entrambi i trasferimenti di messaggi in entrata e in uscita funzionino correttamente. Inoltre, accertarsi che l'integrazione delle directory funzioni adeguatamente.
Non sempre i messaggi di errore SharePoint sono intuitivi o informativi. Tuttavia, ho illustrato diversi metodi per approfondire i problemi di integrazione, localizzare le cause principali ed eliminarle in modo sicuro senza mettere in pericolo la protezione dei server SharePoint.

Pav Cherny è un esperto IT e un autore specializzato in tecnologie Microsoft per la collaborazione e le comunicazioni unificate. Le sue pubblicazioni includono white paper, manuali di prodotti e libri su amministrazione del sistema e operazioni IT. Pav è Presidente di Biblioso Corporation, un'azienda specializzata in servizi di localizzazione e documentazione gestita.


Windows PowerShell Anteprima della versione 2.0 di Gestione remota
Don Jones (in inglese)

L'articolo è basato sulla versione non definitiva di Windows PowerShell. Le informazioni riportate sono soggette a modifiche.

Indice
Due tipi di servizio remoto
Sincrono contro asincrono
Spazi di esecuzione riutilizzabili
Servizio remoto fan-in
L'applicazione killer nella versione 2.0
Vi è mai capitato di sperimentare l'ultima CTP (Community Technology Preview) di Windows PowerShell 2.0? L'ultima versione, CTP2, dispone di una gestione remota più raffinata e questo è il momento giusto per iniziare a familiarizzare con le nuove funzionalità che offre. Prima di leggere l'articolo, prendetevi qualche minuto per
scaricarla dal sito Web all'indirizzo go.microsoft.com/fwlink/?LinkID=119707.
Innanzitutto, vorrei chiarire un paio di punti importanti. Una CTP è un codice pre-beta che Microsoft fornisce per dare agli utenti impazienti come me, un'idea della direzione intrapresa con la versione successiva di un'applicazione. Ogni attività cardine o "drop" (come da definizione del settore) della CTP potrebbe essere completamente diversa rispetto alle precedenti, perché il team di sviluppo raccoglie commenti e suggerimenti da parte degli utenti, li esamina attentamente per poi modificare l'applicazione sulla base degli stessi. Tale metodologia introduce un grande vantaggio, ma ci dà anche un avvertimento importante sull'uso della CTP.
Video
Guardate Don Jones mentre dimostra le nuove funzionalità di gestione remota nella CTP2 di Windows PowerShell 2.0.

Il vantaggio è che quando si utilizza la CTP, è possibile inviare commenti e suggerimenti (attraverso il sito Web connect.microsoft.com) sul prodotto, proprio nel momento in cui il team di sviluppo è in grado di metterli in pratica. Se si aspetta la beta o, peggio ancora, la fase della versione finale candidata, è più difficile integrare i commenti e i suggerimenti dell'utente. Durante la CTP può succedere di tutto ed il team può apportare modifiche profonde e radicali.
Ciò mi spinge a darvi l'avvertimento accennato prima: la CTP non è pronta per la produzione. Certo, la CTP2 di Windows PowerShell™ 2.0 potrebbe essere una delle parti più stabili mai viste della versione preliminare del codice, ma bisogna ricordarsi che la prossima "drop" della CTP potrebbe rivelarsi un'applicazione completamente diversa. Per cui, non fate troppo affidamento sulla CTP2 perché la versione successiva potrebbe farvi ricominciare daccapo.
Si noti che la CTP non può essere installata in parallelo con Windows PowerShell 1.0. Per un'installazione ideale, il sistema dovrebbe disporre anche di Microsoft® .NET Framework 3.5 per poter attivare tutte le funzionalità disponibili; in caso contrario, alcune di esse saranno limitate.
Inoltre, poiché la CTP è un codice preliminare, fino ad ora Microsoft ha posto molta enfasi sull'uso dell'applicazione negli ultimi sistemi operativi, cioè Windows Vista® e Windows Server® 2008. Di conseguenza, la compatibilità del sistema operativo attuale non è indicativa della compatibilità del sistema operativo che ci si può aspettare al momento del rilascio del codice finale. Il backporting verrà trattato successivamente nella parte relativa al ciclo di sviluppo.

Due tipi di servizio remoto
Nel mondo della gestione remota, si trovano di solito due tipi di servizio remoto: fan-in e fan-out. Il servizio remoto fan-in coinvolge più amministratori che creano connessioni basate su shell sicure ad un server unico. Windows PowerShell è progettato per attivare questo sistema in modo sicuro, effettuando una partizione dei dati, in modo che, ad esempio, un Exchange Server che ospita l'azienda può fornire ai propri clienti l'accesso amministrativo alle proprie parti di un server. Con il servizio remoto fan-in, si ottiene l'accesso remoto protetto e interattivo alla copia di Windows PowerShell (solo alla versione 2.0) installata su un server remoto.
Il servizio remoto fan-out consiste nell'inviare simultaneamente una serie di comandi a un intero gruppo di server remoti. I comandi effettuano il fan out dalla propria workstation al gruppo di server in parallelo. I comandi vengono eseguiti su ogni server e i risultati, sotto forma di oggetti di Windows PowerShell, vengono restituiti alla propria workstation così è possibile riesaminarli e lavorarci. Windows PowerShell supporta due tecnologie principali per il servizio remoto fan-out, Strumentazione gestione Windows® (WMI) e Gestione remota Windows, che inizialmente sono state fornite con Windows Server 2008 ed aggiornate successivamente nella CTP di Windows PowerShell 2.0.

Sincrono contro asincrono
In realtà, anche Windows PowerShell 1.0 disponeva di alcune funzionalità fan-out di base, legate a WMI. Ad esempio, era possibile creare facilmente un array di nomi computer e recuperare successivamente una classe di WMI da ognuno:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem
    –computer $names
I metodi di esecuzione, quali il riavvio del computer, richiedevano un po' più di lavoro poiché la versione 1.0 non offriva nessuna funzione di massa per eseguire i metodi WMI. Ciò è stato modificato nella CTP in versione 2.0, grazie al cmdlet Invoke-WmiMethod:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot
Tuttavia, questa tecnica pone un problema; si tratta di un metodo sincrono, il che significa che viene contattato un computer per volta e che bisogna aspettare che ognuno finisca prima di poter eseguire altri comandi. La CTP introduce però un concetto nuovo, i processi in background, che consente ai comandi come questo di essere eseguiti in background. Più semplicemente, è possibile eseguire un comando WMI in background, aggiungendo il parametro AsJob:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob
Si può riesaminare lo stato del lavoro risultante eseguendo Get-PSJob ed visualizzare i risultati finali del processo eseguendo Receive-PSJob. (Tratterò maggiormente i dettagli riguardo alla gestione del processo in un articolo futuro). Tuttavia, il cmdlet Invoke-Command fornisce modi anche migliori per eseguire comandi in background, come il seguente:
$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob
Questo fa azionare il comando di Get-WmiObject in ogni computer specificato e vien eseguito localmente in un secondo momento. In genere, viene eseguito molto più velocemente e senza doversi affidare alle connessioni della RPC (Remote Procedure Call) di WMI. Al contrario, Invoke-Command utilizza Gestione remota Windows, che per impostazione predefinita si serve delle porte 80 o 443, le quali rendono più facile sfogliare i firewall e sono interamente configurabili. Invoke-Command supporta anche parametri aggiuntivi per alternare le credenziali e le limitazioni, consentendo all'utente di scegliere come destinazione centinaia di computer ma di averne solo un piccolo gruppo in esecuzione in parallelo. Ciò permette di evitare la congestione e il sovraccarico in eccesso.

Spazi di esecuzione riutilizzabili
Se si vuole gestire in modalità remota un determinato gruppo di computer più di una volta, è necessario prendere in considerazione l'utilizzo di spazi di esecuzione piuttosto che di semplici elenchi di nomi computer. In Windows PowerShell, uno spazio di esecuzione è semplicemente un'istanza del motore della shell, sia che l'esecuzione avvenga localmente sul proprio computer come finestra di dialogo della console della shell, sia che avvenga in background su un computer remoto. L'avvio di uno spazio di esecuzione remoto è semplice:
$names = @("server1","server2","server2")
New-RunSpace –computer $names
Poiché gli spazi di esecuzione utilizzano anche Gestione remota Windows, si servono anche della porta 80 (o 443, se viene specificato il parametro UseSSL) per impostazione predefinita. Possono anche accettare credenziali alternative e così via. Se vengono recuperati gli oggetti dello spazio di esecuzione risultanti, è possibile passarli a Invoke-Command e Windows PowerShell invierà il comando ai computer su cui esistono quegli spazi di memoria:
$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob
Il vantaggio è che, in questo caso, gli spazi di esecuzione rimangono attivi fino a quando la shell è aperta, quindi si possono riutilizzare per comandi aggiuntivi.

Servizio remoto fan-in
Gli spazi di esecuzione rappresentano anche la chiave del servizio remoto fan-in. Ad esempio, la Figura 1 mostra che è stato creato un spazio di esecuzione su un computer remoto, è stato recuperato un riferimento a quello spazio di esecuzione ed è stato utilizzato successivamente il cmdlet Push-Runspace per attivare lo spazio di esecuzione. A questo punto, si eseguono dei comandi sul computer remoto, tipo quelli consentiti dal protocollo SSH o da altre utilità di shell remota. L'esecuzione di Pop-Runspace restituisce il proprio spazio di esecuzione "locale" originale, mentre il prompt della shell aiuta a tenere traccia del punto in cui si è arrivati in qualsiasi momento.
Figura 1 Utilizzo di spazio di esecuzione per eseguire comandi su un computer remoto (fare clic sull'immagine per ingrandirla)
L'esatta sequenza di comandi eseguita è questa:
PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>
Tale tecnica è denominata fan-in perché più amministratori possono aprire spazi di esecuzione interattivi remoti sullo stesso server, nello stesso momento: le operazioni si "aprono a ventaglio" dalle singole workstation al server. Un nuovo modello di protezione in Windows PowerShell 2.0 consente di creare shell e cmdlet in numero limitato, impedendo così ad ogni amministratore di apportare modifiche globali e limitandone l'azione alla propria area della shell. (Queste nuove tecniche di protezione richiedono una certa personalizzazione nello sviluppo del software, in un linguaggio destinato a .NET Framework. Ciò va al di là dell'ambito della rubrica di Windows PowerShell, ma è bello sapere che tali funzionalità esistono).

L'applicazione killer nella versione 2.0
La CTP di Windows PowerShell 2.0 ha un elenco di nuove funzionalità sorprendentemente lungo. A mio avviso, l'applicazione rivoluzionaria è il servizio remoto. Tutti gli amministratori, in quasi tutti gli ambienti, possono trarne vantaggio.
Anche voi dovreste familiarizzare con queste funzionalità, in modo da poter offrire i vostri suggerimenti al team responsabile del prodotto. Volete che le porte predefinite di Gestione remota Windows vengano gestite attraverso i Criteri di gruppo? I cmdlet dovrebbero funzionare diversamente? Ci sono problemi a livello di prestazioni? Gestione remota Windows è abbastanza facile da configurare? Potrete svolgere un ruolo attivo inviando i vostri suggerimenti a connect.microsoft.com o condividere commenti e suggerimenti con i vincitori del premio Microsoft MVP, compreso me (per contattarmi, utilizzate i forum su ScriptingAnswers.com). Quindi, lasciatevi coinvolgere e date il vostro contributo per creare l'applicazione killer della prossima generazione di Windows PowerShell!
Cmdlet del mese: Select-Object
Provate questo: Get-Service | ConvertTo-HTML | Out-File Services.htm. Adesso esaminate il file HTML prodotto nel vostro browser Web. Ci sono un bel po' di informazioni, non è vero? Se solo ci fosse un modo per ridurle selezionando le informazioni che ci interessano! Il modo c'è ed è proprio questa la funzione di Select-Object. Ad esempio, poniamo che si voglia solo un elenco di nomi dei servizi ed il relativo stato corrente. Si può utilizzare questo: Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm.
Una cosa da ricordare è che Select-Object scarta l'oggetto originale (i servizi, in questo caso) e produce un oggetto personalizzato (letteralmente, un oggetto di tipo PSCustom) che contiene solo le proprietà specificate. Tutte le funzionalità dell'oggetto originale non sono più accessibili, quindi probabilmente si vorrà tenere Select-Object alla fine della pipeline, lavorando con l'oggetto originale fino a quando è possibile farlo.

Don Jones è coautore di Windows PowerShell v2.0: TFM e l'istruttore del corso di formazione in aula "Forze speciali" di ScriptingAnswers.com (scriptinganswers.com/training.asp). È possibile contattarlo all'indirizzo jeepdon@mac.com.


Hey, Scripting Guy! Scegliere la strada diretta
Microsoft Scripting Guys

Negli ultimi mesi, uno degli Scripting Guy ha sperimentato qualcosa di nuovo nell'area di Seattle. Si tratta di un programma, chiamato pedaggio elettronico, che stanno collaudando in varie città degli Stati Uniti. Tuttavia, nello stato di Washington, è conosciuto come Good to Go!
Funziona in questo modo: si paga per ottenere un dispositivo elettronico da fissare sul parabrezza. Inoltre, è necessario aprire un conto e depositarvi una piccola somma di denaro. Ogni volta che si passa sotto uno dei dispositivi di controllo sull'autostrada, l'ammontare del pedaggio viene automaticamente addebitato sul conto. Fondamentalmente, si paga per percorrere l'autostrada (anche quelle che non prevedono il pagamento del pedaggio perché ben lontane dall'essere considerate autostrade) senza la necessità di fermarsi al casello.
Ebbene, su diverse autostrade, coloro che utilizzano le auto di gruppo (car-pool) sono esenti dal pagamento. Tuttavia, la parte interessante di Good to Go! è che funziona solo nella corsia "carpool". Vi chiederete per quale motivo. Perché mai si dovrebbe utilizzare l'auto di gruppo se poi è necessario pagare? In realtà non si paga. Questo sistema addebita il pedaggio solo a coloro che desiderano utilizzare la corsia carpool pur viaggiando da soli. Una ragione ovvia per cui si desidera percorrere la corsia carpool è che generalmente si incontra meno traffico; a volte è l'unica corsia in cui le automobili camminano.
Come già menzionato, tale sistema è in fase di sperimentazione, nonostante migliaia di automobilisti si siano già iscritti al servizio. Ci sono tantissime persone nell'area di Seattle disposte a pagare per prendere la strada più diretta per raggiungere la meta.
Nell'articolo di questo mese, gli Scripting Guy hanno deciso di condurre un piccolo esperimento. Abbiamo deciso di mostrare una strada diretta nota con il nome di Microsoft® Visual Basic® Express Edition. Iniziamo col dire che una delle caratteristiche principali di questa strada è la gratuità; non viene addebitato alcun pedaggio indipendentemente da chi utilizzi queste informazioni, dal numero delle persone o dall'orario. Sembra piuttosto interessante, o no? Ovviamente, c'è un piccolo prezzo da pagare in quanto è necessario imparare alcune cose nuove, ma ne vale la pena per i benefici che se ne possono ricavare.
Prima di continuare, è necessario sottolineare che siamo consapevoli di superare un pochino i limiti. In genere i prodotti Visual Studio® ad esempio Visual Basic e Visual C#® sono oggetto di discussione in MSDN® Magazine e non in TechNet Magazine. Poiché le riviste MSDN e TechNet sembrano avvicinarsi sempre più al punto di diventare un grande "disfunzionale" famiglia felice, speriamo che ci venga concessa un po' di libertà. Inoltre, anche se stiamo parlando di lavorare con ciò che è stato tradizionalmente uno strumento per sviluppatori, ci rivolgiamo comunque anche agli amministratori di sistema Windows®. Se rimanete con noi altri cinque minuti potrete scoprire di cosa stiamo parlando.
La prima cosa da fare è installare Visual Basic. No, un attimo. Non sono ammesse frasi tipo: "Non ce l'ho"! o "non me lo posso permettere"! Microsoft fornisce un'edizione Express di Visual Basic che è possibile scaricare gratuitamente da microsoft.com/express/download.
Non intendiamo analizzare in dettaglio come utilizzare Visual Basic Express. Sono disponibili delle esercitazioni nella Guida in linea che è piuttosto affidabile. (Difficile da credere, vero?) Vogliamo solo mostrare l'utilizzo di Visual Basic Express per risolvere un problema particolare presente in Windows Vista® (sebbene questo esempio funzioni anche in versioni precedenti di Windows) e poi potrete continuare a "giocarci" per conto vostro. Il problema che intendiamo risolvere è il seguente: come si apre la finestra di dialogo Apri in Windows Vista?
Abbiamo spiegato come aprire una finestra di dialogo Apri da uno script pochi anni fa (vedere l'articolo "Come visualizzare una finestra di dialogo che consenta di scegliere i file" all'indirizzo microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx). L'articolo è stato pubblicato a gennaio 2005, molto tempo prima della creazione di Windows Vista. La soluzione utilizza il controllo Activex® UserAccounts.CommonDialog per aprire una finestra di dialogo Apri, che consente di ricercare un file da aprire. Sfortunatamente, questo controllo è stato rimosso da versioni di Windows quali Windows Vista; ciò significa che questa soluzione non funziona sui sistemi più recenti. (No, nessuno ci ha chiesto se fosse una buona idea). Di conseguenza, per quanto ne sappiamo, non c'è modo di aprire una finestra di dialogo Apri utilizzando VBScript. Perciò, invece di scrivere uno script utilizzeremo Visual Basic per scrivere un'applicazione. Questa applicazione consente, tra l'altro, di aprire una finestra di dialogo Apri.
Sì, giusto, l'esempio che vi stiamo per mostrare consente di creare un'applicazione intera in Visual Basic. Ciò può spaventare un pochino all'inizio, ma vedrete che utilizzando Visual Basic Express, scrivere un'applicazione intera sarà facile come scrivere uno script. Questa applicazione sarà composta da una finestra o form che consente di fare clic su un pulsante ed aprire una finestra di dialogo Apri. Quindi, da questa finestra di dialogo è possibile scegliere i file di testo sui quali l'applicazione eseguirà la lettura e visualizzerà una serie selezionata di contenuti all'interno del form.
Bene, iniziamo. Innanzitutto, apriamo Visual Basic Express. La prima cosa da fare è creare un progetto nuovo scegliendo Nuovo progetto dal menu File. In tal modo viene visualizzata la finestra di dialogo Nuovo progetto. (Si noti che se si utilizza una versione di Visual Basic Express precedente al 2008, ci saranno alcune piccole differenze con ciò che verrà mostrato). Verrà creata un'applicazione Windows Forms, per cui è necessario scegliere il modello e il tipo dell'applicazione Windows Forms ed immettere il nome che si desidera dare al progetto. Il nome che abbiamo assegnato noi è ReadFiles, come è possibile vedere nella Figura 1.
Figura 1 Creazione di un nuovo progetto in Visual Basic (Fare clic sull'immagine per ingrandirla)
Quando il progetto viene creato, fornisce automaticamente un form nuovo con cui lavorare. L'applicazione che vogliamo creare presenterà un form simile a quello mostrato nella Figura 2. Come abbiamo detto, il form contiene un pulsante; facendo clic su tale pulsante viene visualizzata la finestra di dialogo Apri, aperta alla cartella C:\Scripts. Possono essere selezionati uno o più file di testo da un punto qualunque del file system. L'applicazione leggerà la prima riga di ciascun file di testo selezionato e visualizzerà i risultati nella casella di riepilogo nel form. (Se tutto ciò vi suona familiare, probabilmente avete partecipato ai Giochi di scripting 2008 nella categoria principianti: Microsoft.com/technet/scriptcenter/funzone/games/games08/bevent3.mspx.).
Figura 2 Il form ReadFiles che verrà mostrato agli utenti
Per creare il form, dobbiamo trascinare i controlli dalla Casella degli strumenti al form del progetto. Per impostazione predefinita la Casella degli strumenti è aperta nella parte sinistra della finestra Visual Basic. (Se la Casella degli strumenti non è aperta, fare clic sul pulsante nella parte sinistra dell'area di lavoro di Visual Basic ed espandere Tutti i Windows Form). Fare clic su Pulsante nella Casella degli strumenti, quindi trascinare il mouse attraverso il form per dare al pulsante le dimensioni desiderate. Per aggiungere un'etichetta al pulsante, fare clic sul pulsante che è stato appena aggiunto al form e digitare l'etichetta che desiderata. (Altrimenti, è possibile modificare la proprietà Text nella finestra di dialogo Proprietà, per impostazione predefinita sul lato inferiore destro dell'area di lavoro di Visual Basic). Il nostro pulsante è stato etichettato Ricerca file. Successivamente, fare clic su ListBox, quindi di nuovo sul form e trascinare il mouse per creare la casella di riepilogo. Utilizzeremo la casella di riepilogo per visualizzare le righe che leggiamo dai file di testo.
Ecco tutti i passaggi necessari per creare il form. Ora arriva la parte divertente: Dobbiamo fare in modo che accada qualcosa facendo clic sul pulsante. Innanzitutto, fare doppio clic sul controllo Pulsante sul form. In tal modo viene aperto un editor di codice con una nuova subroutine già pronta, chiamata Button1_Click:
Private Sub Button1_Click _
  (ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
  Handles Button1.Click
End Sub
Tale subroutine viene eseguita ogni volta che si fa clic sul pulsante sul form. Come si può osservare, tale subroutine al momento è vuota; è necessario aggiungere il codice che comunicherà all'applicazione cosa fare quando si fa clic sul pulsante. Ma cosa vogliamo fare? Bene, innanzitutto vogliamo fare ciò che abbiamo menzionato all'inizio di questo articolo: aprire una finestra di dialogo Apri. Per far ciò utilizzeremo Microsoft .NET Framework, come tutte le operazioni che verranno eseguite con Visual Basic.
Iniziamo aggiungendo un paio di istruzioni Imports al di sopra della subroutine:
Imports System
Imports System.IO
Queste istruzioni specificano gli spazi dei nomi .NET Framework. Utilizzeremo delle classi presenti in questi spazi dei nomi, per cui li importiamo qui così possiamo fare riferimento semplicemente alle classi che desideriamo. Si noti che queste istruzioni vanno inserite al di sopra della subroutine. Le istruzioni Imports sono globali, ciò significa che non possono andare in una subroutine o in una funzione; devono essere al di fuori per conto loro.
In VBScript, a meno che non venga aggiunta l'istruzione Option Explicit nella parte superiore dello script, non è necessario dichiarare esplicitamente le variabili. In Visual Basic, tale istruzione viene aggiunta automaticamente, per cui è necessario dichiarare tutte le variabili. Sarà necessaria una variabile al fine di mantenere un riferimento all'oggetto OpenFileDialog (che rappresenta la finestra di dialogo Apri):
Dim dlg As Windows.Forms.OpenFileDialog
Ora che abbiamo dichiarato una variabile di tipo OpenFileDialog, possiamo creare una nuova istanza di questo oggetto, come indicato di seguito:
dlg = New OpenFileDialog()
Tuttavia, non è ancora stata visualizzata la finestra di dialogo. In primo luogo, è necessario impostare alcune proprietà:
dlg.Multiselect = True
dlg.InitialDirectory = "c:\scripts"
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
La proprietà Multiselect consente di specificare il numero dei file che l'utente può aprire dalla finestra di dialogo Apri. Se si desidera avere la possibilità di scegliere più di un file, è necessario impostare tale proprietà su True. Impostiamo la proprietà InitialDirectory su C:\Scripts. Se questa proprietà non viene impostata, la finestra di dialogo viene aperta nella directory principale del computer.
Infine, ma non meno importante, impostiamo la proprietà Filter:
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
In tal modo è possibile filtrare i file da visualizzare nella finestra di dialogo. Mostreremo solo i file .txt. L'impostazione di queste proprietà consente di visualizzare una finestra di dialogo Apri simile a quella presente nella Figura 3.
Figura 3 Finestra di dialogo Apri che visualizza solo i file di testo (Fare clic sull'immagine per ingrandirla)
È arrivato il momento di visualizzare la finestra di dialogo. Per far ciò utilizziamo il metodo ShowDialog:
dlg.ShowDialog()
Il metodo ShowDialog restituisce un valore che indica se è stato fatto clic su Apri, per aprire i file selezionati oppure su Annulla, per chiudere la finestra di dialogo. Facendo clic su Annulla, non vengono eseguite ulteriori operazioni. Per cui, mettiamo la chiamata a ShowDialog in un'istruzione If per assicurarci che si faccia clic su Apri prima di continuare:
If dlg.ShowDialog() = _
  Windows.Forms.DialogResult.OK Then
Sì, lo sappiamo, abbiamo selezionato la proprietà OK piuttosto che la proprietà Apri. In realtà, il pulsante Apri è lo stesso del pulsante OK — è semplicemente più logico visualizzare il pulsante Apri.
Ora dobbiamo sapere quale o quali file sono stati selezionati dalla finestra di dialogo. I nomi dei file si trovano nella proprietà FileNames dell'oggetto OpenFileDialog, quindi impostiamo un loop For Each per leggere tutti i nomi dei file contenuti in questa proprietà:
For Each strName In dlg.FileNames
E poi? Abbiamo dimenticato di dichiarare strName:
Dim strName As String
Ora dobbiamo aprire ciascuno di questi file ed eseguirne la lettura. Per far ciò in Visual Basic è necessario utilizzare un blocco Using:
Using sr As StreamReader = File.OpenText(strName)
Un blocco Using non viene utilizzato dai creatori di script VBScript, poiché in realtà in VBScript non esiste. Visual Basic è migliore (OK, in molti casi estremamente migliore) nella gestione delle risorse di sistema in confronto a VBScript. Il vantaggio di un'istruzione Using è la possibilità di assicurarsi che le risorse di sistema vengano liberate una volta chiuso il blocco. In tal caso, ci stiamo solo assicurando di non dipendere dai contenuti dei file e i grandi blocchi di memoria.
Sappiamo che questo sembra un po' complicato. Ma deve essere preso in considerazione solo come un'istruzione Set. Stiamo semplicemente eseguendo la creazione di un'istanza di un oggetto nuovo, in questo caso un oggetto StreamReader e l'assegnazione ad esso di un flusso di testo restituito dal metodo File.OpenText. Si noti che all'OpenText viene passato il nome del file che si desidera aprire, il file dalla raccolta FileNames di cui stiamo attualmente eseguendo il loop.
Dunque, la variabile StreamReader, sr, contiene il contenuto del file. Ora abbiamo bisogno di un'altra variabile:
Dim strLine As String
Utilizzeremo questa variabile per memorizzare la prima riga dal file di testo che abbiamo appena aperto:
strLine = sr.ReadLine()
Leggiamo la prima riga dal file chiamando il metodo ReadLine sull'oggetto StreamReader. (Ricordate che l'oggetto StreamReader presenta il contenuto del file). Memorizziamo questa riga di testo nella variabile strLine.
Ora chiamiamo semplicemente il metodo Add sull'oggetto ListBox per aggiungere questa riga alla casella di riepilogo:
ListBox1.Items.Add(strLine)
Per questo esempio, è necessaria solo la prima riga del file, in modo da poter chiudere sia StreamReader — non vogliamo più mantenere l'intero testo del file di testo — che il blocco Using:
sr.Close()
End Using
Successivamente, il loop continua a cercare il successivo file selezionato dalla finestra di dialogo Apri finché non vengono letti tutti i file selezionati e non vengono aggiunte tutte le righe alla casella di riepilogo. Il codice completato è simile a quanto mostrato nella Figura 4.
Figura 4 Codice ReadFiles completo
Imports System
Imports System.IO

Public Class Form1

  Private Sub Button1_Click _
   (ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
   Handles Button1.Click
    Dim dlg As Windows.Forms.OpenFileDialog
    Dim strName As String

    dlg = New OpenFileDialog()

    dlg.Multiselect = True
    dlg.InitialDirectory = "c:\scripts"
    dlg.Filter = "txt files (*.txt)|" & _
      "*.txt|All files (*.*)|*.*"

    If dlg.ShowDialog() = _
     Windows.Forms.DialogResult.OK Then
      For Each strName In dlg.FileNames
        Using sr As StreamReader = _
         File.OpenText(strName)
          Dim strLine As String
          strLine = sr.ReadLine()
          ListBox1.Items.Add(strLine)
          sr.Close()
        End Using
      Next
    End If
Come si nota, la creazione di un'applicazione non è affatto più difficile di quella di uno script.
È possibile controllare l'applicazione premendo F5 (o premendo il pulsante Avvia debug sulla barra degli strumenti di debug). Facendo clic sul pulsante e selezionando uno o più file nella finestra di dialogo Apri, i risultati sono simili a quanto mostrato nella Figura 5.
Figura 5 Prime righe dei file selezionati visualizzati nella casella di riepilogo
Quando l'applicazione viene eseguita nel modo selezionato, scegliere l'opzione per la generazione di ReadFiles (o il nome del progetto) dal menu Genera. Ciò consente di creare un file .exe denominato ReadFiles.exe che è possibile eseguire come qualsiasi altra applicazione e può essere distribuito ai propri utenti.
Sappiamo che questa può non sembrare la strada diretta per utilizzare la finestra di dialogo Apri. Ma se si considera che niente di tutto ciò sarebbe possibile scrivendo uno script come Windows Vista, allora, la scrittura di una semplice applicazione è solo un piccolo prezzo da pagare. Proprio come essere disposti a pagare una somma irrisoria pur di arrivare a destinazione percorrendo l'autostrada: può essere alquanto scocciante, ma alla fine si riesce a raggiungere la meta.
Un ulteriore vantaggio dell'utilizzo di Visual Basic è quello di lavorare con uno strumento più potente di VBScript e ciò consente di creare facilmente delle applicazioni con un'interfaccia utente migliore; si tratta di un grande vantaggio. Gli amministratori di sistema utilizzeranno Visual Basic in molti altri modi.
Ricordatevi, non è necessario imparare nuovamente a guidare per utilizzare la nuova corsia di pedaggio; è solo necessario abituarsi al fatto che le automobili che sono davanti si stanno muovendo. In modo simile, se si conosce VBScript non si devi imparare daccapo una lingua completamente nuova per utilizzare Visual Basic, è solo necessario abituarsi all'idea di poter fare molto più.
Il rompicapo di script del Dottor Scripto
La sfida mensile che verifica non solo le vostre capacità di risoluzione dei puzzle, ma anche le competenze di scripting.

Agosto 2008: Alfabeto di scripting
Nel puzzle di questo mese, è necessario inserire le lettere da A a Z negli spazi vuoti per ottenere una parola in qualche modo collegata allo script. Ogni lettera (da A a Z) deve essere utilizzata una sola volta e le lettere non sono visualizzate in ordine alfabetico. La lettera può essere inserita all'inizio, alla fine o in una posizione qualsiasi all'interno della parola. Ad esempio, nella prima riga abbiamo inserito la lettera C per completare la parola SCRIPT:

RISPOSTA:
Il rompicapo di script del Dottor Scripto
Risposta: Alfabeto di scripting, agosto 2008

Gli Scripting Guy 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.


The Desktop Files Servizi di distribuzione Windows 101
Wes Miller

Indice
WDS in Windows Server 2003
WDS in Windows Server 2008
La scelta
Considerazioni
Introduzione a WDS
Immagini di acquisizione
Acquisizione 101
Migrazione di immagini
Installazione automatica
L'articolo del mese scorso passava in rassegna la storia degli strumenti di distribuzione basati su PXE (Pre-Boot eXecution Environment) forniti da Microsoft. Questo mese, affronteremo i WDS (Servizi di distribuzione Windows) discutendo nello specifico delle versioni fornite con Windows Server 2003 e della versione aggiornata fornita con Windows Server
2008. In seguito, vi fornirò tutte le informazioni essenziali per utilizzare i WDS.
I WDS possono essere visti anche come RIS (Servizi di installazione remota) riscritti. Anche se alcuni dei componenti principali sono gli stessi (e in effetti la versione dei WDS su Windows Server® 2003 presenta una modalità legacy che è funzionalmente identica ai RIS) l'effettiva infrastruttura dei WDS eseguita al 50 per cento in modalità nativa e al 50 per cento in modalità mista è nuova di zecca.

WDS in Windows Server 2003
Al momento del rilascio di Windows Vista® sono stati offerti contemporaneamente anche i WDS. Questo passaggio era necessario perché l'installazione di Windows Vista è stata completamente riprogettata utilizzando l'architettura WIM (Windows® Imaging Format), cosa che ha reso i RIS incapaci di distribuire Windows Vista (e, alla fine, anche Windows Server 2008). I WDS sono poi stati messi a disposizione sotto forma di download fuori banda per i clienti con Windows Server 2003 SP1. Con il SP2, i RIS sono stati completamente soppiantati dai WDS.
È bene tenere a mente che, poiché i WDS in Windows Server 2003 possiedono una compatibilità completa con le versioni precedenti, non è necessario passare alla modalità nativa durante l'installazione dei WDS sui sistemi Windows Server 2003 SP2. È possibile proseguire in modalità legacy, con esecuzione funzionale identica a quella di un server RIS, o in modalità mista, consentendo l'avvio di WDS o RIS in alternativa.
Oltre alla capacità di distribuzione di Windows Vista e Windows Server 2008, i WDS in modalità nativa o nella metà nativa della modalità mista possiedono diverse funzionalità aggiuntive. Invece che utilizzare il motore di installazione di Windows in modalità kernel e il nucleo di installazione tradizionale di cui abbiamo parlato il mese scorso (technet.microsoft.com/magazine/cc645015), i WDS utilizzano Windows PE come ambiente di preinstallazione bootstrap e distribuiscono immagini basate su WIM anziché utilizzare installazioni basate su RIPrep o RISetup. Questo rende la distribuzione più veloce, semplice e affidabile.
Inoltre, decadono molte delle limitazioni citate il mese scorso, come l'esigenza di utilizzare caratteri ANSI (American National Standards Institute), dato che Windows PE è in grado di visualizzare le stesse serie di caratteri come installazione completa di Windows.
In più, i WDS hanno guadagnato qualche strumento che sfortunatamente non era incluso in RIS: uno snap-in Microsoft® Management Console (MMC) per assistere la gestione e uno strumento di configurazione riga di comando estremamente completo che consente funzionalità di configurazione molto più avanzate di quelle dei RIS.
Poiché entrambe le modalità legacy e mista permettono di distribuire immagini di Windows basate su RISetup e RIPrep, forse è necessario tenere a mente che, storicamente, i RIS utilizzavano un componente detto Single Instance Storage (SIS) per ottimizzare l'archiviazione dell'immagine sul disco. SIS, successivamente fornito come parte di Windows Storage Server 2003, utilizzava un servizio denominato Groveler eseguito in background sui server RIS e WDS che cerca i file identici. Se le dimensioni e l'hash di qualsiasi file corrispondono, SIS ne salva una copia nella sua cartella dell'archivio comune SIS e crea poi un collegamento reale a ciascuna delle versioni originali trovate.
SIS è progettato per avere un impatto minimo sull'uso del processore e contemporaneamente consentire significativi risparmi di spazio di archiviazione. Si trattava di un concetto innovativo, utilizzato per primo dai RIS e poi su larga scala sulla piattaforma Windows Server. Ma SIS non sarà più utilizzato per i WDS da ora in avanti.
Poiché i WDS su Windows Server 2003 eseguiti in modalità nativa, e sempre su Windows Server 2008, utilizzano immagini WIM per l'installazione, essi possiedono una propria compressione e, cosa ancora più importante, un proprio modello di archiviazione file di istanza singola e non necessitano affatto di SIS. L'archivio immagini sostituisce il modello di archiviazione utilizzato da RIS con un nuovo design per WDS basato su WIM. Ulteriori informazioni su SIS sono disponibili all'indirizzo go.microsoft.com/fwlink/?LinkId=120302.

WDS in Windows Server 2008
In Windows Server 2008, i WDS sono diventati sia soprainsieme, sia sottoinsieme della funzionalità in Windows Server 2003. Ora sono in grado di distribuire immagini tramite multicast nella modalità autonoma utilizzando il server trasporto, un nuovo server TFTP (Trivial File Transfer Protocol) con prestazioni migliori, supporto per sistemi x64 basati su EFI (Extensible Firmware Interface) e report migliorato della metrica di installazione. Tratteremo questi aspetti nell'articolo del mese prossimo.
Si tenga presente che esiste una funzionalità dei WDS in Windows Server 2003 che è stata eliminata in Windows Server 2008: il supporto dell'installazione legacy. La capacità di distribuire le immagini RISetup/RIPrep o di utilizzare la selezione del sistema operativo RIS legacy per avviare l'installazione non è più disponibile.

La scelta
Una delle domande più frequenti che mi hanno posto dal rilascio di Windows Server 2008 è: "Quale versione dei WDS è necessario utilizzare"? La risposta dipende dal fatto che si distribuiscano o meno versioni di Windows precedenti a Windows Vista e, in tal caso, dalla disponibilità al passaggio da RISetup e/o da immagini basate su RIPrep all'utilizzo esplicito di un'installazione basata su WIM.
I WDS, anche in Windows Server 2008, sono in grado di distribuire Windows fino a coprire Windows 2000 se in un'immagine WIM e possono farlo utilizzando il multicast. Così, se si sta passando da RIS a WDS proprio ora e si sta valutando l'opzione Windows Server 2008 per la propria infrastruttura e se si è disposti a eseguire la migrazione da immagini basate su RIS a immagini basate su WDS, allora la migrazione a WDS in Windows Server 2008 potrebbe avere senso.
È possibile eseguire la migrazione da RIS a WDS anche sul sistema Windows Server 2003, cosa che accade essenzialmente quando si installa SP2 con passaggio alle immagini basate sui WDS. In seguito, baserà effettuare l'aggiornamento a WDS per Windows Server 2008 ed è fatta.
Questo non è però il modello che consiglio. Come per molte versioni di Windows Server precedenti al 2008, Microsoft consiglia di eseguire la migrazione (piuttosto che effettuare l'aggiornamento sul posto) da una versione di Windows Server all'altra.
E come ho affermato prima, prendere in considerazione le versioni x64 di Windows Server 2008 è probabilmente molto più sensato nell'infrastruttura reale di quanto non lo fossero le versioni x64 di Windows Server 2003. Se si decide comunque di effettuare quel passaggio, eseguire una migrazione da server a server dei WDS su Windows Server 2003 a Windows Server 2008 sarà relativamente facile e molto più affidabile rispetto a un aggiornamento sul posto.

Considerazioni
Ecco alcuni punti da tenere a mente per lavorare sulla distribuzione WDS. Non si tratta di requisiti nuovi per WDS (molti valevano anche per i RIS), ma è bene tenerne conto nella creazione di un singolo server WDS o di un'intera infrastruttura:
Privilegi Sono due gli elementi principali da ricordare nella gestione di un server WDS. È necessario autorizzare un server WDS in Active Directory® proprio come si faceva con i RIS. Per farlo, bisogna essere amministratori di dominio nel dominio radice della foresta, essere amministratori dell'organizzazione o avere ricevuto un'apposita delega per i relativi privilegi. Inoltre, bisogna essere anche amministratori di dominio per amministrare il server WDS e naturalmente amministratori del server WDS stesso.
Virtualizzazione Quando si esegue un'istanza di Windows Server 2003 o Windows Server 2008 virtualizzata da Microsoft Virtual PC o Virtual Server e si comunica con un PC client sulla stessa installazione di Virtual PC o Virtual Server, potrebbe verificarsi una race condition all'avvio di PXE che provoca un client molto lento o potenzialmente bloccato. Si consiglia di virtualizzare solo i client o solo i server, ma non entrambi, soprattutto sullo stesso sistema host. Personalmente, sconsiglierei la virtualizzazione di un server WDS per la produzione, principalmente in considerazione del prossimo punto.
Altri servizi I WDS, come i RIS, non interagiscono sempre bene con gli altri servizi di produzione. In particolare, ho osservato problemi con RIS/WDS in esecuzione su un sistema di produzione che esegue anche Microsoft Exchange Server, Systems Management Server (SMS) e System Center Configuration Manager (SCCM).
In genere consiglio di lasciare ai WDS l'unico ruolo sul server se lo si utilizza per la produzione per più di un client. Questo concetto non è valido solo per i WDS: è necessario ponderare attentamente se mescolare o meno i ruoli di prodotti Windows Server e testarli prima della distribuzione.
Collegamenti a bassa o elevata latenza Come i RIS, i WDS non sono pensati per essere utilizzati con connessione a larghezza di banda ridotta o con latenza elevata come i collegamenti satellitari; l'handshake di PXE potrebbe essere problematico e lo scaricamento di immagini sarà probabilmente molto lento, se non addirittura impossibile.

Introduzione a WDS
Maggiori informazioni sui WDS

  • Guida dettagliata per WDS in Windows Server 2003
  • Guida dettagliata per servizi di distribuzione Windows (Windows Server 2008)
  • Distribuzione e gestione dell'aggiornamento WDS su Windows Server 2003
  • Documentazione per i Servizi di distribuzione Windows in Windows Server 2008
  • Riferimento tecnico: Servizi di distribuzione Windows (Windows Server 2008)
Per iniziare, bisogna decidere se si intende utilizzare WDS su Windows Server 2003 o Windows Server 2008. Se si utilizza Windows Server 2003, consiglio di iniziare con SP2 nel quale i WDS sono contenuti in modalità nativa come componenti facoltativi (in sostituzione dei RIS) invece di utilizzare SP1 e il download facoltativo precedentemente disponibile dei WDS contenuto nel Windows Automated Installation Kit (WAIK).
Per entrambe le versioni di Windows Server è bene creare un proprio sistema server. Utilizzare una scheda di interfaccia di rete (NIC) di alta qualità da almeno 100 Mbps o superiore. Evitare il gruppo della scheda di interfaccia di rete (NIC) perché in questo caso l'infrastruttura PXE di WDS potrebbe risultare problematica. Se si utilizza Windows Server 2008, è possibile installare i WDS sia su Server Core, sia sull'installazione completa di Windows Server 2008.
I WDS sono installati su Windows Server 2003 come componenti facoltativi (come accadeva per i RIS). Possono essere installati durante l'installazione del sistema operativo o in un secondo momento da Installazione applicazioni | Installazione componenti di Windows (oppure eseguendo sysocmgr.exe dalla riga di comando). I WDS sono installati in Windows Server 2008 come Ruolo e possono essere installati tramite la configurazione guidata iniziale (fare clic su Aggiungi ruoli | Avanti | quindi scegliere Servizi di distribuzione Windows), tramite Server Manager (stessi passaggi della configurazione guidata iniziale) o dalla riga di comando eseguendo ServerManagerCmd –install WDS.
Una volta installati i WDS è necessario configurarli. Dal menu Start di Windows, andare a Strumenti di amministrazione e selezionare Servizi di distribuzione Windows. Quando parte MMC, fare clic con il pulsante destro del mouse sul proprio server e selezionare "Configura server" dal menu per avviare la configurazione guidata.
Se si esegue l'installazione su Windows Server 2003 e l'aggiornamento di un server RIS esistente, è opportuno specificare la directory RemoteInstall esistente in modo che l'installazione legacy possa essere aggiornata alla modalità mista. In questo caso, assicurarsi che la directory RemoteInstall non si trovi sulla partizione di sistema, cosa che potrebbe pregiudicare le prestazioni.
La Figura 1 mostra la console WDS su Windows Server 2008 prima che la configurazione guidata sia stata completata. La Figura 2 mostra la Pagina di benvenuto per la configurazione guidata dei WDS su Windows Server 2008. La Figura 3 mostra il passaggio di configurazione PXE della configurazione guidata dei WDS. In questo passaggio è possibile specificare se il server dovrà rispondere a qualsiasi client (utile per la creazione iniziale), solo ai computer client noti (quelli pre-installati nella Active Directory) o a tutti i client (e se dovrà tenere in sospeso facoltativamente tutti i client sconosciuti permettendo a un amministratore di scegliere la linea di condotta da tenere).
Figura 1 WDS installati ma non ancora configurati
Figura 2 Configurazione guidata dei WDS
Figura 3 Scelta dei criteri di risposta per il server PXE
La Figura 4 mostra un server WDS completamente configurato su Windows Server 2008 (senza immagini installate) con la pagina delle Proprietà aperta. Se si utilizza un server che è già un server DHCP (Dynamic Host Configuration Protocol), assicurarsi di impostare l'opzione DHCP 60 su PXEClient e di impostare WDS su Non eseguire l'ascolto sulla porta 67. Questo consentirà al server WDS di ignorare un passaggio durante il processo di rilevamento di PXE (come spiegato nell'articolo del mese scorso).
Figura 4 Server WDS completamente configurato su Windows Server 2008
Una volta completata la procedura guidata, è possibile aggiungere nuove immagini. Possono essere aggiunti due tipi di immagini a un server WDS con esecuzione in modalità mista o nativa:
  • Immagini d'avvio: si tratta delle immagini contenenti Windows PE 2.x, generalmente copiate dal DVD di installazione di Windows Server 2008 o Windows Vista SP1. È opportuno utilizzare il file \Sources\Boot.wim da Windows Server 2008 per le immagini d'avvio (anche se si sta distribuendo Windows Vista o un sistema operativo legacy) quando si utilizza il multicast. Le immagini d'avvio sono generalmente Windows PE, Windows Setup.exe e altre dipendenze.
  • Immagini di installazione: si tratta delle immagini del sistema operativo Windows, generalmente il file \Sources\Install.wim di Windows Vista o Windows Server 2008.
Per aggiungere un'immagine d'avvio predefinita o un'immagine di installazione predefinita, i passaggi sono praticamente gli stessi. Entrambi i processi iniziano facendo clic con il pulsante destro del mouse sul tipo di immagine e scegliendo di aggiungere un'immagine di quel tipo.
Per un'immagine di installazione è necessario specificare un nome per il gruppo di immagini (dato che un WIM predefinito sul DVD Windows contiene più di un tipo di sistema operativo). Scegliere poi il file boot.wim o install.wim appropriato che si desidera aggiungere e fare clic su Apri. Per le immagini di installazione, si può rimuovere il segno di spunta da qualsiasi immagine di volume (immagine del sistema operativo) che non si desidera aggiungere al server WDS. Infine, è possibile installare con PXE i client utilizzando queste immagini predefinite.

Immagini di acquisizione
Per creare immagini del sistema operativo personalizzate, creare un'immagine di acquisizione (un'immagine Windows PE progettata per consentire l'acquisizione di un sistema Windows come immagine WIM). Il modo più facile per far ciò è utilizzare un'immagine boot.wim installata in precedenza.
Fare clic con il pulsante destro del mouse sull'immagine desiderata, quindi su Crea immagine d'avvio di acquisizione. Specificare il nome e la descrizione da utilizzare per l'immagine e la posizione in cui salvare una copia locale del file .wim se si verificano problemi di connettività di rete durante la distribuzione dell'immagine di acquisizione. Quindi, seguire la procedura guidata e fare clic su Fine.
Poi, fare clic con il pulsante destro del mouse sulla cartella Immagine d'avvio in WDS MMC e poi su Aggiungi immagine d'avvio. Come prima, seguire le istruzioni della procedura guidata. Alla fine della procedura, si è pronti per acquisire un'immagine di installazione di Windows.

Acquisizione 101
Prima di acquisire un'immagine del sistema operativo è ovviamente necessario installare Windows e assicurarsi che contenga tutte le applicazioni, le personalizzazioni e gli aggiornamenti desiderati. Successivamente, è necessario eseguire Sysprep sul sistema; è possibile acquisire immagini di installazione Windows solo da sistemi preparati con Sysprep. Bisogna quindi specificare una posizione locale valida per salvare la nuova immagine (ed evitare possibili danneggiamenti) e un'estensione file *.wim.
Dopo avere configurato il sistema e copiato la versione corretta di sysprep.exe nel sistema, attenersi ai passaggi indicati di seguito:
  1. Dal prompt dei comandi che è sul computer di riferimento, modificare la directory in cui si trova sysprep.exe.
  2. Avviare Sysprep (è possibile anche facendo doppio clic su sysprep.exe e specificando manualmente le opzioni). Dai computer che eseguono Windows Vista o Windows Server 2008, eseguire il comando sysprep /oobe /generalize /reboot. Sui computer con versioni precedenti di Windows eseguire sysprep -mini -reseal -reboot.
  3. Dopo aver riavviato il computer, effettuare l'avvio con PXE (il processo potrebbe variare a seconda del sistema client).
  4. Dal menu di avvio, scegliere l'immagine di acquisizione WDS e fare clic su Avanti.
  5. Scegliere l'unità, il nome e la descrizione dell'immagine.
  6. Come menzionato, saranno visibili soltanto i sistemi preparati con Sysprep. Si tratta di un caratteristica insita che non è possibile aggirare.
  7. Fare clic su Sfoglia e selezionare la cartella locale in cui memorizzare l'immagine di installazione acquisita. La posizione scelta può essere un'unità di rete mappata.
  8. Selezionare Carica immagine in un server WDS.
  9. Digitare il nome del server WDS e fare clic su Connetti.
10. Dall'elenco Gruppo immagini, scegliere il gruppo immagini in cui memorizzare l'immagine e poi fare clic su Fine.
Questa immagine è ora pronta per essere distribuita dal server WDS. C'è un aspetto che i veterani dei RIS potrebbero avere notato: non ho acquisito quest'immagine di Windows dal vivo. WDS richiede che il sistema venga acquisito non in linea.
RIPrep nei RIS era in grado di effettuare l'acquisizione (o meglio, richiedeva l'acquisizione) di un sistema in linea, ma il processo era estremamente fragile. Credo invece che il processo di acquisizione per WDS sia abbastanza facile e certamente più solido.

Migrazione di immagini
Dopo avere utilizzato i RIS per qualche tempo, certamente si disporrà di una certa quantità di immagini. Per le immagini basate su RISetup (un'installazione codificata) siamo arrivati al capolinea. È tuttavia possibile eseguire la migrazione delle immagini RIPrep a immagini WDS basate su WIM. I WDS consentono infatti anche di eseguire la migrazione delle immagini attraverso WDSUtil (ne parleremo più dettagliatamente il prossimo mese).
Consiglio, generalmente, di farlo soltanto se è stata investita una quantità significativa di tempo in un'immagine che non si vuole perdere. Il processo funziona piuttosto bene, ma ho sentito parlare di alcuni errori durante la conversione e ciò di solito significa dover ricostruire l'immagine daccapo.

Installazione automatica
I passaggi analizzati precedentemente, consentono di creare un'immagine che può essere installata manualmente. Per un'installazione più automatizzata o completamente automatica è necessario utilizzare due file di installazione automatica. I WDS in sé richiedono un file di risposta (unattend.xml, memorizzato nella directory \RemoteInstall\WDSClientUnattend del server WDS) che automatizza il processo di installazione WDS. Il secondo file è un vero e proprio file di installazione automatica dell'immagine. Per Windows Vista o sistemi operativi successivi, si tratta di un file unattend.xml. Per le immagini di Windows precedenti, è un file sysprep.inf memorizzato in una struttura di directory $OEM$ o in \Unattend per ogni directory dell'immagine. Questo file è utilizzato per automatizzare l'installazione effettiva di Windows una volta completati i WDS.
Per creare un file di installazione automatica WDS, creare un file unattend.xml per WDS utilizzando il WAIK. Copiare questo file nella directory RemoteInstall o in una directory secondaria. Fare clic con il pulsante destro del mouse sull'immagine di installazione per cui si desidera utilizzare il file di installazione automatica, quindi fare clic su Proprietà. Nella scheda Client, scegliere Abilita installazione automatica e fornire il file unattend.xml specificato prima.
Per creare il file di installazione automatica immagine per immagini delle versioni precedenti a Windows Vista, copiare il file sysprep.inf nella directory $OEM$ dell'immagine, ad esempio: D:\RemoteInstall\Images\Windows XP\SP2\$OEM$\$1\sysprep\sysprep.inf. Per immagini di Windows Vista, specificare l'immagine da associare, fare clic su Proprietà e poi, dalla scheda Generale, fare clic su Consenti che l'immagine venga installata in modalità automatica. Specificare poi il file unattend.xml da utilizzare per l'installazione.
Siamo giunti a metà strada. Quest'articolo è pensato per fornire le informazioni essenziali sui WDS. Il prossimo mese, verranno forniti ulteriori dettagli su WDSUtil, le caratteristiche specifiche dell'archivio immagini e il multicast. Poi completeremo la serie con una descrizione approfondita sulle modalità e i motivi per cui prendere in considerazione la creazione di una soluzione di distribuzione personalizzata in aggiunta a WDS. Nel frattempo è possibile consultare l'approfondimento "Maggiori informazioni su WDS" che accompagna questo articolo.

Wes Miller è un Senior Technical Product Manager presso CoreTrace (www.CoreTrace.com) ad Austin, in Texas. In passato ha lavorato per Winternals Software e per Microsoft in qualità di Program Manager. È possibile contattarlo all'indirizzo technet@getwired.com.


Security Watch Password e carte di credito - Parte 2
Jesper M. Johansson

Indice
Processo di pseudo accesso a più fattori
Problemi con componenti aggiuntivi del browser
L'autenticatore non deve mai cambiare
Passare a password meno sicure
Ignorare lo pseudo accesso a più fattori
Problemi con password compromesse
Alcuni vantaggi
Immagini utilizzate per ingannare gli utenti
Aprire o non aprire
Fornire comunicazioni protette
È una questione di privacy
Benvenuto nella seconda delle tre parti di questa serie. Lo scopo di questa serie di articoli è dare uno sguardo a come talvolta gli esperti informatici confondono gli utenti piuttosto che aiutarli ad affrontare i problemi relativi alla sicurezza. Nell'edizione di luglio 2008 di TechNet Magazine, ho parlato di alcuni consigli sulle questioni di sicurezza che risultano inesatti e impraticabili. Ho inoltre discusso dei flussi di lavoro relativi alle fasi di accesso che appaiono confusionari. (Qualora non si fosse letta la prima parte, essa è ancora disponibile a questo indirizzo
technet.microsoft.com/magazine/cc626076.). Mi sono soffermato su due delle cause che generano confusione negli utenti e che costituiscono minacce per la loro sicurezza informatica. Per prima cosa ho parlato di quei consigli che vengono spesso dati e che si farebbe bene a ignorare. In secondo luogo ho discusso quei flussi di lavoro relativi ai processi di accesso che risultano poco chiari.
In questa parte continuerò quella discussione, portando altri esempi reali tratti dal mondo della protezione degli utenti. L'ultima parte di questa serie, che conterrà una vera e propria "chiamata alle armi" rivolta ai professionisti mondiali della sicurezza, verrà pubblicata nel prossimo numero di TechNet Magazine.

Processo di pseudo accesso a più fattori
Nell'ottobre 2005, il Federal Financial Institutions Examination Council (organo con compiti simili alla CONSOB) ha pubblicato le linee guida sulle modalità di autenticazione utilizzate nei servizi di banking online (vedere www.ffiec.gov/press/pr101205.htm). Il tempo a disposizione per l'implementazione di quelle linee guida era stato fissato a 14 mesi e le istituzioni finanziarie americane si sono date subito da fare per cercare di mettersi in linea con quelle indicazioni.
La maggior parte delle istituzioni non fu in grado di rispettare quella scadenza. Quelle che invece riuscirono in qualche modo a osservare tali indicazioni, applicarono delle misure il cui unico effetto era quello di rispettare le nuove normative. In altre parole, applicarono delle misure che in nessun modo garantivano ai consumatori un maggiore livello di sicurezza (semplicemente delle "misure di facciata"). Tra gli esempi di soluzioni inutili più interessanti, ci sono sicuramente quelli che riguardano l'autenticazione, solo apparentemente, a più fattori.
Ad esempio, prendiamo la tecnologia che misura la velocità di digitazione della password da parte di un utente. Utilizzata in un sito Web, questa soluzione si presenta esattamente come una finestra di dialogo di accesso tradizionale. Tuttavia, questa finestra di dialogo è costituita da un oggetto Adobe Flash.
L'oggetto di Flash registra la velocità con la quale l'utente digita e altre caratteristiche, come ad esempio per quanto tempo è stato premuto un tasto o l'intervallo esatto intercorso fra la digitazione di un tasto e un altro. Questi dati vengono inoltrati al sito Web insieme alla password e confrontati con i valori in archivio. Se la velocità rientra entro certi limiti memorizzati e la password digitata è quella corretta, l'accesso viene eseguito. L'idea che sta alla base di questa pratica è permettere al sito di utilizzare un metodo di accesso pseudo biometrico, senza la necessità di installare componenti hardware di terze parti da parte dell'utente.
Prenderò appunto questo come esempio di pseudo autenticazione a più fattori. Non si tratta infatti di un vero accesso a più fattori. Per essere tale essa dovrebbe prevedere la misurazione di almeno due dei seguenti fattori standard:
  • Qualcosa che l'utente possiede (ad esempio una smart card)
  • Qualcosa che l'utente sa (ad esempio una password)
  • Qualcosa che l'utente possiede naturalmente (ad esempio le impronte digitali)
Piuttosto che sfruttare fattori multipli durante l'accesso, metodi come quello descritto in precedenza registrano più caratteristiche che sono tuttavia derivate da un solo parametro: la password. E quindi utilizzano questi parametri aggiuntivi per cercare di definire una caratteristica innata dell'utente.
La tecnologia utilizzata per lo pseudo accesso a più fattori presenta molti difetti che. Se presi tutti insieme, tali fattori rendono la tecnologia rendono ampiamente inefficace contro i problemi che si pone di risolvere.

Problemi con componenti aggiuntivi del browser
I sistemi di pseudo accesso a più fattori sfruttano alcuni componenti aggiuntivi del browser per eseguire la complessa elaborazione richiesta dal lato client. Tutti i software, si sa, contengono dei bug e alcuni di questi possono esporre l'utente ad alcune vulnerabilità. Queste possono realmente costituire un problema quando il software è difficile da aggiornare e l'utente non è sicuro di avere installato un determinato aggiornamento.
I componenti aggiuntivi del browser presentano entrambi questi difetti: sono difficili da aggiornare e non comunicano all'utente se la versione installata è la più recente o meno. Di conseguenza, l'utente è costretto a esporre, forse inutilmente, determinate porzioni di software su Internet.
In alcuni casi, per mantenere il componente aggiuntivo aggiornato è necessario visitare regolarmente il sito Web del produttore. È scontato dire che questo non avviene per la maggior parte degli utenti. Qualsiasi sistema che, al fine di offrire funzionalità di sicurezza, espone altri software aggiuntivi dell'utente su Internet, dovrebbe essere maneggiato con molta attenzione.

L'autenticatore non deve mai cambiare
La caratteristica "che l'utente possiede naturalmente" presenta un tratto, anche un difetto se si vuole, che non ha impatto sugli altri due fattori. Mentre è possibile modificare una password (qualcosa che l'utente sa) e produrre nuovi dispositivi di sicurezza (qualcosa che l'utente possiede), il numero di autenticatori biometrici utilizzabile è decisamente limitato. Per le impronte digitali, ad esempio, generalmente esistono dieci possibili varianti. Inoltre, se capita di perdere uno di questi autenticatori, è generalmente impossibile sostituirlo.
Vediamo adesso come quanto appena detto si applica all'esempio dell'accesso con pseudo autenticazione a più fattori. I criteri di misurazione raccolti sfruttando altri fattori non possono essere facilmente sostituibili o modificabili. Sicuramente, dopo aver modificato la password, l'utente la digiterà in modo differente. Tuttavia, la maniera in cui normalmente preme i tasti rimarrà immutata. È proprio su questo che si basa la tecnica appena discussa. Se questi criteri di misurazioni potessero essere compromessi, allora sarebbe possibile sintetizzarli. Un utente malintenzionato potrebbe almeno essere in grado di acquisire queste caratteristiche e riprodurle.

Passare a password meno sicure
È sempre bene utilizzare password lunghe e cambiarle di frequente. Come anche discusso nella prima parte di questa serie, è consigliabile (contrariamente a quanto qualcuno potrebbe consigliare) registrare le proprie password, sia beninteso, in modo protetto. Tuttavia, dovere digitare una password manualmente potrebbe scoraggiare l'uso di queste pratiche. Una password lunga è infatti più difficile da digitare, mentre una che sia registrata risulta di gran lunga più utile quando è possibile copiarla e incollarla. Uno dei migliori modi per memorizzare cento o più password è sicuramente quello di utilizzare un software come Password Safe (disponibile su sourceforge.net/projects/passwordsafe). Con uno strumento come questo, è possibile generare password assolutamente casuali, memorizzarle in formato crittografato e incollarle direttamente nelle finestre di dialogo di accesso. Di fatto, con uno strumento del genere, non è neppure necessario che l'utente conosca la propria password.
Ma il guaio è proprio questo: è impossibile misurare la velocità di digitazione, a meno che non sia proprio l'utente a digitarla. E se è necessario immettere la password all'interno di un oggetto che misura la velocità di digitazione, la tecnica di gestione delle password appena descritta potrebbe risultare inadeguata. Digitare correttamente una password di 15 caratteri completamente casuale non è certo semplice. Di conseguenza, in casi come questi gli utenti scelgono generalmente di utilizzare una password più semplice. Una password completamente casuale di 15 caratteri è certamente più sicura di una più breve, se pur accoppiata a un sistema di pseudo autenticazione a più fattori.
A conti fatti, la pseudo autenticazione a più fattori, se usata da sola, induce gli utenti a utilizzare password meno sicure. Sfortunatamente, come si vedrà a breve, soddisfare gli utenti che utilizzano tecniche di gestione delle password annulla praticamente qualsiasi protezione offerta dai sistemi di pseudo autenticazione a più fattori.

Ignorare lo pseudo accesso a più fattori
Anche se un sito fornisce un sistema di pseudo accesso a più fattori, esso deve sicuramente supportare una modalità alternativa. Innanzi tutto perché pochi siti possono pretendere che tutti gli utenti dispongano di strumenti aggiuntivi per poter accedere al sito. Alcuni utenti (alcuni autori di TechNet Magazine, ad esempio) si rifiutano categoricamente di installare questo genere di software.
La velocità di digitazione può inoltre variare per svariati motivi e i siti devono certamente prevedere questa eventualità. Consideriamo ad esempio che un utente si sia slogato polso e di conseguenza la sua velocità di digitazione è temporaneamente alterata. Come potrà accedere al sito se questo analizza la sua velocità e pensa che sia tratti di una persona diversa? Se si trattasse di una lesione permanente, l'utente potrebbe certamente reimpostare i valori della velocità di digitazione. Tuttavia, nel caso di una lesione temporanea, l'utente non vorrà probabilmente reimpostare i valori memorizzati, presupponendo che la velocità di digitazione ritornerà alla normalità.
Infine, non tutti gli utenti sono in grado di utilizzare i sistemi di pseudo autenticazione a più fattori. Per fare un esempio, consideriamo un utente disabile che interagisce col computer attraverso un'interfaccia di riconoscimento vocale. L'utente potrebbe non essere in grado di immettere le informazioni di accesso nella finestra di dialogo, se questa non prevede la possibilità di immissione automatica. In casi come questi è molto probabile che per legge sia necessario offrire un sistema alternativo per garantire l'accesso agli utenti disabili.
Il modo più semplice per ovviare a questo genere di casistica è quello di supportare l'autenticazione standard basata su password.

Problemi con password compromesse
I sistemi di pseudo autenticazione a più fattori si prefiggono di risolvere i vari problemi legati all'autenticazione basata su password. Tuttavia, questi sistemi non sono in grado di fermare tutte le tecniche utilizzate per compromettere le password. Ci sono cinque metodi principali utilizzati per compromettere un sistema di autenticazione con password, dove per "compromesso" si intende che un utente malintenzionato ottiene e utilizza la password di un altro utente:
  • Indovinare la password
  • Utilizzare un keystroke logger
  • Effettuare degli attacchi di phishing
  • Chiedere all'utente
  • Entrare in qualsiasi sistema che memorizza la password o un hash di essa
Quello di indovinare la password non è più un metodo di attacco particolarmente comune tra i pirati ed è stato surclassato dai keystroke logger e dagli attacchi di phishing. Questa tecnica è soltanto in parte efficacemente contrastata dalla pseudo autenticazione a più fattori. È poco probabile che cercando di indovinare la password si riesca a compromettere un sistema di pseudo autenticazione a più fattori, se non altro perché l'utente malintenzionato oltre alla password deve individuare anche la velocità di digitazione. Sebbene sia teoricamente possibile sintetizzare i criteri di misurazione della velocità di digitazione, questa tecnica viene raramente utilizzata. Infatti utilizzando un attacco di phishing o un keystroke logger è possibile intercettare i dati stessi. Inoltre, se il sistema fornisce anche un'interfaccia di accesso standard basata esclusivamente sulla password, l'utente malintenzionato può sfruttarla per indovinare la password.
E ancora, utilizzando password molto complesse si riduce la possibilità che vengano indovinate da utenti malintenzionati. Se è possibile insegnare agli utenti a utilizzare password complesse, magari anche con l'ausilio di strumenti di gestione, la pseudo autenticazione a più fattori risulta superflua. (Al contrario, password semplici, tipicamente utilizzate con i sistemi di pseudo autenticazione a più fattori, rendono il metodo di individuazione della password una tecnica facilmente praticabile). Quindi, affinché un sistema sia protetto da tecniche per l'individuazione di password, è fondamentale che questo non supporti l'autenticazione basata esclusivamente su password. E, come si diceva in precedenza, questo può essere possibile solamente di rado. In altre parole, se gli utenti utilizzano password più semplici in presenza di sistemi con pseudo autenticazione a più fattori, indovinare le password potrebbe ritornare ad essere un metodo di attacco facilmente praticabile; la pseudo autenticazione a più fattori ridurrebbe quindi il livello di protezione, piuttosto che aumentarlo. È necessario quindi approfondire questo aspetto.
La pseudo autenticazione a più fattori non offre protezione inoltre contro i keystroke logger. Sebbene io non sia a conoscenza di alcun keystroke logger attualmente in uso in grado di acquisire la velocità di digitazione, non ritengo che progettarne uno possa essere un'impresa eccessivamente difficile. Un keystroke logger può essere un particolare hardware posto tra la tastiera e il computer o un software che acquisisce i tasti digitati. In entrambi i casi, il logger ha pieno accesso a tutti i dati utilizzati dal sistema di pseudo autenticazione a più fattori.
Il keystroke logger può infatti accedere a un numero maggiore di dati in quanto i processi di autenticazione vengono eseguiti in modalità di utente. Senza una soluzione protetta che stia tra la tastiera e l'oggetto basato sul Web utilizzato per acquisire la password, non è possibile evitare questo tipo di attacco. Se le soluzioni di pseudo autenticazione a più fattori diventassero abbastanza comuni, sicuramente verrebbero creati keystroke logger del genere.
Analogamente, gli attacchi di phishing non vengono efficacemente contrastati dalla pseudo autenticazione a più fattori. Piuttosto che utilizzare semplicemente una schermata di accesso contraffatta, un utente malintenzionato potrebbe sfruttare un oggetto Flash per acquisire la password e identificare la velocità di digitazione.
Va precisato però che la pseudo autenticazione a più fattori può essere utile nei casi in cui la tecnica utilizzata da un utente malintenzionato mira soltanto a individuare la password. Ad esempio, la maniera più facile per ottenere una password da un utente è quella di chiedere all'utente stesso. Sembra strano, ma questa si è dimostrata essere una tecnica efficace. Molti sono i modi per chiedere una password: di persona, al telefono o infine attraverso messaggi di phishing.
Sicuramente, chiedere a un utente la sua velocità di digitazione sarebbe ben più complesso. Allo stesso modo, se il database delle password di un'azienda viene compromesso, l'utente malintenzionato avrà a disposizione soltanto le password. Ma ancora un volta questi tentativi di attacco potranno essere neutralizzati solo se il sistema non fornisce la possibilità di eseguire l'autenticazione solo con la password.
È doveroso notare inoltre che, se il database delle password è stato compromesso, l'utente malintenzionato ha probabilmente violato il cuore del sistema, in modo ben più grave di quanto sia possibile fare utilizzando una sola, o anche più, password di account utente standard. Quindi, non è affatto giusto cercare di sottovalutare ciò che un utente malintenzionato in possesso di un database di password è in grado di fare.

Alcuni vantaggi
A dire il vero, ci sono un paio di situazioni nelle quali la pseudo autenticazione a più fattori può essere utile (presupponendo che il sistema non fornisca l'opzione di accesso con la sola password). Ad esempio, può essere utilizzato per evitare lo scambio di password. Tuttavia, questo può risultare una limitazione per quei sistemi nei quali più utenti condividono gli account in maniera del tutto legittima, come ad esempio i conti bancari cointestati.
Inoltre, una finestra di dialogo di accesso interattiva e ben progettata (non l'accesso a un sito Web) potrebbe chiedere all'utente di eseguire ulteriori passaggi di autenticazione, nel caso in cui la velocità di digitazione non venga riconosciuta. In questo modo si può fornire un maggiore grado di protezione a un account compromesso in un ambiente estremamente delicato.

Immagini utilizzate per ingannare gli utenti
Uno dei modi migliori per confondere gli utenti è dare loro indicazioni inesatte riguardo la sicurezza. Il più comune è probabilmente quello di visualizzare l'immagine di un lucchetto in una pagina Web, come illustrato in Figura 1. In questa pagina viene persino visualizzata la parola "Secure" con in lucchetto.
Figura 1 Un esempio di uso improprio dell'icona lucchetto, una tendenza preoccupante (fare clic sull'immagine per una ingrandirla)
Come è probabilmente noto ai lettori, visualizzare semplicemente l'immagine di un lucchetto insieme alla parola "Secure" non rende la pagina sicura. Ma purtroppo questa pratica è fastidiosamente diffusa, anche nei siti Web più rispettabili e nel mirino di molti utenti malintenzionati. Il risultato è che molti utenti sono abituati a cercare questi simboli di garanzia della sicurezza nel testo della pagina Web, piuttosto che dove queste icone effettivamente rappresentano una garanzia, cioè nella barra degli indirizzi. (Il Wiki di Web Security Context di W3C contiene un articolo in merito, disponibile all'indirizzo w3.org/2006/WSC/wiki/PadlockIconMisuse)
È spiacevole dovere notare che tuttavia ci sono così tanti esempi dell'uso improprio dei simboli. Da alcune ricerche si evince che gli utenti non sono in grado di identificare i siti Web dannosi anche quando i certificati parlano chiaro (vedere www.usablesecurity.org/papers/jackson.pdf). È un po' come l'abilità di distinguere facilmente l'originale dal contraffatto, anche quando non si ha l'originale a portata di mano. Ma ciò richiede appunto abilità; la visualizzazione di false garanzie di protezione sulle pagine Web ostacola lo sviluppo di questa abilità, poiché gli utenti vengono esposti a informazioni fuorvianti.
Una variante particolarmente fastidiosa di questo tecnica è illustrata nella Figura 2. In questo caso, la pagina che visualizza le informazioni non è in realtà protetta. Se si guarda la barra degli indirizzi, è facile notare che il protocollo indicato è "http". Questo sito utilizza una tecnica di ottimizzazione molto comune: non codifica tutta la pagina che contiene il modulo di accesso, ma soltanto quest'ultimo. L'accesso è protetto, proprio come si dice nella pagina. Questo è vero se diamo per scontato che "protetto" sia sinonimo di "codificato". Tuttavia, e questo è di fondamentale importanza, l'utente non ha modo di verificare dove le credenziali verranno inviate prima di avere effettivamente effettuato l'accesso. Prima dell'invio dei dati, il sito non mostra all'utente nessun certificato di protezione. È un esercizio per aumentare la fiducia, un po' come lasciarsi cadere essendo certi che la persona dietro di noi ci prenderà. Da quando il modulo viene inviato, il danno potrebbe essere già stato fatto.
Figura 2 Simboli di protezione in una pagina non protetta (fare clic sull'immagine per ingrandirla)
Secure Sockets Layer (SSL), il protocollo che fornisce la protezione nel protocollo HTTPS, presenta un duplice scopo. Primo, autentica il server all'utente. Secondo, offre un meccanismo semplice per negoziare una chiave di crittografia che può essere utilizzata tra il client ed il server durante la sessione.
Quando invece è soltanto il modulo di inserimento ad essere codificato, il primo, e più importante, vantaggio appena citato non viene offerto. I siti che sfruttano questo tipo di ottimizzazione utilizzano SSL semplicemente per negoziare le chiavi. Di fatto, potrebbero ottenere questo risultato utilizzando semplicemente un protocollo di negoziazione standard, evitando così i costi e le spese generali per SSL.
Siti come quello illustrato nella Figura 2 non sono rari da trovare. Molti siti forniscono la protezione SSL soltanto per l'invio del modulo, ma non per la codifica del modulo stesso. Tuttavia, questo sito in particolare mostra un tratto ancora più fastidioso. Digitando https://www.<site>.com (notare l'indicatore di protezione https) nella barra degli indirizzi del browser, il sito reindirizzerà l'utente alla versione non SSL del sito! Anche se si cerca di consultare un certificato prima di inviare le credenziali, il sito continuerà a non mostrare alcuna informazione in merito.
Non tutti i siti sono così cattivi, ma ce ne sono molti in giro. E due delle più grandi aziende che forniscono carte di credito negli Stati Uniti sono fra questi. Di fatto, delle tre più grandi aziende che forniscono carte di credito da me usate, soltanto American Express fornisce un certificato sul modulo di accesso. American Express reindirizza persino le richieste HTTP verso HTTPS. Ottimo!
Farò adesso un'ultima considerazione su questo argomento. Ci si potrebbe chiedere perché un sito faccia una cosa del genere. Il motivo è semplicemente economico. Mostrare un certificato richiede la crittografia della pagina e questo implica un maggiore livello di elaborazione. Quindi più computer per elaborare lo stesso numero di richieste. E utilizzare più computer vuol dire aumentare i costi. Sfortunatamente, quando si tratta di scegliere fra protezione della privacy dei clienti e incremento dei profitti, molte organizzazioni optano per la seconda opzione.

Aprire o non aprire
Recentemente ho ricevuto un sorprendente messaggio di posta elettronica dalla mia azienda di assicurazione sanitaria. Chiunque abbia utilizzato un computer negli ultimi dieci anni sa che non si dovrebbero mai aprire allegati a messaggi di posta elettronica indesiderati. Dunque immaginate con quale incredulità ho ricevuto il messaggio nella Figura 3.
Figura 3 Messaggio di posta elettronica contenente un "allegato sicuro" (fare clic sull'immagine per ingrandirla)
Evidentemente avevo inviato una domanda tramite il sito Web della compagnia di assicurazione sanitaria (e l'avevo dimenticato quando il messaggio sospetto mi è arrivato). Questa è la risposta ricevuta. Inizialmente, ho pensato che fosse un tentativo di phishing molto ben costruito. Quando ho capito che si trattava di un messaggio legittimo, mi è venuta la pelle d'oca.
Mi si chiedeva di fare doppio clic sull'allegato per decodificare il messaggio. Gli esperti di sicurezza e gli amministratori di sistemi informatici hanno passato gli ultimi dieci anni cercando di insegnare agli utenti a NON fare doppio clic sugli allegati. E poi ecco che un'azienda (la compagnia con la quale ho un'assicurazione sanitaria, peraltro, non è la sola organizzazione ad utilizzare questa tecnica) che mi chiede di fare clic sull'allegato per garantire la mia protezione. Come dovrebbe comportarsi un utente in una situazione del genere? Cosa si insegna all'utente?
Successivamente, ho utilizzato la funzionalità di anteprima in Microsoft® Office Outlook® 2007 per visualizzarlo. Come si può vedere nella Figura 4, Outlook ha segnalato questo messaggio come possibile attacco e mi ha avvertito di non aprirlo!
Figura 4 Outlook 2007 considera pericoloso il documento protetto (fare clic sull'immagine per ingrandirla)
È triste e ironico al tempo stesso, che una compagnia assicurativa violi i controlli di protezione fondamentali utilizzati dal programma di posta elettronica più usato al mondo. Considerando che quest'azienda non si è neppure scomodata per controllare che la sua soluzione per la protezione fosse in linea con gli standard di Outlook, è legittimo domandarsi cos'altro quest'azienda faccia per proteggere le informazioni private degli utenti. Oppure, per essere più chiari, quali altre soluzioni impiega l'azienda per non essere accusata di non garantire la protezione della privacy dei propri clienti? Questo caso è simile a quanto descritto precedentemente per le istituzioni finanziarie. In casi del genere penso che la soluzione impiegata miri a evitare le accuse, piuttosto che a proteggere veramente i clienti.
Ho voluto controllare cosa l'allegato fosse realmente. È risultato essere un oggetto di controllo Activex®. Per vedere l'allegato, ho dovuto aprirlo in Internet Explorer® e installare l'oggetto. Ciò che mi è stato mostrato è la rassicurante schermata illustrata nella Figura 5. Come si può vedere, sono stati fatti grandi sforzi per mostrare il messaggio sotto forma di una busta; e ha anche un francobollo che garantisce l'affidabilità del messaggio.
Figura 5 Il documento protetto illustra una busta affrancata come "Affidabile" (fare clic sull'immagine per ingrandirla)
Questo tipo di tecnologia è preoccupante per molte ragioni. Primo, consolida un comportamento sbagliato spesso adottato dagli utenti: l'apertura di allegati indesiderati. Secondo, nel corpo del messaggio, si guida l'utente a configurare il sistema in modo che questo apra automaticamente gli allegati. Terzo, di fronte a messaggi contrastanti, quando il messaggio di posta elettronica dice di essere sicuro mentre Outlook sostiene il contrario, la situazione risulta già molto sospettosa. Infine, l'allegato contiene un messaggio inutile che comunica all'utente l'affidabilità della comunicazione. Se l'utente impara a fidarsi di questo tipo di messaggi, basterà poco per iniziare a fidarsi anche di messaggi dannosi con un layout molto simile.

Fornire comunicazioni protette
Il problema che questa tecnologia si prefigge di affrontare è molto importante. Comunicare con i clienti in modo sicuro è difficile. Tuttavia, questa soluzione risulta estremamente complessa. Probabilmente finirà per confondere l'utente e ottenere il risultato opposto a quello che ci si era prefissi: il sistema dell'utente verrà compromesso.
I siti Web progettati a regola d'arte utilizzano adesso un "centro messaggi". In siti del genere, quando l'azienda deve comunicare col cliente, invia un messaggio di posta elettronica che dice qualcosa del genere: "Hai ricevuto un messaggio nel tuo Centro Messaggi. Collegati al nostro sito Web, effettua l'accesso e fai clic sul collegamento al Centro messaggi per leggere il messaggio". Un'altra garanzia è costituita dall'utilizzo di Secure Multipurpose Internet Mail Extensions (S/MIME) per firmare tutti i messaggi di posta elettronica spediti all'utente, così da garantire l'autenticazione della fonte. È bene inoltre se il messaggio non contiene nel suo testo collegamenti del tipo "fare clic sul collegamento". L'utente dovrebbe digitare l'indirizzo del sito dell'azienda con le proprie mani, per assicurarsi di collegarsi al sito desiderato.
Utilizzando un centro messaggi e aggiungendo la firma digitale ai messaggi, un'azienda è a buon punto nella comunicazione sicura con i propri clienti. Tutto ciò che il cliente vede nel processo di comunicazione è autenticato e l'azienda non pubblicizza inefficaci soluzioni di protezione.

È una questione di privacy
Fino ad ora, nei primi due numeri di questa serie, ho parlato di come gli esperti di sicurezza indirizzano gli utenti verso la direzione sbagliata. Garantire la protezione è il nostro lavoro. Ma molte delle soluzioni implementate confondono gli utenti, insegnano loro a fare scelte sbagliate e comunicano una percezione errata della sicurezza. Non dovremmo ricoprire gli utenti con tutte queste informazioni contrastanti.
Come ho fatto notare precedentemente, gli utenti comuni intendono la protezione come la semplice protezione delle password o dei numeri di carta di credito. Desiderano che la tecnologia sia efficiente e affidabile. Sfortunatamente essi devono anche prendere delle decisioni ed è nostro compito assicurarci che siano informati sulle scelte giuste.
Nella parte finale di questa serie, discuterò come alcune delle tecnologie più importanti disponibili sul mercato non sono effettivamente all'altezza delle aspettative. Presenterò inoltre la mia chiamata alle armi. Date quindi un'occhiata alla colonna Security Watch sul numero di settembre 2008.

Jesper M. Johansson è Software Architect, si occupa dei problemi di protezione software e collabora con TechNet Magazine in qualità di redattore. Ha conseguito un Ph.D. in sistemi di gestione delle informazioni e vanta un'esperienza più che ventennale sul tema della sicurezza; è inoltre Microsoft Most Valuable Professional (MVP) per la protezione delle aziende. Il suo ultimo libro è Windows Server 2008 Security Resource Kit.


Sustainable Computing Filtrare il "Greenwashing"
Dave Ohara

Indice
Il bisogno dei numeri
Misurazione dell'utilizzo di energia
Fattore di potenza
Misurazione in fase di produzione
Microsoft EnterpriseEngineering Center
Conclusioni
Esiste un numero consistente di soluzioni e prodotti lanciati sul mercato come verdi, a risparmio energetico e più efficienti. Tutto questo clamore pubblicitario crea confusione nel mercato su ciò che è realmente ecocompatibile. Anche dopo aver valutato le caratteristiche dei vari prodotti, è difficile, se non impossibile, per un professionista IT
determinare quale dispositivo utilizzare quando l'impatto ambientale è l'interesse principale. Durante le dimostrazioni viene sempre evidenziato l'elevato risparmio energetico e ciò porta a pensare che il rendimento degli investimenti (ROI, Return on Investment) giustifichi l'aggiornamento dei dispositivi. Dopotutto, il risparmio energetico dovrebbe portare a una riduzione del costo complessivo di proprietà (TOC, Total Cost of Ownership).
La tendenza di tutte le aziende a contrassegnare praticamente ogni prodotto con l'aggettivo ambientale e sfruttare l'interesse attuale per le soluzioni ecocompatibili ha condotto al concetto di "Greenwashing", termine che si riferisce all'attribuzione ingiustificata di virtù ambientali. Qual è la verità in fatto di risparmio energetico? Non si tratta semplicemente dell'installazione di lampadine a risparmio energetico in casa.
Con l'aumento d'interesse per l'informatica sostenibile e l'espansione del mercato delle apparecchiature che rispettano l'ambiente, molte persone e aziende decidono di avvalersi di computer portatili, desktop e server a consumo ottimale di energia e di utilizzare la virtualizzazione per ridurre i consumi energetici. Eppure, poche organizzazioni eseguono dei controlli in ambito energetico per determinare i veri vantaggi dei prodotti acquistati.
In uno scenario ideale l'ambiente di produzione andrebbe monitorato attivamente, ma ciò può essere molto costoso. Se non si è pronti ad avviare la misurazione in fase di produzione, è tuttavia possibile eseguire almeno i controlli energetici in un momento precedente del processo, nei laboratori dedicati allo studio delle prestazioni e alla valutazione (la maggior parte delle aziende dispone di laboratori o gruppi responsabili per l'esecuzione di verifiche e valutazioni sulle apparecchiature prima di effettuare un acquisto). Nei laboratori è possibile aggiungere la verifica delle prestazioni energetiche come uno dei criteri dei test, tenendo in considerazione i risultati nel momento in cui si prendono delle decisioni in merito all'acquisto, invece di affidarsi completamente ai numeri forniti dai produttori. In tal modo, una volta verificati, i dispositivi possono essere classificati in un database in base al consumo di energia. Sarà così possibile ignorare il "Greenwashing" e decidere da soli ciò che è meglio.
Certo, è necessario sottolineare che se si desidera ottenere valori molto precisi sul funzionamento durante il carico di lavoro reale, è necessario eseguire un monitoraggio dell'ambiente di produzione. Prima si inizia a monitorare l'ambiente di produzione, migliori saranno i risultati ottenuti dall'azienda anche in termini economici. Si tratta di un processo fondamentale per raggiungere un successo a lungo termine.

Il bisogno dei numeri
In una situazione ideale sarebbero disponibili test indipendenti per valutare il rendimento per watt dei dispositivi hardware in condizioni di carico utente realistiche. Ma nel settore si è appena iniziato a sviluppare e immettere sul mercato test del genere. I test disponibili, ad esempio SPEC Power benchmark, sono ancora ai primi passi. La qualità di questi test, una volta pronti, è ancora tutta da scoprire. Ma come con qualsiasi test, i produttori impareranno a modificare le attrezzature per raggiungere risultati ottimali.
I professionisti IT più esperti hanno imparato a valutare i test condotti da laboratori appositi. Proprio come le aziende automobilistiche fanno in modo di destinare le automobili migliori ai test su strada, i produttori IT inviano le configurazioni delle attrezzature più efficienti per l'esecuzione dei test energetici.
Si prendano ad esempio i test di virtualizzazione utilizzati per confrontare un gruppo di server sovradimensionati su cui non è stato eseguito alcun consolidamento per dimostrare i vantaggi della virtualizzazione. I produttori evitano di menzionare i problemi relativi alle potenziali ripercussioni dei progetti di risparmio energetico, come la virtualizzazione. Sostanzialmente, ciò accade quando l'efficienza energetica consente di diminuire i costi, di conseguenza la domanda aumenta e ciò fa salire la quantità di energia utilizzata. Quando una soluzione, come la virtualizzazione, viene lanciata sul mercato come una panacea per il risparmio energetico, è bene nutrire dei sospetti. Si deve avere una visione di insieme ed essere consapevoli degli effetti a lungo termine.
Come scoprire, quindi, il metodo giusto per la propria azienda? Molti consulenti sono pronti ad eseguire delle valutazioni previo pagamento. Ma questo approccio comporta degli svantaggi. È davvero il caso di lasciare che le scelte in merito all'efficienza dell'azienda vengano affidate a qualcuno al di fuori dell'azienda? È opportuno affidarsi a un consulente che ha tutto l'interesse a mantenere un contratto a lungo termine e creare una sorta di dipendenza dal proprio servizio?
Il progetto per la determinazione della giusta strategia di sostenibilità ambientale potrebbe diventare enorme con il coinvolgimento di decine di persone. È bene resistere alla tentazione di scegliere semplicemente un punto all'interno dell'ambiente e iniziare a eseguire delle misurazioni. Sebbene l'approccio sia giusto in teoria, in pratica non ha molto senso poiché si tratta di azioni casuali. È necessario scoprire la verità sul consumo di energia e su come si possa offrire un contributo.

Misurazione dell'utilizzo di energia
È necessario considerare in un nuovo modo ciò che funziona. I professionisti IT si accorgono che un componente hardware non funziona quando, ad esempio, un servizio presenta dei problemi. Ma cosa accade se un componente hardware non funziona correttamente dal punto di vista del consumo energetico? Il problema non viene spesso rilevato, poiché la maggior parte delle aziende non dispone di dati per stabilire dei valori di riferimento relativi all'efficienza energetica.
Come ottenere questi dati? Alcuni suggeriscono la necessità di uno Zar dell'energia. Tuttavia, ciò presuppone la presenza di un responsabile in grado di muoversi nell'organizzazione aziendale e che abbia conoscenze tecniche in relazione ai problemi di alimentazione. Un metodo più semplice e accessibile prevede l'adozione di strumenti di misurazione di energia alle funzioni esistenti nei laboratori delle prestazioni.
Esiste una vasta gamma di dispositivi per la misurazione del consumo di energia. Purtroppo, ancora non esiste un dispositivo da utilizzare in un laboratorio IT di analisi delle prestazioni. Al massimo si può utilizzare Watts Up Pro. Si tratta di un dispositivo USB che fornisce misurazioni dell'energia in linea per 120V. Smart-Watt è un altro dispositivo di misurazione del consumo di energia che si può mettere in rete a 100-240 volt e 15-30 ampere. I dispositivi Smart-Watt sono disponibili anche con sensori di temperatura e umidità per misurare fattori ambientali. Inoltre, esistono dispositivi per l'analisi dell'alimentazione elettrica industriale, ad esempio, Extech Appliance Tester 380801 e Fluke 345 Power Clamp. È relativamente semplice trovare tali dispositivi per eseguire i test in laboratorio.

Fattore di potenza
Chi non ha mai eseguito misurazioni del consumo energetico, deve comprendere a fondo il concetto del fattore di potenza. Il fattore di potenza di un sistema elettrico CA equivale al rapporto tra la potenza attiva e la potenza apparente ed è rappresentato da un numero compreso tra 0 e 1. La potenza attiva (misurata in watt) è la capacità del circuito di eseguire lavoro. La potenza apparente (VA) è il prodotto della corrente e della tensione sul circuito.
Per comprendere perché è così importante, è sufficiente analizzare la Figura 1. Nell'immagine viene mostrato un dispositivo di monitoraggio energetico di Smart Works utilizzato per paragonare l'efficienza energetica di un computer portatile a quella di una lampadina elettrica e di un condensatore. Una lampadina elettrica ha un carico di 50 watt e 50 VA, per un fattore di potenza pari a 1,0. Un condensatore con un carico capacitivo puro ha un carico di 2 watt e 193 VA, per un fattore di potenza pari a 0,01. Il computer portatile utilizza 22 watt di energia ma ha una lettura di 48 VA, con un fattore di potenza pari a 0,47. Il fattore di potenza del computer portatile è basso a causa di un alimentatore inefficiente, probabilmente conseguenza di tagli ai costi di produzione.
Figura 1 Consumo di energia per un computer portatile, una lampadina elettrica e un condensatore (fare clic sull'immagine per ingrandirla)
Un tale interesse per l'efficienza energetica, spinge i produttori a migliorare le prestazioni degli alimentatori nelle condizioni di utilizzo previste. Se si confronta il fattore di potenza delle apparecchiature esistenti con quello delle apparecchiatura nuove, si scopre che è possibile risparmiare energia semplicemente scegliendo soluzioni con forniture di energia più efficienti e fattori di alimentazione più alti.

Misurazione in fase di produzione
Lo scopo dell'esecuzione di misurazioni nei laboratori delle prestazioni consiste nel prevedere le prestazioni nell'ambiente di produzione. Il problema nella misurazione del consumo di energia in fase di produzione è costituito dai costi necessari per eseguire la misurazione su tutti i dispositivi. Tuttavia, esiste una strategia per ridurre il costo di misurazione del consumo energetico in fase di produzione, ossia misurare al livello di unità di distribuzione di alimentazione (PDU) e aggregare le letture delle apparecchiature multiple. Nella Figura 2 viene illustrata una lettura di energia di campionamento presa da una PDU con componenti multipli della stessa apparecchiatura su un'unità. Poiché è possibile calcolare il consumo medio di energia per server, questo mezzo di misurazione fornisce informazioni riguardo i consumi energetici di produzione.
Figura 2 Misurazione a livello di unità di distribuzione di alimentazione (fare clic sull'immagine per ingrandirla)
Una volta che ogni componente dell'apparecchiatura è stato misurato, le informazioni relative devono essere integrate nel database di gestione della configurazione. Se è troppo difficile, è possibile creare un database o almeno un foglio di lavoro Excel® con i dispositivi e il relativo consumo energetico. Man mano che il numero di dispositivi aumenta, si possono formulare delle stime per altre apparecchiature, in modo da creare un calcolo della capacità energetica globale. È necessario considerare che un server efficiente sul piano del consumo energetico utilizza oltre la metà del carico di alimentazione quando è inattivo rispetto a quando è al massimo carico. Se il server è vecchio ed esegue soluzioni obsolete, consuma grandi quantità di energia anche se inattivo. Questo è uno degli obiettivi più semplici per recuperare capacità energetica.
Se si desidera andare oltre, il passaggio successivo è calcolare l'energia per rack utilizzato nel datacenter. È inoltre necessario accertarsi di comprendere le proprie capacità energetiche e di raffreddamento quando l'ambiente viene modificato. Nel tempo, si inizierà a vedere l'apparecchiatura in termini di esigenze energetiche e non solo in base allo spazio che richiede. Lo spazio è un concetto facile: statico e visivo. I professionisti IT possono parlare facilmente dei server 1U, 2U e 4U, ma se si parla di server da 200 watt a fronte di server da 450 watt, gli stessi professionisti non sono più così ferrati. Si tratta di un nuovo linguaggio per le apparecchiature informatiche e ciò è evidente nei datacenter odierni. Molti datacenter, sebbene dispongano di spazio sufficiente per ospitare altri componenti, hanno già raggiunto le capacità energetiche massime.

Microsoft EnterpriseEngineering Center
Microsoft EnterpriseEngineering Center (EEC) recentemente ha aggiunto la misurazione energetica al proprio impianto. Situato presso il campus Microsoft di Redmond, WA, l'EEC (microsoft.com/windowsserver/evaluation/eec/default.mspx) è un centro che permette alle organizzazioni di collaudare complessi scenari informatici aziendali.
Con più di 40 milioni di dollari investiti in hardware e dispositivi collegati in rete (vedere la Figura 3), l'EEC può affrontare la riproduzione degli ambienti di produzione più complessi di aziende reali. Il gruppo è associato a provider di soluzioni di collegamento di rete, di archiviazione e di soluzioni client/server per offrire un insieme di tecnologie e piattaforme legacy all'avanguardia. Lo scopo è assicurarsi che ogni test fornisca un'accurata riproduzione dell'ambiente corrente dell'azienda cliente. L'ultimo servizio che è stato sviluppato all'interno della struttura fornisce un report dettagliato sui consumi energetici per le soluzioni allo scopo di fornire un benchmark di prestazione per watt.
Figura 3 Una delle numerose file nel laboratorio EEC (fare clic sull'immagine per ingrandirla)
Negli ultimi anni l'EEC ha visto molti operatori di datacenter a corto di capacità di alimentazione e raffreddamento per le apparecchiature. Le apparecchiature più all'avanguardia spesso presentano i più alti livelli di densità energetica, ciò ha aumentato il carico sugli impianti. Il personale dell'EEC ha sperimentato in prima persona i costi e il tempo necessari per aggiornare l'infrastruttura di alimentazione e raffreddamento. Dunque, per operare più efficientemente ed essere più efficaci dal punto di vista dei costi, l'EEC ha aggiunto la capacità di misurare l'energia per dispositivo.
Alcuni degli strumenti e delle apparecchiature utilizzati dall'EEC non erano ancora stati distribuiti quando questo articolo è stato scritto. Poiché si tratta di una nuova soluzione, l'EEC continuerà a sviluppare tecniche migliori, lavorando con clienti, produttori e team di sviluppo di Microsoft. L'EEC condivide i metodi che ha sviluppato finora direttamente con i clienti in modo da ricevere commenti immediati, consentendo ai clienti di creare dei propri parametri di riferimento.
Al contrario di quanto si pensi, i risultati non sono affatto ovvi. L'EEC ha condiviso alcuni dei risultati interessanti scoperti dal gruppo nell'utilizzo di funzionalità di monitoraggio energetico nei laboratori di prestazione dell'EEC:
  1. 1. Lo spegnimento di un dispositivo non implica necessariamente la riduzione del consumo di energia, al contrario di quanto si possa pensare (vedere la Figura 4). In un caso, che riguarda l'hardware server, l'EEC ha scoperto un dispositivo che in realtà consuma 100 watt se spento, ma ancora collegato. Ciò ha sorpreso molte persone e l'EEC ha esaminato più volte la configurazione. Alla fine, è stato utilizzato un termometro a infrarossi per misurare la temperatura di entrata e uscita e verificare se il dispositivo consumava realmente 100 watt se spento.
  2. Il software può incidere pesantemente sul consumo di energia. Su switch di rete identici, con le medesime configurazioni hardware e BIOS, l'esecuzione di software di rete diversi comporta una differenza del 21% nel consumo di energia. Le soluzioni di alta qualità con più processi e funzionalità attivate, ad esempio, gli strumenti di protezione e controllo, consumano spesso più energia rispetto alle copie di bassa qualità dello stesso prodotto.
  3. Negli scenari di virtualizzazione, l'EEC ha misurato il consumo di energia a fronte dell'utilizzo di I/O e CPU per determinare quando un dato componente hardware massimizza le proprie prestazione per watt. L'EEC ha scoperto che la concentrazione dell'attenzione sull'utilizzo della CPU può condurre a troppe macchine virtuali caricate su una macchina fisica, diminuendo in realtà la prestazione complessiva per watt.
  4. I dispositivi a densità più alta, come si può immaginare, presentano maggiori problemi relativi all'alimentazione e al raffreddamento. Quando vengono distribuiti sistemi ad alta densità, il personale degli impianti di alimentazione e di raffreddamento dovrebbe essere consultato il prima possibile. Questi dispositivi sono buoni candidati per i dispositivi di controllo energetico in fase di produzione se l'ambiente sarà vincolato dall'energia.
  5. L'alimentazione elettrica doppia può consumare molta più energia dell'alimentazione elettrica singola.
  6. Componenti hardware apparentemente identici con configurazioni uguali possono presentare dei consumi energetici estremamente diversi. Le differenze osservate erano talmente cospicue che il personale dell'EEC ha ricontrollato l'hardware per accertare che i componenti presentassero davvero la stessa configurazione.
  7. La potenza in watt riportata sull'etichetta del prodotto non rappresenta i valori relativi ai consumi effettivi, ma la capacità stimata per gli alimentatori.
  8. La gestione di un database dei test relativi al consumo di energia e i risultati per ciascun dispositivo e sottocomponente è essenziale per conservare i dati ed eseguire dei confronti.
  9. Configurazioni diverse con la stessa quantità di RAM consumano quantità di energia differenti. Un numero minore di DIMM consuma generalmente meno energia, ad esempio 4 DIMM x 2 GB rispetto a 8 DIMM x 1 GB. Ma si sono registrati dei casi in cui un numero inferiore di DIMM consumava più energia.
Figura 4 Confronto del consumo di energia con dispositivo spento o acceso (fare clic per ingrandire l'immagine)

Conclusioni
Aggiungendo la capacità di misurare il consumo di energia nei laboratori delle prestazioni, è possibile iniziare la creazione di un proprio database relativo al consumo di energia per dispositivo con valori numerici accurati in relazione ai carichi reali. Una volta distribuite tali soluzioni, i risultati dovrebbero essere controllati in un sistema di feedback a circuito chiuso per determinare la precisione dei test eseguiti nel laboratorio delle prestazioni. Eseguendo i test di misurazione, l'EEC ha scoperto dei dettagli davvero interessanti da tenere in considerazione per filtrare il Greenwashing e scoprire la verità.
Questo metodo relativo alla misurazione nei laboratori delle prestazioni influenzerà il mercato globale iniziando a identificare i prodotti veramente efficienti dal punto di vista del risparmio energetico. Con il passar del tempo i produttori dovranno fornire dati più accurati a sostegno dei prodotti a risparmio energetico Al tempo stesso, i professionisti IT prenderanno in considerazione i watt per dispositivo come uno dei comuni criteri per decidere l'acquisto del prodotto. Ciò deve diventare una pratica comune, soprattutto per le aziende che comprano grandi quantità di server. Tuttavia, è possibile iniziare sin da oggi a considerare l'energia come una delle preziose risorse informatiche.
Mantenimento del raffreddamento nel datacenter
Il raffreddamento del datacenter offre un potenziale enorme per ridurre il consumo di energia. La quantità di calore che può essere generata in un datacenter è stupefacente, così come la quantità di energia utilizzata per mantenere l'hardware alla temperatura ideale. Ma se si desidera gestire correttamente il raffreddamento, risolvere i problemi e sviluppare soluzioni di raffreddamento più efficienti, è necessaria una soluzione di monitoraggio della temperatura. È utile prendere ad esempio la soluzione utilizzata dai datacenter Microsoft.
Microsoft Research ha creato una rete di sensori di temperatura per i datacenter che tiene conto del controllo di temperatura ottimizzato e consente anche di valutare gli eventuali miglioramenti del raffreddamento. Ad esempio, un datacenter Microsoft stava analizzando le cortine d'aria poste alla fine del corridoio per migliorare la separazione tra aria calda e fredda. Una volta installate le cortine, alcuni server hanno iniziato a segnalare problemi di surriscaldamento. Naturalmente, i tecnici addetti hanno aumentato il flusso di aria dall'impianto di raffreddamento per fornire una maggiore quantità d'aria fresca. Nonostante ciò, altri server segnalavano il medesimo problema. E tutti questi server erano posizionati nella parte inferiore del rack; questa parte è solitamente l'area più fresca di un sistema di raffreddamento a piano rialzato.
Utilizzando la rete di sensori, gli ingegneri hanno confermato che i rack erano più freschi nella parte superiore che in quella inferiore. Inoltre, hanno scoperto che l'aria calda proveniva dallo spazio caldo tra la parte inferiore del rack e il pavimento, una conseguenza del principio di Bernoulli. I tecnici hanno risolto facilmente il problema sigillando la parte inferiore del rack e riducendo la velocità del flusso dell'aria.
Ecco un esempio del tipo dei dati raccolti e analizzati dal Microsoft Enterprise Engineering Center nel corso dei test delle prestazioni. Di recente, l'EEC ha comunicato a Microsoft Research che era tutto pronto per eseguire un test di distribuzione. In un giorno il sistema è stato distribuito a 10 rack e per l'installazione è stata sufficiente un'ora di lavoro. L'EEC ora è in grado di studiare e comprendere meglio i problemi relativi al raffreddamento e la relazione con le prestazioni hardware.
Certo, il semplice controllo non rappresenta una soluzione. Ciò che è veramente importante è la capacità di individuare tipi di problemi che è possibile risolvere, di apportare delle modifiche e valutare le varie soluzioni per vedere se i risultati sono quelli previsti. Dopotutto, è meglio non essere presi alla sprovvista se la nuova soluzione di raffreddamento causa un inaspettato surriscaldamento dei rack.

Dave Ohara ha 26 anni di esperienza in campo tecnologico. Al momento lavora con diverse aziende che stanno implementando iniziative ecocompatibili.


Field Notes IMAP salva il mondo
R'ykandar Korra'ti

A volte, le soluzioni a piccoli problemi nuovi consentono di risolvere anche grandi problemi vecchi. Questo è uno di quei casi.
Lo scorso inverno, l'amministratore Web ha acquistato un MacBook. Sino a quel momento, aveva utilizzato esclusivamente Windows® ma ora disponeva sia di OS X, sia di Windows XP, su una macchina virtuale, per sincronizzare i dispositivi Windows Mobile® e svolgere alcune altre piccole attività.
Aveva bisogno di accedere a tutti gli archivi di posta elettronica da entrambi i sistemi operativi, ma non voleva eseguire Entourage da Mac, sarebbe stato troppo facile. Voleva invece utilizzare Mail.app, il client di posta elettronica contenuto in OS X. Oltretutto, aveva conservato tutto il materiale nell'archivio locale del suo portatile, senza alcun mirroring. Il mio compito: far funzionare il sistema.
Disporre di archivi leggibili ovunque presentava solo il piccolo problema menzionato sopra, dato che, e questa è la prima morale della nostra storia, tutti i componenti, compresi Exchange Server, Microsoft® Office Outlook®, e Mail, parlano il linguaggio IMAP4. IMAP4 è un protocollo di messaggistica per la gestione da thin client di archivi di messaggi su server. Presenta meno funzionalità rispetto a quelle di cui possono usufruire gli utenti di Exchange, ma comunque funziona (vedere Funzionamento di IT: IMAP4 nell'edizione di marzo-aprile 2006 di TechNet Magazine all'indirizzo technet.microsoft.com/magazine/cc161016).
Così, è bastato modificare un paio di impostazioni per mettere in linea IMAP4 utilizzando SSL, copiare tutte le cartelle locali sul server ed effettuare il ping! L'amministratore Web poteva così accedere alla posta su tutti i client e tenere aggiornati i propri dispositivi Windows Mobile. Problema risolto.
Ma individuare una soluzione semplice a un problema potenzialmente complesso è come quando ti regalano una nuova sega da tavolo. Improvvisamente inizi a cercare altro compensato e, prima di rendertene conto, hai realizzato un palcoscenico completo e sei pronto a inscenare "Romeo e Giulietta".
Il nostro piccolo provider di servizi Internet esegue Windows, OS X, Mac OS, Linux e persino un vecchio e solitario sistema AmigaOS in cerca di amici. Tanto tempo fa, ospitavamo le news di Usenet e la posta UUCP proprio su quell'Amiga, che creava archivi memorizzati in formato RFC-733/AmigaUUCP. Abbiamo anche archivi Microsoft Mail (in formato .mmf) e alcuni archivi di posta UNIX altrettanto vintage (in formato .mbox). Erano tutti lì a prendersi gioco di noi, un problema che prendevamo in considerazione di tanto in tanto per poi abbandonarlo colti dalla disperazione.
Questo scenario ci porta alla seconda morale della nostra storia, l'antico motto dell'hacker: non cancellare mai quel che non puoi sostituire.
Abbiamo affrontato per primi gli archivi di Microsoft Mail. Outlook non è in grado di importare i file .mmf da qualche tempo. Ma aggiornando i client nell'arco degli anni, abbiamo conservato almeno una licenza di ogni prodotto più vecchio, perché non si può mai sapere. Di conseguenza, la nostra raccolta di licenze segna la storia di Microsoft Corporation. Serve MS-DOS®? OS/2 1.31? Microsoft Mail? Office 95? Nessun problema! Lo preferite in inglese o francese?
Outlook 2000 ha importato i file .mmf supportando IMAP in modo anomalo e di tanto in tanto saltando i dati di intestazione. Inoltre, non era in grado di comunicare contemporaneamente con i server Exchange e IMAP4. Il problema era fastidioso, ma non impediva di procedere. Abbiamo importato i file .mmf con Outlook 2000, effettuato l'aggiornamento ad Outlook 2003 con la licenza conservata e, dopo qualche ora di trascinamento e rilascio, gli archivi vecchi di 15 anni erano in linea e visualizzabili da qualsiasi postazione. Lo stesso è accaduto per i file .mbox: abbiamo messo un server compatibile con IMAP su un computer Linux e poi collocato gli archivi in formato .mbox nella rispettiva directory di lavoro. Abbiamo poi utilizzato il supporto IMAP di Outlook per collegarci e copiare le cartelle nel server di produzione scelto.
Gli archivi Amiga, invece, richiedevano la scrittura di un piccolo frammento di codice C per convertire le intestazioni RFC-733 in formato RFC-822, buttare via i vecchi divisori di messaggi stile SysV e recuperare gli strani dati della riga Da: dall'inferno privato in cui erano sprofondati. Questo è il prezzo che si paga quando i problemi rimangono irrisolti per lungo tempo. Ma una volta fatto questo, il formato Amiga-UUCP si è trasformato in .mbox. Sistemato nella stessa directory di lavoro, Outlook IMAP4 è stato in grado di scaricare i messaggi di posta come se fossero nuovi. Ha persino confezionato per bene gli allegati.
Ora abbiamo in linea in formato unificato archivi che risalgono al 1990, e ne stiamo cercando altri... giusto perché possiamo. Siamo normali?

R'ykandar Korra'ti, responsabile della posta di una piccola cooperativa di provider di servizi Internet, vive vicino Seattle con la sua compagna Anna. Avendo precedentemente lavorato alla spedizione di prodotti per posta presso Microsoft, oggi scrive articoli tecnici quando non compone liriche profondamente oscure per brani di mandolino. Gli agenti di prenotazione possono contattarla all'indirizzo darako@murkworks.net.


Windows Confidential Il futuro si costruisce sul passato
Raymond Chen

Un mio collega ha recuperato una macchina Alpha AXP da un armadio polveroso. All'avvio del sistema, ha scoperto che sulla macchina era installata una versione a 64 bit di Windows® del 2000. Com'è possibile?
Un tempo avevo una di queste macchine nel mio ufficio. All'apice del successo, questo computer era una vera e propria forza. Aveva all'incirca le dimensioni di un piccolo frigorifero ed era rumoroso quanto un aspirapolvere. Conteneva quattro (li ho contati, quattro!) processori Alpha AXP, ciascuno dei quali con una frequenza pari a 400 MHz. Aveva un gigabyte di RAM e tredici gigabyte di spazio su disco rigido, distribuiti su una dozzina di unità SCSI veloci. Oggi potranno sembrare poco potenti, ma negli anni '90 questi Alpha AXP suscitavano l'invidia di tutti e chiunque li possedesse godeva di indiscussa popolarità.
Nel 1999, quando Compaq annunciò che l'Alpha AXP non avrebbe più supportato Windows, in Microsoft molti sistemi di questo tipo si sono trovati improvvisamente disoccupati, senza compiti ufficiali da svolgere. Alcuni, tuttavia, sono stati utilizzati per una serie di operazioni ufficiose. Io ho utilizzato il mio Alpha AXP per indicizzare l'intero codice sorgente di Windows. Si potrà immaginare quanto sia comodo per un programmatore poter identificare tutti i comandi di richiamo di una funzione in pochi secondi o localizzare il codice sorgente di una funzione o una finestra di dialogo visualizzata in una traccia di debug.
Ma anche per un'operazione semplice come l'indicizzazione del codice sorgente Windows, l'Alpha AXP è stato presto eclissato dalle macchine classe x86. Queste erano più economiche e rapide, offrivano più spazio su disco rigido e avevano più memoria. Per questo motivo, in breve anche il mio computer ha raggiunto le altre macchine dimenticate. Si supponeva che la fine del supporto per l'Alpha AXP significasse la fine di queste macchine, ma poi si è presentata l'opportunità di un ultimo attimo di gloria, esalando gli ultimi respiri al servizio della nuova generazione.
Il progetto di Windows a 64 bit era già avviato e, tra i processori a 64 bit presi in considerazione, solo l'Alpha AXP era in realtà fisicamente disponibile. L'Intel Itanium era ancora in fase di sviluppo e operava solo in un simulatore, mentre l'architettura AMD64 non era nemmeno stata inventata. Di conseguenza, Windows a 64 bit è stato inizialmente sviluppato sull'Alpha AXP.
Quando Compaq ha annunciato che l'Alpha AXP non avrebbe più supportato Windows, tutti i computer di questo tipo, che in precedenza erano stati utilizzati per lo sviluppo e il test di Windows 2000 a 32 bit, sono stati reimpiegati, iniziando una vita segreta come macchine di prova per un sistema operativo a 64 bit che non sarebbe mai stato fornito in quella forma. L'Alpha AXP era una semplice piattaforma di prova.
I computer Alpha AXP hanno svolto bene questo ruolo, fornendo al team di Windows a 64 bit un supporto hardware vero e proprio su cui operare, anziché eseguire il sistema operativo su un simulatore Itanium (è facile immaginare quanto fosse lento). Certo, l'Alpha AXP non era l'hardware finale di destinazione, ma è stato di grande aiuto. Con la comparsa delle prime CPU Itanium vere e proprie, la nicchia colmata dagli Alpha AXP svanì e le macchine furono di nuovo relegate in armadi polverosi.
I miei amici che lavorano agli archivi Microsoft hanno tirato fuori dal suo armadio polveroso il mio vecchio e fedele Alpha AXP per questa foto, in cui è ritratto con uno dei prodotti che ha contribuito a rendere possibili: l'edizione a 64 bit di Microsoft Windows Server® 2003. Quella che si vede è proprio la polvere originale.

Sul sito Web di Raymond Chen, The Old New Thing, così come nell'omonimo libro (Addison-Wesley, 2007), vengono illustrate la storia di Windows e la programmazione in Win32. Lui preferirebbe non essere rinchiuso in un armadio polveroso.