 TechNet Magazine July 2007

TechNet Magazine July 2007

Comunicazioni: Protezione dei dati e ripristino di emergenza per Exchange Server 2007

Exchange Server 2007 include un'ampia gamma di opzioni per il supporto della disponibilità elevata e del ripristino di emergenza. Nel presente articolo vengono esaminate le soluzioni alternative offerte da Exchange in base a cui sviluppare la soluzione di ripristino più adeguata per la propria organizzazione.

Lee Benjamin Comunicazioni: Miglioramento della protezione con Windows Mobile 6

Se da una parte smartphone e PDA offrono l'accesso alla rete dall'esterno dell'ufficio, dall'altra espongono la stessa rete a nuove vulnerabilità. In questo articolo viene fornita una guida alla protezione dei dispositivi mobili e dell'infrastruttura aziendale tramite Windows Mobile 6 ed Exchange Server.

Matt Fontaine Comunicazioni: Una valida alternativa alle cartelle pubbliche

MOSS 2007 fornisce una soluzione per la condivisione dei dati molto più valida rispetto alle cartelle condivise di Exchange, grazie alle funzionalità migliorate e alla più semplice gestione. Verrà analizzato il modo in cui è possibile utilizzare SharePoint per la condivisione di calendari, contatti e documenti.

Alan Maddison Comunicazioni: Accesso a Outlook Web Access con smart card

Uno degli anelli più deboli della catena di protezione è rappresentato da password vulnerabili e facilmente acquisibili. Scopri come migliorare la protezione della posta elettronica implementando l'autenticazione a due fattori basata su smart card per gli utenti mobili.

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Amministrazione di Windows: Il servizio ActiveX Installer in Windows Vista

Come proteggere il desktop da controlli ActiveX dannosi senza limitare la compatibilità delle applicazioni? In questo articolo verrà fornita una panoramica del servizio ActiveX Installer presente in Windows Vista, che risolve questo problema con un nuovo sistema di gestione dei controlli ActiveX.

Rob Campbell and Joel Yoker Dal redattore: Sei gradi

Joshua Trupin Casella degli strumenti: Nuovi prodotti per professionisti IT

Greg Steen SQL: Domande&Risposte: Clustering interno, blocchi misteriosi, account dell'amministratore di sistema e altro ancora

Edited by Nancy Michell Utilità sotto i riflettori: SMSMap

Jeff Tondt Funzionamento di IT: Risoluzione degli errori RPC

Zubair Alexander The Cable Guy: Traffico IPv6 su connessioni VPN

Joseph Davies Windows PowerShell: Riflessioni sulla pipeline

Don Jones Hey, Scripting Guy!: Negli script, come nella vita, l'aspetto è importante

The Microsoft Scripting Guys Exchange Queue & A: Ruoli Trasporto Edge e Hub, computer virtuali e altro ancora

KC Lemson and Nino Bilic Controllo della protezione: Strumenti per la gestione degli ACL

Jesper M. Johansson Desktop file: Microsoft Desktop Optimization Pack

Wes Miller Windows Confidential: I poteri terapeutici della modalità provvisoria

Raymond Chen


 Comunicazioni: Protezione dei dati e ripristino di emergenza per Exchange Server 2007
Comunicazioni Lee Benjamin

Protezione dei dati e ripristino di emergenza per Exchange Server 2007
Panoramica:
  • Backup e ripristino di base
  • Continuità dei dati
  • Tecnologie di replica
  • Soluzioni alternative

Microsoft Exchange Server è stato progettato specificamente per soddisfare le esigenze di backup. Le organizzazioni hanno l'esigenza di eseguire il backup oltre che il ripristino dei relativi dati di messaggistica. Per rispondere a questa esigenza, Microsoft ha creato una gamma completa di opzioni per la protezione dei dati, che spaziano da
funzionalità di backup e ripristino di base a soluzioni di continuità operativa e di continuità aziendale che forniscono i più alti livelli di disponibilità e ripristino di emergenza. In questo articolo verranno esaminate queste opzioni e verranno fornite informazioni utili nella scelta del metodo di implementazione della soluzione di ripristino di Exchange più appropriata alla propria organizzazione.

LIVELLO 1: BACKUP E RIPRISTINO DI BASE
È possibile eseguire il backup dei file di Exchange sia in modalità non in linea che in fase di esecuzione. Il secondo approccio rappresenta, in effetti, il metodo consigliato per l'esecuzione del backup di Exchange. Exchange è tuttavia molto più di un insieme di file. È un archivio di informazioni con file di database e registri delle transazioni di grandi dimensioni. I messaggi inviati a Exchange vengono archiviati immediatamente nei registri delle transazioni e, quando nel sistema sono disponibili alcuni cicli non utilizzati (in genere solo pochi millisecondi dopo), i messaggi vengono copiati nel database. Grazie alla possibilità di copiare le informazioni sul disco il più rapidamente possibile, Exchange un livello molto elevato di recuperabilità. Per il ripristino di Exchange è fondamentale la disponibilità di entrambi i set di dati. In caso di errore del sistema, la combinazione di un backup precedente e di tutte le transazioni eseguite a partire da tale momento consentirà di ripristinare in Exchange le informazioni più recenti. Tenere presente che in Exchange le transazioni vengono automaticamente replicate in un database ripristinato, in base alle esigenze.
I programmi di backup accedono alle informazioni contenute nel database di Exchange tramite l'API di backup ESE (Extensible Storage Engine) o le più recenti soluzioni VSS che verranno illustrate più avanti in questo articolo. Ogni volta che viene avviato un backup ESE, Exchange sospende temporaneamente tutte le operazioni di scrittura nei relativi database. Nello stesso momento in cui ESE imposta temporaneamente il database sulla modalità di sola lettura che ne garantisce la disponibilità per la copia in un backup completo, utilizza anche un database temporaneo in cui memorizzare le nuove transazioni eseguite durante il backup. Quando il backup viene completato, ESE reimposta il database sulla normale modalità di lettura/scrittura e applica le transazioni che sono state accumulate nel database temporaneo. Al termine di un processo di backup eseguito in modo corretto vengono inoltre eliminati i registri delle transazioni obsoleti.
Sebbene il processo di backup sia semplice e avvenga in modo trasparente persino per gli utenti che eseguono l'accesso durante la notte mentre il backup è in corso, il completamento di ESE potrebbe richiedere tempi piuttosto lunghi, in base alle dimensioni dei database di Exchange, che possono variare da pochi gigabyte a dimensioni ancora gestibili comprese tra 30 e 50 GB fino ad arrivare persino a 100 GB, un contesto in cui diventa quasi impossibile eseguire il backup durante la notte quando si utilizzano tecnologie standard. Per avere un'idea delle opzioni disponibili quando si utilizza NTBackup.exe, dare un'occhiata alla Figura 1.
Figura 1 Utilizzo dell'utilità NTBackup
Figura 1 Utilizzo dell'utilità NTBackup

Procedure consigliate per Exchange
Se si desidera essere in grado di effettuare rapidamente il ripristino in seguito a comuni errori di sistema o hardware, è consigliabile eseguire backup completi di Exchange durante la notte. Per ottimizzare le prestazioni e la recuperabilità ogni volta che un server Exchange utilizza dischi locali, è opportuno utilizzare array RAID separati per memorizzare i database e i registri delle transazioni di Exchange. In tal modo, in caso di errore di un controller dell'array RAID o di guasto di più dischi dell'array che impedisce ai dischi rimanenti di ricostruire i dati con striping, si sarà comunque in grado di eseguire il ripristino. In caso di perdita dei registri delle transazioni, saranno comunque disponibili database di Exchange aggiornati nelle altre unità che consentiranno di continuare le normali operazioni con i nuovi registri delle transazioni. In caso di perdita delle unità del database, la strategia di ripristino consigliata prevede l'accesso al backup completo eseguito la notte precedente per i database di Exchange e successivamente l'applicazione dei registri delle transazioni del giorno corrente per aggiornarlo.
È importante limitare le dimensioni dei database di Exchange in modo che sia possibile eseguirne il backup e, cosa più importante, il ripristino, in un intervallo di tempo accettabile. Per la maggior parte delle organizzazioni, questo implica la necessità di limitare le dimensioni dei database a un intervallo compreso tra 30 e 50 GB. Quando le dimensioni di un database superano questo valore, è consigliabile suddividerlo in più database in modo da rendere più gestibile il processo di ripristino.

Continuum dei processi di backup e ripristino
Il posizionamento dei database e dei registri delle transazioni è molto importante non solo in termini di prestazioni del processo di backup ma anche in termini di velocità del ripristino. Attualmente, tutti i server supportano diversi livelli di ridondanza dell'unità disco, a cui viene fatto riferimento con il termine RAID. In sostanza, la tecnologia RAID impedisce che un eventuale errore dell'unità disco determini l'arresto anomalo del sistema; le prestazioni del sistema subiranno tuttavia un rallentamento fino a quando il disco non viene sostituito o ricreato. Fino a tale momento, il controller dell'array deve ricostruire i dati presenti nei dischi rimanenti in tempo reale in risposta alla richiesta di accesso a ciascun disco. Per ulteriori informazioni sulla modalità di archiviazione del server delle cassette postali, vedere l'articolo di Microsoft IT Showcase "Passaggio alla piattaforma a 64 bit con Exchange Server 2007".
Una delle funzionalità di base di Exchange è la progettazione di database a istanza singola. questo implica che all'interno di un database di Exchange viene archiviata un'unica copia di uno specifico messaggio, insieme a un singolo allegato (se disponibile). Se il messaggio è stato inviato a più destinatari nello stesso archivio di informazioni, verranno creati puntatori aggiuntivi agli oggetti (messaggio, allegato), ma gli oggetti non verranno duplicati. Questo rappresenta un enorme vantaggio non solo in termini di efficienza del recapito dei messaggi, ma anche in termini di risparmio di spazio, sia su disco che su nastro.
Sebbene Exchange consenta un ripristino efficace dell'intero database, il ripristino di singole cassette postali, cartelle o messaggi richiede prima di tutto il ripristino dell'intero nastro. Non sorprende che gli utenti desiderassero funzionalità di ripristino più granulari. Tuttavia, la disponibilità di una singola istanza sul nastro preclude questa possibilità. I fornitori di soluzioni di backup hanno risposto a questa esigenza con il cosiddetto "backup brick-level", ovvero il backup specifico delle singole cassette postali, che io tuttavia non consiglio di utilizzare. Dopo aver completato un backup completo del database di Exchange utilizzando l'API di backup ESE approvata, i prodotti di backup aggiungono ciascuna cassetta postale al nastro di backup. Poiché l'API di backup non fornisce un metodo per estrarre i dati dalle singole cassette postali, viene utilizzato MAPI. La durata del nastro di backup diventa, di conseguenza, notevolmente maggiore in quanto vengono duplicati tutti i messaggi e gli allegati.
Microsoft ha introdotto alcuni miglioramenti che risolvono parzialmente questo problema. Ad esempio, il cestino amministrativo (o dumpster) conserva gli elementi per un determinato periodo di tempo dopo che sono stati eliminati dagli utenti in modo da consentirne il riutilizzo nel caso in cui siano necessari. Inoltre, non è più necessario conservare un server di riserva come foresta di ripristino di Exchange; i gruppi di archiviazione di ripristino consentono a un amministratore di montare parzialmente i database ripristinati dal nastro e di copiare o unire i dati a livello delle cassette postali.

Dalla pratica nasce la perfezione
La maggior parte delle organizzazioni ha sperimentato che, indipendentemente dal livello di backup e di ripristino su cui è ricaduta la scelta, i supporti di backup e le procedure di ripristino devono essere testati con regolarità. Troppi amministratori apprendono che le relative tecnologie di backup e procedure di ripristino funzionano in modo corretto solo dopo una situazione di emergenza. Il momento più appropriato per eseguire il test è il giorno dopo la creazione e la configurazione del nuovo server, quando è già operativo come parte dell'organizzazione Exchange ma viene utilizzato solo da un numero limitato di utenti. In tale fase è consigliabile eseguire un backup completo di Exchange, effettuare backup periodici delle unità e acquisire lo stato del sistema, che include i file di importanza critica del disco di sistema e la metabase di IIS (in cui viene conservata la configurazione di routing di Exchange). Successivamente, riformattare il nuovo server e ricominciare da capo, aggiornando le note prese quando si è creato il server per la prima volta. A questo punto si dovrebbe essere in grado di ripristinare le impostazioni dello stato del sistema; è inoltre opportuno reimplementare le impostazioni di configurazione del sistema manualmente basandosi sulla documentazione correlata.
Il tempo dedicato a questa esercitazione per la verifica del piano di ripristino di emergenza consentirà di ridurre significativamente i tempi di ripristino in futuro. Ripetere il processo periodicamente. Nel corso di questo processo, annotare il tempo impiegato per recuperare i nastri archiviati fuori sede. Coloro che si sono imbattuti in situazioni che richiedevano la necessità di attendere il completamento di questo intervallo apparentemente interminabile iniziano a pensare più seriamente al ruolo importante che i backup da disco a disco possono svolgere nell'ambito della relativa strategia di backup e ripristino, anche se l'archiviazione di nastri fuori sede continua a fornire la principale "rete di sicurezza" per il ripristino di emergenza.

Problematiche correlate al backup su nastro
Il ripristino di dati da nastro richiede tempi eccessivamente lunghi. Considerato il ruolo critico che Exchange riveste attualmente per le organizzazioni, sia gli utenti che il corpo direttivo dell'azienda si aspettano che questa applicazione sia sempre disponibile. Quando si verifica un problema grave, la maggior parte delle organizzazioni viene colta impreparata. Nessuna organizzazione dispone della preparazione adeguata per gestire i tempi eccessivi lunghi, addirittura otto ore, richiesti dal ripristino da nastro di database di 75 GB; un intervallo che non include neppure il tempo impiegato per ripristinare i nastri dalla struttura di archiviazione fuori sede o per reinstallare il sistema operativo.
Inoltre, occorre considerare le difficoltà insite nel ripristino da nastro del database corretto. Nei 10 anni successivi al rilascio della prima versione di Exchange, il costo dell'archiviazione su disco e delle reti WAN si è ridotto in misura considerevole. Di conseguenza, molte organizzazioni sono in grado di sostenere i costi di metodi di backup e ripristino più rapidi. Queste organizzazioni hanno la possibilità di sfruttare i vantaggi di tecnologie che consentono loro di dotare l'infrastruttura Exchange di adeguati piani di continuità operativa e di ripristino di emergenza.

LIVELLO 2: CONTINUITÀ OPERATIVA
La continuità operativa è un insieme di processi e tecnologie volti a garantire il ripristino nel minor tempo possibile, riducendo al minimo i tempi di inattività non previsti. La continuità operativa offre livelli migliorati di RTO (Recovery Time Objective, tempo massimo di ripristino del servizio) e di RPO (Recovery Point Objective, perdita dati tollerata) su nastro per il ripristino locale e mira a eliminare, ove possibile, i tempi richiesti per ripristinare i nastri in sede. Dare un'occhiata alla Figura 2 per un confronto tra continuità operativa, processi di backup e ripristino e piano di ripristino di emergenza.
Figura 2 Continuum del processo di ripristino
Figura 2 Continuum del processo di ripristino
In questo diagramma viene illustrato il continuum del processo di ripristino e della disponibilità che va da soluzioni lente ed economiche nella parte inferiore sinistra a soluzioni rapide e costose nella parte superiore destra, con una transizione deliberatamente indistinta tra le soluzioni di continuità operativa e di ripristino di emergenza.
Il grafico dà un'idea dei compromessi tra costi, tempi di ripristino e disponibilità che questi approcci comportano. In questo articolo viene intenzionalmente operata una chiara distinzione tra processi di continuità locali e ripristino di emergenza. Il piano di ripristino di emergenza è sempre considerato remoto, il cui obiettivo principale è il recupero di dati archiviati fuori sede. La distanza introduce problemi aggiuntivi e comporta un maggiore dispendio in termini di denaro, ma il piano di ripristino di emergenza mira ad assicurare principalmente la continuità aziendale dopo eventi catastrofici. questo argomento verrà trattato in maggior dettaglio più avanti in questo articolo.

Un po' di storia
Man mano che Exchange ha cominciato a svolgere un ruolo sempre più strategico nell'ambito dell'infrastruttura e considerata l'attuale tendenza ad archiviare nei database di Exchange una quantità sempre più elevata di informazioni, è emersa chiara la necessità di ridurre i tempi di backup e ripristino. In collaborazione con Microsoft, alcune organizzazioni di grandi dimensioni hanno elaborato un approccio che garantiva un miglioramento dei tempi di ripristino di uno stato di parziale operatività. Se un'organizzazione era in grado ricevere e inviare nuovi messaggi di posta elettronica al mondo esterno, nessuno avrebbe immaginato che si fossero verificati dei problemi. Dopotutto l'apparenza oggi ha un ruolo notevole nella società.
Per implementare questo ripristino temporaneo per Exchange, è stato utilizzato un nuovo database vuoto in sostituzione del database danneggiato. In Exchange e Active Directory® sono state quindi create nuove cassette postali con autorizzazioni appropriate e gli utenti erano in grado di ricevere e inviare messaggi. Una volta recuperato il nastro di backup e ripristinati i dati, poteva essere montato dagli utenti con privilegi di amministratore. L'amministratore di Exchange avrebbe quindi unito le cassette postali ripristinate nelle cassette postali temporanee. Era possibile assegnare alle cassette postali livelli di priorità, in base alle esigenze. Sebbene si trattasse di un miglioramento, questo era un processo piuttosto complesso e dispendioso in termini di tempo che originariamente prevedeva l'utilizzo di EXMERGE e successivamente è stato adattato ai gruppi di archiviazione di ripristino. Tenere presente tuttavia che il ripristino completo dei dati dopo uno scenario di ripristino temporaneo può rivelarsi un'attività difficile e complessa, in particolare in situazioni in cui è possibile utilizzare fino a 50 gruppi di archiviazione, come in Exchange 2007). Se si prende in considerazione l'implementazione di uno scenario di ripristino temporaneo, accertarsi che i vantaggi ottenuti superino gli sforzi richiesti.

Servizio Copia Shadow del volume
Per sfruttare i vantaggi dei dischi più economici e per rimuovere l'overhead sul processore generato dai server di produzione di Exchange, è stata sviluppata una nuova API di backup per Microsoft® Windows Server® 2003 ed Exchange. Il servizio Copia Shadow del Volume (VSS) è stato creato per consentire l'esecuzione di copie temporizzate coerenti dei dati. Questi snapshot sono copie rapide di sola lettura dei dati di Exchange che includono in successione solo i dati che sono stati modificati. Le copie in genere fanno riferimento a un altro server con spazio su disco disponibile o a una rete SAN (Storage Area Network). È possibile conservare più snapshot con backup eseguiti su nastro. Di conseguenza, il server Exchange di produzione non dovrà più soffrire l'impatto in termini di prestazioni dell'overhead generato dal software di backup e dalla copia su nastro.
L'utilizzo del servizio Copia Shadow del volume per la protezione dei dati di Exchange comporta diversi vantaggi. Primo, è possibile rimuovere dal server Exchange il carico sulle prestazioni delle operazioni di backup su nastro. Sebbene il backup su nastro continui a essere necessario, è possibile utilizzare la copia dei dati di Exchange senza alcun impatto sulle prestazioni degli utenti. Secondo, è possibile creare più di uno snapshot per notte, con il vantaggio aggiuntivo di poter conservare più snapshot sul server secondario o altri dispositivi di archiviazione locali.
Sul mercato sono disponibili numerosi prodotti di terze parti che sfruttano i vantaggi offerti dalle funzionalità snapshot VSS. Alcuni riducono semplicemente il tempo necessario per il backup e il ripristino dei database di Exchange, mentre altri aggiungono ulteriori funzionalità, ad esempio un ripristino più granulare rispetto a quello offerto dalla modalità Exchange nativa in modo da consentire il ripristino a livello delle cassette postali. Sebbene i backup "brick level" non rappresentino la soluzione preferita dagli utenti, questi hanno comunque l'esigenza di ripristinare specifiche cartelle o singoli messaggi.

Tecnologie di replica
Il failover di Exchange mediato da software è un'opzione fornita da alcuni fornitori di tecnologie di replica. Questa opzione consente l'attivazione di un server Exchange standby e indica ad Active Directory che tutte le cassette postali degli utenti sono state spostate. Questa operazione può essere eseguita in due modi, che richiedono entrambi alcune personalizzazioni degli ambienti Exchange e Windows. Uno dei due metodi prevede l'adozione di alcuni accorgimenti con il server DNS in modo che il server standby assuma il nome e l'indirizzo IP del server in cui si è verificato l'errore. Il vantaggio di questo approccio risiede nella sua semplicità di utilizzo sulle workstation client in quanto Outlook® pensa che sta ancora utilizzando lo stesso server.
Il secondo approccio prevede l'utilizzo di un server di standby che esegue Exchange, in cui vengono archiviate le copie del database ma non viene montato nulla. In caso di errore, il server di standby informa Active Directory che tutte le cassette postali degli utenti sono state spostate. Successivamente, viene eseguito uno script o viene distribuito un criterio di gruppo, che informa i client che le cassette postali risiedono su un server di posta differente. Outlook 2007 fornisce il supporto per Active Directory, il che semplifica il processo in quanto è in grado di stabilire questi mapping automaticamente.

Clustering locale con MSCS
A un livello più alto nel continuum della disponibilità si trova Microsoft Cluster Services (MSCS); Exchange è un'applicazione abilitata per i cluster. Il clustering prevede la condivisione di informazioni tra due o più computer in modo che, in caso di errore su uno di essi, gli altri possono assumere il controllo. Attualmente, la maggior parte dei cluster Exchange è rappresentata da due o quattro nodi, anche se è possibile utilizzare fino a otto nodi. Un nodo è sempre designato come passivo, operativo quando Windows Server è in esecuzione ed Exchange Server è installato, ma non contiene cassette postali attive. L'utilizzo di un cluster attivo/attivo a due nodi era possibile in Exchange 2003, ma a causa dei carichi sulle prestazioni, ora è sconsigliato e non verrà supportato in Exchange 2007.
Analogamente alla disposizione dei cluster in Exchange 2003, i cluster di Exchange 2007 che includono un nodo passivo possono ancora utilizzare un singolo vettore di archiviazione (storage array). Sebbene i vettori di archiviazione di tipo cluster dispongano in genere di una serie di funzionalità di ridondanza per gestire diversi tipi di errore, forniscono tuttavia una sola copia di dati, il che lascia aperta una finestra di vulnerabilità. Per questo motivo, questi cluster vengono chiamati cluster a copia singola (SCC) per distinguerli dalla successiva frontiera nell'ambito della protezione dei dati rappresentata dai cluster a copia multipla (MCC) in Exchange 2007. I cluster a copia multipla verranno illustrati in maggiore dettaglio nella sezione relativa al ripristino di emergenza.

Replica continua locale
La replica continua locale (LCR) è una nuova funzionalità di Exchange 2007 che garantisce una gestione più efficace di una seconda copia dei database e dei registri delle transazioni di Exchange all'interno dello stesso server. Questo aggiunge un livello di ridondanza alla procedura consigliata che prevede l'installazione del database e dei registri delle transazioni di Exchange su array RAID separati: LCR consente di archiviare una copia secondaria dei registri sull'array in cui è archiviata la copia principale del database e di archiviare una copia secondaria del database sull'array in cui è archiviata la copia principale dei registri (vedere la Figura 3). In caso di errore dell'array o del controller RAID, sarà possibile utilizzare il database e i registri delle transazioni archiviati nell'altro array. In questo modo, sarà possibile continuare a svolgere le attività aziendali, anche se non senza un certo nervosismo e con prestazioni ridotte, fino a quando non si sarà in grado di ricreare l'array in cui si è verificato l'errore.
Figura 3 Configurazione di LCR
Figura 3 Configurazione di LCR
Poiché LCR è una soluzione per la continuità operativa locale, non una soluzione di backup, è comunque necessario utilizzare una strategia di backup completo. L'utilizzo di LCR inoltre incide sulle prestazioni in quanto il server in uso ora dovrà eseguire due copie del database e dei registri delle transazioni. Inoltre, l'implementazione di Exchange 2007 prevede alcune limitazioni che rendono l'utilizzo di LCR adatto solo alle organizzazioni di piccole dimensioni in quanto LCR supporta un solo database in un gruppo di archiviazione e un solo database di cartelle pubbliche all'interno di un'organizzazione.
Il failover mediante un ripristino basato su LCR non è istantaneo: un professionista IT esperto dovrà eseguire alcuni script per il backup di Exchange. Il processo richiede l'esecuzione dei comandi di Exchange Management Shell all'esterno di Exchange Management Console.
Mentre Exchange Server 2003 Enterprise Edition consentiva a un'organizzazione di eseguire fino a 20 database Exchange (quattro gruppi di archiviazione ciascuno dei quali contenente un massimo di cinque database), Exchange 2007 Enterprise Edition consente di eseguire fino a 50 gruppi di archiviazione, ciascuno con il proprio database. Anche i registri delle transazioni sono stati ridotti da file di 5 MB in Exchange 2003 a file di 1 MB in Exchange 2007. Entrambe queste modifiche sono state introdotte allo scopo di fornire il supporto per LCR, nonché per la replica continua cluster (CCR), che verrà discussa tra breve.
Le organizzazioni di piccole e medie dimensioni utilizzeranno LCR per garantire una maggiore protezione dei dati nell'ambito delle relative operazioni Exchange. LCR è facile da implementare ma richiede l'intervento manuale. In quanto soluzione per l'archiviazione su disco locale all'interno dello stesso server, LCR rappresenta solo il primo passo verso il miglioramento della continuità operativa. Anche se garantisce la protezione da errori di un array RAID o di controller RAID, più guasti simultanei del disco o errori dei controller RAID sono relativamente rari. Nella maggior parte dei casi, gli scenari di errore implicano il collasso dell'intero server, il che introduce la fase successiva nell'ambito della protezione di Exchange.

Replica off-host locale di terze parti
Per migliorare le funzionalità di ripristino di Exchange, alcuni fornitori di terze parti hanno sviluppato prodotti che sfruttano i vantaggi della replica "off-host" utilizzando i file di registro di Exchange per conservare una copia di standby del database di Exchange su un altro computer. In questo caso, la soluzione di archiviazione e protezione dei dati esegue un backup completo ESE di Exchange in un computer differente ed effettua il pull dei registri delle transazioni non appena vengono chiusi da Exchange. Inserisce le transazioni nella copia del database di Exchange in modo che sia sempre aggiornato. Come osservato in precedenza, questi registri sono relativamente piccoli (5 MB in Exchange 2003 e 1 MB in Exchange 2007) e pertanto, una volta completato il backup completo, la copia dei file di registro sul server off-host non genera in pratica alcun overhead sul server Exchange.

LIVELLO 3: RIPRISTINO DI EMERGENZA ED ELEVATA DISPONIBILITÀ
Il ripristino di emergenza è la capacità di ristabilire uno stato di completa operatività in caso di mancata disponibilità del principale centro dati. Exchange merita una soluzione di ripristino di emergenza efficace in quanto le funzioni di calendario e di posta elettronica rivestono attualmente un'importanza cruciale per la maggior parte delle organizzazioni.
Alcune aziende ritengono che i tradizionali backup su nastro archiviati fuori sede siano una forma di piano di ripristino di emergenza, senza pensare alla conseguenze insite in un'eventuale distruzione, dovuta ad esempio a un incendio o un'inondazione, dell'unico centro dati disponibile: un cumulo di bobine di nastro sarebbe senza dubbio di scarsa utilità per l'organizzazione. Il ripristino di emergenza determina necessariamente lo spostamento non solo dei dati in una posizione alternativa, ma anche della tecnologia e dei processi in grado di riportare l'applicazione in uso a uno stato di completa operatività. Per essere efficace, il piano ripristino di emergenza deve prevedere la separazione tra i sistemi primari e secondari. La distanza di separazione tra le sedi dipende dall'entità dell'emergenza a cui si deve far fronte. Se la preoccupazione principale riguarda lo scoppio di un incendio, probabilmente un altro edificio nel campus aziendale garantisce una distanza di sicurezza sufficiente a evitare qualsiasi pericolo per i dati aziendali. Tuttavia, le emergenze a livello di infrastruttura che coinvolgono treni o aerei potrebbero interessare un raggio di circa due chilometri o più. Molti disastri avvengono a livello locale: inondazioni, tempeste di neve, terremoti e persino interruzioni di alimentazione. Esistono calamità che hanno un impatto diretto sui sistemi di comunicazione, che possono spaziare da un retroescavatore che può interrompere il collegamento al proprio ISP ad attacchi Denial of Service e attacchi DoS su Internet che prendono di mira il commercio in generale.
Ai fini pratici, se la propria organizzazione dispone già di più sedi con personale IT, è possibile che una di queste sedi sia in grado di soddisfare i criteri stabiliti per la continuità operativa remota, in base ai tipi di situazioni di emergenza a cui far fronte. Utilizzare una propria struttura e il proprio personale sarà senza dubbio meno costoso che accordarsi con un fornitore di terze parti per la fornitura di soluzioni di ripristino di emergenza o prendere in affitto un nuovo locale.
Infine, il ripristino di emergenza è strettamente correlato anche alla percezione dell'azienda da parte del proprio pubblico: non dare ai clienti l'impressione che l'organizzazione abbia cessato l'attività. Quando un'emergenza colpisce una città o un'area specifica, se la propria azienda non ritorna operativa nel più breve tempo possibile, vi è la possibilità che clienti e fornitori pensino al peggio; molte aziende falliscono proprio per questo motivo. L'azienda deve dare ai clienti l'impressione che si sta attivando per ristabilire tempestivamente la propria operatività in modo da rassicurarli da possibili dubbi circa la continuità aziendale. I clienti avranno opinioni diverse per quanto riguarda il concetto di ripristino tempestivo: sono comprensibilmente meno pazienti con le interruzioni di servizio che avvengono presso le relative aziende di servizi finanziari rispetto ad esempio alle interruzioni che si verificano presso i relativi fornitori di arredi per ufficio.

Requisiti del ripristino di emergenza
La capacità di riportare in linea Exchange dopo una situazione di emergenza richiede la replica dei relativi dati nella sede secondaria e l'utilizzo di una tecnologia di replica che sia in grado di presentare i dati a un server Exchange che supporti tale tecnologia, quindi l'invio di una notifica ai client Outlook in cui vengono informati che le relative cassette postali sono state spostate.
La replica di Exchange richiede un utilizzo intensivo di risorse, in particolare su lunghe distanze. Data la natura transazionale del database Exchange, l'ordine di ciascuna operazione di scrittura riveste un'importanza fondamentale. A complicare ulteriormente la situazione è il fatto che il protocollo di trasporto utilizzato da Exchange per comunicare tutte le transazioni e le informazioni del sistema tra i server è SMTP, noto come protocollo che richiede un impiego intensivo di larghezza di banda. Inoltre, con i cluster Exchange è necessario mantenere un heartbeat tra i sistemi ogni 500 millisecondi. Se un nodo secondario non riceve l'heartbeat, potrebbe attivare l'avvio di un failover.
Le complessità insite nella gestione di tali problematiche potrebbero rappresentare la ragione per cui Microsoft si stia addentrando solo ora in questa area con Exchange 2007. In assenza di un prodotto Microsoft specifico, sono state sviluppate diverse soluzioni di terze parti che consentono di replicare i dati di Exchange mediante l'uso della replica basata su host o su array.
I fornitori hanno compreso che potevano estendere un cluster distribuendo i nodi in posizioni diverse, una tecnica definita cluster esteso. Oggi, il metodo più comune di implementazione dei cluster estesi è rappresentato dall'utilizzo di prodotti di replica dei dati di terze parti generici o di prodotti specificamente progettati per l'estensione di un nodo di Exchange. È possibile eseguire questa operazione con MSCS; tuttavia la necessità di utilizzo di subnet costituisce un requisito impegnativo su una rete WAN. Il clustering e le complessità correlate alla necessità di fornire una connettività a larghezza di banda elevata e affidabile ai centri dati remoti determinano comprensibilmente un incremento dei costi e della disponibilità di personale dedicato per creare, gestire e testare periodicamente i sistemi di ripristino di emergenza.

Replica continua cluster
Microsoft estende il suo supporto per i cluster con il meccanismo di replica continua cluster incluso in Exchange 2007. CCR estende la capacità della replica continua locale di gestire due copie dei registri delle transazioni e di un database di Exchange per implementare la stessa idea su due nodi cluster. Il ripristino di emergenza implica la separazione geografica di sistemi primari e secondari e i cluster a copia multipla (MCC) di Microsoft non saranno in grado di coprire distanze significative fino a quando Windows Server 2008, nome in codice precedente "Longhorn," non fornirà il supporto per i cluster estesi.
La tecnologia che consente a nodi MCC di disporre di copie separate di dati è definita maggioranza dei nodi (MNS, Majority Node Set), che indica il processo di elezione che due o più nodi eseguono per determinare quale nodo dispone della copia attiva dei dati. In caso di errore, i nodi rimanenti eseguono un nuovo processo di elezione per determinare quale nodo assumerà il controllo come nuovo server di elaborazione/dati primario. Il supporto di questa "democrazia tecnica" viene fornito da CCR, che assicura che ciascun nodo disponga di un database aggiornato. I cluster di Exchange 2007 che utilizzano CCR sono limitati a solo due nodi.
In ambienti di grandi dimensioni, i server Exchange in genere configurano il disco di sistema locale sul server stesso e si connettono al database di Exchange tramite una rete SAN utilizzando array di dischi SCSI, in fibra ottica o iSCSI. Con un cluster MCC/MNS, una domanda interessante riguarda la possibilità o meno che i gruppi di archiviazione di Exchange di fascia alta utilizzino di nuovo, come in passato, array RAID locali per ciascun nodo. Se lo scopo di un cluster MNS è consentire la disponibilità in ogni nodo di una archiviazione separata, ha senso continuare a configurare ciascun nodo in modo che faccia riferimento a una rete SAN il cui scopo principale consiste nel fornire un sistema di archiviazione comune?
Un probabile scenario di cluster MCC/MNS moderato prevede un nodo primario con archiviazione sulla rete SAN e un nodo cluster secondario con dischi locali o una rete SAN iSCSI a basso costo. Questo nodo secondario potrebbe trovarsi in una posizione remota rispetto al centro dati primario, in una sede che non dispone di un'infrastruttura SAN.
Indipendentemente dall'evoluzione di questa situazione, la configurazione MCC che prevede l'utilizzo di MNS e la tecnica CCR rappresentano un altro passo al livello superiore della gerarchia che conduce verso la ridondanza e la disponibilità migliorata in quanto più computer sono in grado di eseguire il failover e i dati vengono replicati in elementi di archiviazione separati. I dati sono ancora interamente confinati in un unico centro dati, almeno fino a quando non viene rilasciato Windows Server 2008. Windows Server 2008 fornirà il supporto nativo per i cluster estesi, consentendo la separazione geografica dei nodi in un cluster MNS, purché la latenza di rete tra i nodi sia inferiore a 500 ms. Fino ad allora (e oltre), la tecnologia cluster di terze parti può basarsi su Microsoft MNS e CCR per fornire la separazione geografica necessaria perché la tecnica del cluster esteso rappresenti una soluzione di ripristino di emergenza efficace.
Il clustering è collocato all'estremo più alto del continuum del ripristino di emergenza e la tecnica CCR è correttamente posizionata a un livello del continuum che la indica come soluzione di disponibilità elevata di Exchange. Anche se la combinazione di queste tecnologie può generare un certo overhead in termini di costi e di personale, è possibile prevedere che si rivelerà una soluzione di fascia alta davvero interessante per i clienti che desiderano utilizzare un ambiente Microsoft omogeneo.

Continuità operativa remota di terze parti
Non vi sono dubbi riguardo al fatto che la soluzione Microsoft e le estensioni di terze parti occuperanno l'estremo più alto del continuum del processo ripristino quando verranno rese disponibili. Il vantaggio principale di questa soluzione risiede nella capacità di failover automatico nel giro di pochi secondi. Tuttavia, non tutte le organizzazioni desiderano questo livello di disponibilità e continuità aziendale né possono permettersi di investire le centinaia di migliaia di dollari necessari per garantire tale continuità. Per molte aziende, una soluzione affidabile che garantisca il ripristino completo di Exchange in pochi minuti risponde perfettamente ai relativi requisiti di continuità operativa.
Ad esempio, Mimosa Systems, Inc. estende la continuità operativa all'interno di un singolo centro dati alla continuità remota. In una posizione remota, il piano di ripristino di emergenza di Mimosa consente di mantenere una copia di Exchange, di garantirne il costante aggiornamento in base ai registri delle transazioni forniti dal server Exchange primario e di rendere sempre disponibile questa copia attiva al server Exchange di standby. Il server Exchange remoto utilizza l'hardware standard e, analogamente all'implementazione di un singolo centro dati, è necessario tenerlo sempre attivo e sempre pronto per essere attivato in caso di emergenza. In caso di emergenza, un operatore nella sede remota avvia ed esegue il failover installando i file di database di standby, modificando il mapping per le cassette postali e i profili di Outlook. Tenere presente tuttavia che queste soluzioni di terze parti sono soggette alle limitazioni di supporto descritte nell'articolo della Knowledge Base "Politica di supporto Microsoft per i prodotti di terze parti che modificano o estraggono i contenuti del database di Exchange".

Conclusione
La protezione dei dati di Exchange è disponibile come un continuum di tecnologie e procedure che possono essere raggruppate in tre livelli in base al costo e alle funzionalità. Quando si esaminano i requisiti di tali tecnologie per la protezione dei dati di Exchange, è opportuno prendere in considerazione i tempi di inattività che i propri azionisti sono in grado di tollerare. Prestazioni migliori e tempi di ripristino più rapidi comportano costi maggiori, con le opzioni di fascia alta nell'ordine di cifre a cinque zeri. Sono disponibili soluzioni più convenienti che si avvicinano ma non raggiungono i più elevati livelli di disponibilità. Le scelte effettuate devono riflettere le esigenze reali della propria organizzazione.
Service Pack 1 per Exchange 2007
Attualmente in fase di beta testing, Service Pack 1 (SP1) per Exchange 2007 includerà numerose funzionalità non disponibili finora agli amministratori, tra cui miglioramenti a OWA, funzionalità GUI aggiuntive nella console e molto altro.
Di particolare interesse per gli amministratori che prevedono di utilizzare soluzioni di ripristino, Exchange 2007 SP1 include inoltre una terza soluzione di disponibilità a integrazione di LCR e CCR: replica continua secondaria (SCR). Si tratta di un "approccio di compromesso" e Microsoft mira a creare un'"configurazione ideale" in grado di offrire livelli più elevati di ripristino, senza la complessità insita nella " elevata disponibilità."
SCR consentirà la replica dei registri delle transazioni e del database di Exchange in un server Exchange differente rispetto a quello su cui risiedono in genere le cassette postali. La destinazione di SCR può essere locale o remota e può essere un cluster o un server Exchange di standby. Tuttavia, SCR non richiede un cluster in nessuna delle due posizioni e si differenzia da CCR in quanto la destinazione è un ambiente standby e il failover è un processo manuale. Tenere presente che è comunque necessario eseguire la prima copia di grandi dimensioni in rete, in sostanza un backup completo. Potrebbe essere necessario eseguire di tanto in tanto questa replica estesa tenendo tuttavia presenti le implicazioni sulla rete in uso, proprio come con CCR e le soluzioni di terze parti. Prevedo di assistere a un massiccio utilizzo sia di SCR che di CCR nonché di prodotti aggiuntivi che forniscono funzionalità simili e talvolta di maggiore valore.

Lee Benjamin gestisce ExchangeGuy Consulting Services in cui lavora direttamente con i clienti e fornisce servizi di consulenza ai partner Microsoft. Lee è presidente del più grosso gruppo di utenti Exchange al mondo, ExchangeServerBoston, e direttore del gruppo BostonUserGroups. Occupa inoltre il ruolo di MVP per Exchange, è Microsoft Certified Trainer e partecipa regolarmente come oratore a conferenze di settore.
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 Comunicazioni: Miglioramento della protezione con Windows Mobile 6
Comunicazioni Matt Fontaine

Miglioramento della protezione con Windows Mobile 6
Panoramica:
  • Protezione sul dispositivo
  • Protezione di Exchange Server
  • Protezione di rete

I dispositivi mobili aumentano la produttività dei professionisti in tutto il mondo, fornendo loro l'accesso alle informazioni aziendali e mantenendoli connessi anche quando sono fisicamente lontani
dalla sede. Gli aumenti di produttività sono reali: è sufficiente accendere il dispositivo mobile e iniziare a lavorare.
Sull'altro versante troviamo i professionisti IT che sono impegnati nel difficile compito di garantire la sicurezza e la stabilità dell'ufficio virtuale. Dal loro punto di vista, ogni dispositivo mobile rappresenta una potenziale falla nel sistema di protezione della rete che deve essere tamponata e una potenziale esposizione al furto di dati. Lo sviluppo di una distribuzione più sicura dei dispositivi mobili è cruciale, ma al tempo stesso è necessario garantire un utilizzo trasparente e intuitivo per gli utenti.
Microsoft® Windows Mobile® 6 e il suo predecessore, Windows Mobile 5.0 con Messaging and Security Feature Pack (MSFP), comprende numerose funzioni che aiutano a proteggere l'infrastruttura aziendale con semplicità e disagio minimo per gli utenti. L'utilizzo di Microsoft Exchange Server quale piattaforma di messaggistica consente di aumentare ulteriormente le opzioni di protezione disponibili. In questo articolo viene dimostrato come è possibile utilizzare Windows Mobile, Exchange Server e alcune procedure consigliate di protezione della rete come base per la protezione dei dispositivi mobili aziendali.

Architettura di comunicazione mobile
La pianificazione o l'aggiornamento di una distribuzione mobile comporta la valutazione di tre livelli: il dispositivo, il server dei messaggi e la rete (vedere la Figura 1). A livello di dispositivo, le difficoltà principali consistono nel consentire solo l'accesso autorizzato e impedire la presenza di applicazioni non autorizzate. Windows Mobile aiuta a impedire l'accesso non autorizzato al dispositivo tramite l'autenticazione PIN e la protezione con password, il timeout di blocco del dispositivo e la possibilità di "cancellare" la memoria del dispositivo in modalità locale o remota se viene perduto o rubato. È supportata la crittografia dati del canale di comunicazione e l'archiviazione rimovibile. È inoltre essenziale impedire l'installazione di applicazioni non autorizzate quali virus o spyware o l'accesso a parti critiche del dispositivo. La protezione a livello di dispositivo viene ottenuta grazie a una combinazione di definizione dei ruoli di gestione, livelli di accesso dell'applicazione, impostazioni di firma codice, impostazioni di protezione e certificati di protezione.
Figura 1 Livelli di comunicazione mobile
Figura 1 Livelli di comunicazione mobile
Il livello di protezione successivo è il server di messaggistica, quale ad esempio, Exchange Server 2003 con Service Pack 2 (SP2) o Exchange Server 2007. Questo livello comprende la protezione dei messaggi, ovvero la tecnologia che consente la trasmissione sicura da e verso i dispositivi, e l'interazione tra il server dei messaggi e il dispositivo mobile tramite Exchange ActiveSync®. L'utilizzo di dispositivi Windows Mobile non richiede Exchange Server, ma il suo impiego offre vantaggi in termini di costo, scalabilità, prestazioni e amministrazione.
Procedure consigliate di protezione a livello di dispositivo e di server di messaggistica sono importanti, ma anche la protezione del livello di rete è altrettanto critica. Grazie alla configurazione della rete aziendale in base alle procedure consigliate e all'implementazione di efficaci protocolli di protezione, è possibile contribuire a impedire danni alla rete anche se uno o più dispositivi mobili vengono compromessi.

Criteri di protezione sul dispositivo
La prima linea di difesa contro le violazioni della protezione è costituita dal dispositivo Windows Mobile stesso. Il sistema operativo Windows Mobile garantisce estesi servizi di protezione a livello di dispositivo che supportano i servizi di autenticazione, crittografia della scheda di memoria, rete privata virtuale (VPN), crittografia Wi-Fi e Secure Socket Layer (SSL). La protezione a livello di dispositivo coinvolge la gestione di chi può accedere a un dispositivo e ai relativi dati, il controllo delle applicazioni che possono essere eseguite sul dispositivo e la definizione della modalità di trasmissione dei dati da e verso il dispositivo. In generale, gli amministratori dispongono di un buon livello di flessibilità nell'impostazione e applicazione dei criteri di protezione su Windows Mobile 5,0 con MSFP e Windows Mobile 6.
L'accesso utente è gestito tramite un PIN o l'autenticazione con password. Un dispositivo può essere impostato per bloccarsi automaticamente dopo un periodo di inattività o dopo lo spegnimento, richiedendo lo sbocco da parte dell'utente per utilizzarlo nuovamente (vedere la Figura 2). Le specifiche di controllo dell'accesso utente sono stabilite da criteri di protezione, che possono essere modificati in base al ruolo di protezione dell'amministratore.
Figura 2 Impostazione di criteri password
Figura 2 Impostazione di criteri password
I criteri di protezione definiscono i livelli globali di protezione del dispositivo mobile (vedere la Figura 3). I ruoli di protezione determinano chi può impostare e modificare questi criteri di protezione. Il ruolo Manager, solitamente riservato agli operatori mobili, fornisce il controllo completo sulle impostazioni dei criteri di protezione. Il ruolo Enterprise è utilizzato da Exchange per gestire alcuni criteri di dispositivo, che vengono configurati dall'amministratore di Exchange. A seconda del contratto stipulato con il fornitore del dispositivo, è possibile personalizzare i criteri di protezione per l'azienda.
Figure 3 Criteri di protezione per i dispositivi mobili (Close Figure 3)

Criterio Dispositivo mobile
Blocco dell'ingresso non autorizzato nel dispositivo

Windows Mobile 5.0 con MSFP

Specificare che l'utente deve sempre eseguire l'autenticazione sul dispositivo per sbloccarlo o consentire che l'utente immetta un PIN sul desktop.
Ruolo predefinito: Responsabile, organizzazione.

Windows Mobile 6

Consentire o negare l'autorizzazione utente per modificare le impostazioni di crittografia mobili dei supporti di archiviazione rimovibili.
Ruolo predefinito: Responsabile, organizzazione.
Specificare se l'utente deve eseguire l'autenticazione sul dispositivo quando è connesso se il blocco del dispositivo è attivo. Ruolo predefinito: Responsabile, organizzazione.
Proteggere i dati riservati in caso di furto o perdita del dispositivo

Windows Mobile 5.0 con MSFP

Specificare che l'utente deve sempre eseguire l'autenticazione sul dispositivo per sbloccarlo o consentire che l'utente immetta un PIN sul desktop.
Ruolo predefinito: Responsabile, organizzazione.

Windows Mobile 5.0 con MSFP e Windows Mobile 6

Specificare se deve essere configurata una password sul dispositivo. Configurare le impostazioni di cancellazione del dispositivo locali e remote.
Ruolo predefinito: Responsabile, organizzazione.
I metodi di autenticazione personalizzabili utilizzati da Windows Mobile sono controllati dai Local Authentication Plug-In (LAP), che interagiscono con il Local Authentication Subsystem (LASS). Questa tecnologia consente a Exchange Server di controllare la configurazione del dispositivo a un livello granulare, ad esempio, applicando requisiti di lunghezza e complessità della password o attivando l'autenticazione PIN semplice.
Windows Mobile 6 comprende un ampio set di funzioni LAP che vengono configurate mediante Exchange Server 2007. È possibile attivare il riconoscimento dello schema di PIN (ad esempio, vietando l'utilizzo di schemi semplici come "1111" o" 1234"), configurare i periodi di scadenza di password o PIN, consentire agli utenti di richiedere la reimpostazione di un PIN in base a determinate condizioni o conservare la cronologia PIN/password per impedire agli utenti di riutilizzare PIN o password precedenti quando devono crearne di nuovi.

Protezione dei dati sui dispositivi
Nel caso un PIN o una password non corretto venga immesso per un numero di volte superiore al limite stabilito dall'amministratore, la funzione locale di cancellazione esegue una reimpostazione hardware del dispositivo, cancellandone la memoria, comprese le credenziali di autenticazione utente. Il limite viene impostato come parte dei criteri di protezione in Exchange Server. Dopo due immissioni non corrette, il dispositivo chiede all'utente di immettere una stringa chiave strutturata per continuare (vedere la Figura 4). Ciò impedisce che il dispositivo venga cancellato accidentalmente a causa di pressioni casuali dei tasti. Quando si utilizza Windows Mobile 6 ed Exchange Server 2007 è anche possibile la cancellazione in modalità remota della scheda di memoria.
Figura 4 Applicazione dell'uso di PIN e password
Figura 4 Applicazione dell'uso di PIN e password
Il blocco di un dispositivo non è consigliabile se qualcuno dimentica una scheda di memoria da 2 GB con dati aziendali riservati in un taxi. Fortunatamente, Windows Mobile 6 consente di affrontare anche questo problema. È possibile crittografare i dati della scheda di memoria in modo che possano essere letti solo dal dispositivo che li ha scritti. Analogamente a molte altre funzioni avanzate di protezione di Windows Mobile 6, Exchange Server 2007 può essere utilizzato per eseguire il provisioning via radio di questa funzione di protezione. La crittografia delle schede di memoria è del tutto trasparente per l'utente. Exchange Server 2007 consente all'amministratore di scegliere se gli utenti possono modificare le impostazioni di crittografia della scheda di memoria.
La possibilità di un'applicazione di essere eseguita o meno su un dispositivo Windows Mobile è basata su tre livelli di autorizzazione: Privilegiato, Normale e Bloccato. Le applicazioni di livello privilegiato (con firma di un certificato nell'Archivio certificati privilegiato) possono scrivere sui file del Registro di sistema e di sistema e possono anche installare certificati. Analogamente a un computer desktop o server, tanto maggiore è il numero di applicazioni che possono modificare l'ambiente del sistema operativo, tanto maggiore è la possibilità di compromettere tale ambiente. È generalmente buona norma ridurre il numero di applicazioni con accesso Privilegiato. La maggior parte delle applicazioni deve essere eseguita solamente a livello Normale (applicazioni con firma di un certificato nell'archivio certificati Unpriv o applicazioni senza firma che l'utente ha accettato di eseguire), che ne consente l'esecuzione senza però accedere ai file di sistema. Le applicazioni bloccate sono proprio questo: vengono bloccate e non possono essere eseguite a causa di una firma o di un'azione dell'utente non corretta.
I dispositivi possono prevedere una configurazione dell'accesso di protezione a uno o due livelli. Con una configurazione di accesso a un livello, le applicazioni senza firma vengono eseguite con l'accesso Privilegiato o vengono bloccate e semplicemente non possono essere eseguite. Una configurazione di accesso a due livelli eseguirà le applicazioni senza firma a livello normale se le verifica dei criteri è corretta o se l'utente autorizza l'esecuzione dell'applicazione. A seconda delle impostazioni del dispositivo, all'utente può essere richiesto o meno se eseguire un'applicazione senza firma.
I certificati digitali, una delle forme più comunemente utilizzate di autenticazione personale, dei dispositivi e delle applicazioni, costituiscono una parte cruciale della protezione di Windows Mobile sui livelli di dispositivo, server e rete. Il sistema operativo Windows Mobile memorizza alcuni tipi di certificati in diversi archivi certificati sul dispositivo. Per quanto riguarda le applicazioni, i certificati determinano quelle che possono essere installate ed eseguite. Perché venga eseguita su un dispositivo Windows Mobile senza chiedere conferma all'utente, un'applicazione deve essere firmata con un certificato comprovante l'avvenuta accettazione da parte del programma Microsoft Mobile2Mobile. Alle applicazioni vengono concessi livelli di autorizzazione basati sui certificati a cui sono associate.
Per l'autenticazione di rete, ciascun dispositivo mobile è provvisto di vari certificati principali commerciali attendibili emessi da un'autorità di certificazione (CA) come illustrato nella Figura 5. Prima di stabilire una connessione SSL con un dispositivo, il server di messaggistica (ad esempio, Exchange Server) verifica l'autenticità del relativo certificato principale. Un'azienda che utilizza certificati personalizzati può installarli sui dispositivi Windows Mobile che vengono acquistati o crearne di nuovi. Questo argomento verrà ripreso ulteriormente nella sezione Protezione di rete di questo articolo.
Figura 5 Gestione dei certificati digitali
Figura 5 Gestione dei certificati digitali
ActiveSync e Internet Explorer® Mobile sono in grado di utilizzare SSL per agevolare la protezione della trasmissione di dati tra il dispositivo e un server Web aziendale. Ciò vale nel caso la connessione esista per sincronizzare i dati di Microsoft Exchange, configurare il dispositivo o eseguire il download di applicazioni. SSL crittografa il canale di comunicazione con crittografia RC4 o 3DES a 128 bit in modo che i dati non possano essere letti da estranei. Windows Mobile supporta anche VPN, che utilizza la crittografia di pacchetto per fornire una protezione simile a quella di una linea dedicata durante l'accesso a un server in Internet.

Protezione di Exchange Server
Anche se il funzionamento dei dispositivi Windows Mobile non richiede Exchange Server, i due sistemi sono stati progettati per operare in stretta collaborazione e presentano una solida soluzione di messaggistica e produttività mobile end-to-end. Dal rilascio di Windows Mobile 5.0 con MSFP, ActiveSync è stato migliorato per consentire la gestione remota delle impostazioni dei dispositivi Windows Mobile. Offre un mezzo facile e al tempo stesso potente per applicare impostazioni di protezione globali sulla maggior parte dei dispositivi Windows Mobile.
ActiveSync funziona su IIS, il componente di applicazione/server Web di Microsoft Windows Server 2003. IIS offre protezione incorporata che aiuta a proteggere ActiveSync stesso da attacchi provenienti dalla rete. Poiché anche Microsoft Office Outlook® Web Access (OWA) è basato su IIS, è possibile utilizzare gli stessi certificati di protezione sia per ActiveSync che per OWA.
Quando ActiveSync viene utilizzato per propagare un criterio organizzativo, tale criterio viene recapitato ai dispositivi nel corso della successiva sincronizzazione con Exchange Server. Gli utenti devono accettare le modifiche altrimenti non possono connettersi al server. Molte reti devono gestire un'ampia varietà di dispositivi, compreso hardware legacy che non è in grado di accettare criteri di protezione sofisticati. Se necessario, è possibile escludere dall'obbligo del criterio di protezione determinati dispositivi, quali l'hardware legacy in modo che possa continuare a connettersi.
Le funzionalità di controllo dei criteri di protezione di Exchange Server 2003 SP2 ed Exchange Server 2007 sono piuttosto diverse. Exchange Server 2003 SP2 può essere utilizzato per specificare una lunghezza minima della password da 4 a 18 caratteri, richiedere la presenza di numeri e lettere in una password e impostare la durata di un periodo di inattività prima che un dispositivo si blocchi. Questa versione di Exchange Server è anche in grado di impostare la frequenza con cui le impostazioni di protezione vengono trasmesse ai dispositivi oltre a consentire le esenzioni summenzionate per i dispositivi legacy.
Con il rilascio di Exchange Server 2007, le funzionalità di gestione dei dispositivi mobili di ActiveSync sono state migliorate per includere tutte le funzionalità di Exchange Server 2003 SP2, oltre alle seguenti:
  • Consentire o meno l'uso di password semplici (quali "1234" o" 1111")
  • Attivare o disattivare il download di allegati
  • Richiedere la crittografia delle schede di memoria
  • Impostare la dimensione massima degli allegati
  • Attivare il ripristino della password di un dispositivo da parte dell'utente tramite OWA
  • Attivare l'accesso ai file UNC (Universal Naming Convention) e Microsoft Windows SharePoint® Services (WSS)
Tramite Exchange Server 2007, i professionisti IT dispongono della flessibilità per adattare i criteri a ciascun utente o dispositivo, gestire i criteri per gruppi di utenti ed escludere completamente utenti specifici dai criteri di protezione.

Cancellazione tramite accesso remoto
Oltre alla cancellazione del dispositivo locale descritta in precedenza, è possibile cancellare un dispositivo Windows Mobile in modalità remota utilizzando Exchange Server 2003 SP2, Exchange Server 2007 o OWA. Le cancellazioni in modalità remota, che hanno luogo al momento della sincronizzazione, possono essere eseguite anche se non vengono utilizzati i criteri di protezione di ActiveSync. Non è possibile interrompere una reimpostazione hardware con cancellazione in modalità remota dal dispositivo. Dati, impostazioni, e chiavi di protezione vengono sovrascritti con valori zero ripetuti che rendono estremamente difficile il ripristino di qualsiasi dato che non appartiene al sistema operativo di base.

Protezione di rete
La protezione di rete per la protezione mobile è importante tanto quanto i componenti dispositivo e server di messaggistica. È anche la parte dell'infrastruttura mobile che è più chiaramente sotto controllo. Anche se uno o più dispositivi mobili vengono compromessi, la configurazione della rete aziendale in base alle procedure consigliate e l'implementazione di protocolli di protezione adeguati possono aiutare a impedire qualsiasi danno alla rete.
Windows Mobile funziona bene con vari tipi di rete. L'utilizzo di protocolli di protezione Internet standard e di firewall consente di progettare una soluzione adeguata alle esigenze di prestazioni, stabilità e protezione.
Quando i server di messaggistica vengono tenuti all'interno della rete aziendale, possono essere protetti da un firewall perimetrale con la funzione di cuscinetto tra Internet e i server aziendali. Microsoft Internet Security and Acceleration (ISA) Server 2004 o ISA Server 2006, entrambi dotati di funzionalità progettate appositamente a questo scopo, ispeziona tutti i pacchetti in arrivo per determinarne l'identità prima di consentire il passaggio ai server Exchange, quindi restituisce le informazioni in uscita al client tramite Internet.
La configurazione di ISA Server richiede l'attivazione della crittografia SSL e la designazione della porta 443 come porta di ascolto Web SSL per il traffico di Exchange Server. Questo riduce al minimo l'esposizione in Internet limitandola a una singola porta. Inoltre, prima di connettersi tramite ActiveSync tutti i client sono obbligati a stabilire un collegamento SSL.
ISA Server è in grado di autenticare preventivamente gli utenti di applicazioni Web quali OWA per aiutare a impedire che utenti non autenticati raggiungano i server di applicazioni. ISA Server 2006 migliora il modello di bridging SSL di ISA Server 2004 operando come punto di terminazione SSL per i dispositivi Windows Mobile. Questo consente ai dispositivi Windows Mobile di eseguire l'autenticazione con il server Exchange senza stabilire alcuna connessione diretta e affidandosi invece a ISA Server 2006 per il passaggio del traffico in entrambe le direzioni. Inoltre, poiché la posizione consigliata di ISA Server 2006 è nella rete perimetrale, questo offre un livello di protezione aggiuntivo tra Internet e il front-end di Exchange Server.

Autenticazione
Sono disponibili due tipi di autenticazione di base tra cui scegliere: base e basata sui certificati. Il tipo base si riferisce a una connessione SSL standard con nome e password tra un client Windows Mobile e il server front-end di Exchange. Richiede comunque un certificato perché prima di procedere all'autenticazione Exchange Server cerca un certificato principale corrispondente sul dispositivo. Windows Mobile ed IIS consentono di utilizzare l'ampia varietà di metodologie di crittografia associate a SSL.
L'autenticazione basata sui certificati, che è disponibile sia in Windows Mobile 5.0 con MSFP che in Windows Mobile 6, utilizza TLS (Transport Layer security) invece dell'autenticazione di base SSL. Oltre al certificato principale, TLS richiede che ogni utente disponga di un certificato con chiavi pubbliche e private. Poiché TLS utilizza una chiave di crittografia (fino a 2.048 bit) invece di una password, questo protocollo offre un'autenticazione più efficace.
Con Windows Mobile 6, la registrazione di un certificato utente mediante Desktop Enroll richiede che il dispositivo sia agganciato a un desktop che si trova nello stesso dominio del server di registrazione del certificato. L'utente autentica la registrazione mediante una password, una smart card o un altro metodo, quindi connette il dispositivo a un computer desktop. L'utente accede quindi al sistema di certificati tramite il desktop che, a sua volta, installa il certificato sul dispositivo mobile. Desktop Enroll è in grado di svolgere varie funzioni di protezione di Windows Mobile, tra cui il rinnovo del certificato e la distribuzione di certificati di autenticazione ActiveSync, certificati di autenticazione SSL/TLS, certificati Wi-Fi 802.1x o certificati con firma digitale S/MIME.
I protocolli di protezione quali SSL proteggono i dati dei messaggi in transito, ma non li crittografano quando arrivano sul dispositivo Windows Mobile o sul server Exchange. S/MIME è un formato sicuro del familiare standard MIME che supporta la posta elettronica con firma digitale e/o crittografata. Questo offre un ulteriore livello di protezione che si aggiunge alla crittografia del livello di trasporto SSL.

Conclusioni
La creazione di un'infrastruttura che sia sufficientemente sicura richiede che venga dedicata attenzione a ciascuno dei molti livelli che compongono una soluzione. Windows Mobile, Exchange Server e prodotti per la protezione di rete Microsoft quali ISA Server collaborano reciprocamente per alleviare una gran parte dei problemi di gestione dell'infrastruttura mobile. Ciò contribuisce ad attenuare una parte della pressione posta sui reparti IT, spostando l'attenzione dalle sfide della protezione create dai dispositivi mobili per privilegiare gli incrementi di produttività che questi mettono a disposizione.

Un ringraziamento particolare a Kathy Esser, Katharine Holdsworth, Sarah Norton e Chip Vollers per l'assistenza fornita nella realizzazione di questo articolo.

Matt Fontaine è uno scrittore che si occupa di tecnologia per BuzzBee Company.


 Comunicazioni: Una valida alternativa alle cartelle pubbliche
Comunicazioni Alan Maddison

Una valida alternativa alle cartelle pubbliche
Panoramica:
  • Condivisione di calendari e contatti
  • Comunicazioni con blog e wiki
  • Condivisione e gestione dei documenti

Le cartelle pubbliche esistono dalla prima versione di Microsoft Exchange e hanno lo scopo principale di fornire una piattaforma di base per condividere i documenti, archiviare le liste di distribuzione e sviluppare le applicazioni personalizzate. Sin dal principio,
tuttavia, gli amministratori si sono impegnati per gestire e utilizzare quella che è diventata una parte sempre più complessa degli ambienti Exchange. Sebbene Exchange Server 2007 abbia introdotto alcuni notevoli miglioramenti nella gestione delle cartelle pubbliche, la sfida da affrontare rimane. Le cartelle pubbliche non forniscono la solida piattaforma di collaborazione e gestione dei documenti richiesta attualmente dalle aziende.
Microsoft ha dichiarato che Exchange Server 2007 potrebbe essere l'ultima versione del prodotto che supporta le cartelle pubbliche. Sebbene queste siano ancora supportate e sebbene lo saranno per i prossimi 10 anni successivi al lancio di Exchange Server 2007, è opportuno esaminare una valida alternativa.
Fortunatamente, Microsoft ha fornito un'opzione interessante con il lancio di Microsoft® Office SharePoint® Server (MOSS) 2007 che offre la piattaforma richiesta dagli amministratori IT e dalle aziende per sostituire e spostare le funzionalità garantite dalle cartelle pubbliche. In quest'articolo, dimostrerò il motivo per il quale MOSS è considerato una struttura solida e importante che può offrire molte più funzionalità rispetto alle cartelle pubbliche di Exchange. In particolare, mi concentrerò sull'uso di SharePoint per le attività svolte solitamente tramite le cartelle pubbliche, ad esempio la condivisione di calendari, contatti e documenti.
È importante ricordarsi che le cartelle condivise saranno sempre necessarie finché non si esegue l'aggiornamento dei client. I client Microsoft Outlook® da Outlook 97 a Outlook 2003 richiedono le cartelle pubbliche per diversi motivi, tra cui le rubriche fuori rete, la Libreria moduli organizzazione e la ricerca delle disponibilità. Una volta passati a Outlook 2007 e Exchange Server 2007, è possibile non utilizzare più le cartelle pubbliche.

Calendari SharePoint
I calendari condivisi sono di uso comune per le cartelle pubbliche e SharePoint semplifica la sostituzione di un calendario delle cartelle pubbliche con un calendario SharePoint. Sebbene un'installazione predefinita di un sito di SharePoint contenga un calendario, sarà probabilmente necessario creare più calendari per soddisfare le esigenze aziendali. Per dimostrare quanto appena detto, spiegherò dettagliatamente la creazione di un calendario condiviso per un team delle risorse umane. Per prima cosa, è necessario selezionare Visualizza tutto il contenuto del sito, opzione solitamente disponibile nell'angolo superiore sinistro del sito di SharePoint (vedere la Figura 1).
Figura 1 Creazione del contenuto del nuovo sito
Figura 1 Creazione del contenuto del nuovo sito
Una volta selezionato Visualizza tutto il contenuto del sito, scegliere il pulsante Crea (illustrato nella Figura 1). Una volta caricata la pagina Crea, verranno visualizzate le opzioni del tipo di contenuto predefinito (come illustrato nella Figura 2). Per creare un calendario, è necessario scegliere Calendario nella colonna Analisi. Quindi, riempire i campi del nome e della descrizione e scegliere se includere il calendario nella sezione Collegamenti rapidi.
Figura 2 Nella pagina Crea vengono visualizzate le opzioni predefinite
Figura 2 Nella pagina Crea vengono visualizzate le opzioni predefinite
A questo punto, il calendario è stato creato. L'utente ha l'opzione di visualizzare il calendario condiviso dal sito di SharePoint o direttamente da Outlook. Per la seconda opzione, l'utente deve connettersi al calendario utilizzando il proprio browser Web, aprire il menu Azioni e scegliere l'opzione Connetti a Outlook.
Quando la connessione viene stabilita per la prima volta, Outlook visualizza un avviso di protezione per ricordare agli utenti che devono collegarsi solo a fonti conosciute e attendibili. Una volta scelto Sì, il calendario sarà connesso a Outlook. Nella Figura 3 viene illustrata la vista predefinita con il calendario SharePoint e il calendario Outlook affiancati.
Figura 3 Visualizzazione del calendario SharePoint e del calendario Outlook affiancati
Figura 3 Visualizzazione del calendario SharePoint e del calendario Outlook affiancati
Una volta connesso a Outlook il calendario, può verificarsi una sincronizzazione bidirezionale. Tutti gli eventi inseriti tramite Outlook vengono sincronizzati con SharePoint e tutti gli utenti che possono visualizzare il calendario, visualizzeranno anche le voci aggiornate. Inoltre, se in SharePoint è stato attivato il supporto SMTP, è possibile inviare tramite posta elettronica gli eventi direttamente al calendario e SharePoint aggiungerà queste voci.

Contatti SharePoint
I contatti condivisi, che si basano sempre sulle cartelle pubbliche, vengono utilizzati da molte organizzazioni. Inoltre, SharePoint fornisce un'alternativa più valida, semplificando la creazione e la gestione degli elenchi dei contatti. Continuando con lo stesso esempio, illustrerò il modo in cui è possibile creare un elenco contatti condiviso per il suddetto reparto delle risorse umane.
Ancora una volta, selezionare Visualizza tutto il contenuto del sito e scegliere il pulsante Crea. Selezionare il collegamento Contatti nella colonna Comunicazioni. Viene visualizzata una schermata in cui è possibile trovare le informazioni per la configurazione del nome, della descrizione e del collegamento rapido (vedere la Figura 4). Una volta specificate queste informazioni, selezionare il pulsante Crea e il nuovo Elenco contatti viene creato.
Figura 4 Completamento della configurazione del nome, della descrizione e del collegamento rapido
Figura 4 Completamento della configurazione del nome, della descrizione e del collegamento rapido

Comunicazione utente
È possibile utilizzare SharePoint per creare un'area discussioni (nota anche come lista discussioni). Allo stesso modo dei calendari e dei contatti, il processo di creazione è molto semplice (selezionare Visualizza tutto il contenuto del sito, scegliere il pulsante Crea e fare clic sul collegamento Area discussioni nella colonna Comunicazioni). Come si è fatto in precedenza, immettere le informazioni appropriate per la configurazione del nome, della descrizione e del collegamento rapido e scegliere il pulsante Crea. Nella Figura 5 viene illustrata un'area discussioni con alcuni messaggi di esempio.
Figura 5 Area discussioni di esempio con un paio di messaggi
Figura 5 Area discussioni di esempio con un paio di messaggi
Oltre alle aree discussioni, SharePoint Server supporta anche due strumenti di comunicazione molto popolari: i blog e i wiki. Non disponibili con le cartelle pubbliche, i blog e i wiki rappresentano una novità di SharePoint Server 2007 e forniscono funzionalità di collaborazione eccezionali.
I blog forniscono un forum interattivo in cui un blogger può condividere facilmente pensieri e idee inviando messaggi a un sito Web. Solitamente, questi messaggi vengono classificati in modo da semplificare ai lettori la ricerca dei messaggi desiderati. Nel frattempo, i lettori possono fornire risposte ai commenti dei blogger. In un'azienda, ad esempio, è possibile che i membri dell'esecutivo facciano parte di un blog. Un blog può rappresentare uno strumento prezioso per comunicare con i propri dipendenti e fornisce allo staff un modo per condividere idee ed entrare in contatto con tutti i livelli dell'azienda.
Creare un blog in SharePoint è semplice. La prima cosa da fare è selezionare Visualizza tutto il contenuto del sito, scegliere il pulsante Crea e fare clic su Siti e aree di lavoro nella colonna Pagine Web. In questo modo viene aperta la pagina del nuovo sito di SharePoint, in cui è necessario fornire il titolo, il nome e l'URL per il sito. Quindi, scegliere un modello per il sito, in questo caso scegliere il modello Blog. Le ultime tre opzioni di configurazione riguardano le autorizzazioni, l'esplorazione e l'elenco delle directory del sito. Dopo aver completato tutte le opzioni richieste, selezionare il pulsante Crea. In questo modo, all'interno del sito principale, viene creato un sito secondario contenente librerie ed elenchi che forniscono le funzionalità disponibili nel blog. Una volta terminato il processo, viene aperto il nuovo blog.
Un wiki è un altro straordinario strumento progettato per garantire una migliore collaborazione. Gli utenti possono aggiungere, rimuovere e modificare contenuto del sito, nonché unire più pagine. Il modo più semplice per creare un wiki è selezionare Visualizza tutto il contenuto del sito, fare clic sul collegamento Crea e scegliere Raccolta pagine Wiki nella colonna Raccolte. Dopo aver riempito i campi per la configurazione del nome, della descrizione e dell'esplorazione, scegliere il pulsante Crea. Per ulteriori informazioni sull'uso dei wiki in SharePoint, vedere l'articolo "Wiki al lavoro" nel numero di gennaio 2007 di TechNet Magazine.

Raccolte SharePoint
Le cartelle pubbliche sono diventate archivi di documenti e forniscono infatti una posizione centrale alla quale gli utenti possono accedere facilmente per condividere i propri documenti. Come gli amministratori Exchange hanno scoperto nel corso degli anni, questo è uno degli usi principali delle cartelle pubbliche che non solo causa l'aumento delle operazioni di I/O di Exchange per il database delle cartelle pubbliche, ma ha anche effetti sulla replica nell'infrastruttura di Exchange. Le raccolte SharePoint forniscono un'alternativa eccellente, riducendo le richieste per Exchange e le relative risorse.
Una raccolta SharePoint è una posizione all'interno di un sito di SharePoint che consente di memorizzare e gestire i file. Esistono diversi tipi di raccolte, tra cui Raccolta immagini, Raccolta pagine Wiki, Raccolta moduli e Raccolta documenti. Quando si pensa a una sostituzione per le cartelle pubbliche, la scelta più appropriata ricade sulla Raccolta documenti. Una Raccolta documenti supporta la memorizzazione, la gestione e, in alcuni casi, la creazione di documenti in un sito di SharePoint.
Molti tipi diversi di file possono essere memorizzati in una Raccolta documenti, ma alcuni, ad esempio i file eseguibili e script, sono vietati per motivi di sicurezza. Queste restrizioni, tuttavia, possono essere configurate nella sezione Operazioni del sito Amministrazione centrale SharePoint.
Un'installazione predefinita di MOSS comprende una Raccolta documenti personalizzabile. La maggior parte delle organizzazioni vorrà creare più raccolte per supportare le diverse unità aziendali, il che è semplice da fare utilizzando gli strumenti forniti da SharePoint. Ad esempio, per distribuire una Raccolta documenti per le risorse umane, selezionare Visualizza tutto il contenuto del sito, fare clic sul collegamento Crea e scegliere Raccolta documenti nella colonna Raccolte. Verranno visualizzate le impostazioni da configurare, sarà quindi necessario fornire un nome e una descrizione della raccolta, specificare se includere la raccolta nella sezione Collegamenti rapidi, scegliere se attivare il controllo delle versioni e selezionare il formato predefinito per i nuovi documenti creati direttamente nella raccolta.
Prestare particolare attenzione all'opzione Cronologia versioni documento. Per impostazione predefinita, l'opzione è disattivata. Tuttavia, il controllo delle versioni può essere utile e appropriato in molti ambienti. Oltre a memorizzare le copie cronologiche dei documenti, questa funzionalità tiene traccia delle date e degli autori delle modifiche apportate e offre la possibilità di visualizzare e ripristinare le versioni precedenti.
Nella Figura 6 viene illustrata la Raccolta documenti con alcuni documenti caricati. Una volta create le raccolte documenti, è possibile rendere disponibili questi archivi tramite Microsoft Outlook e Windows® Explorer. Outlook consente di mettere fuori linea il contenuto della Raccolta documenti e fornisce una copia di sola lettura per gli utenti che hanno accesso alla rete. Per fornire accesso tramite Esplora risorse si ricorre alle risorse di rete. Inserendo l'URL della Raccolta documenti, è possibile fornire accesso agli utenti. In ambienti di dimensioni maggiori, è possibile utilizzare i Criteri di gruppo per distribuire queste risorse di rete.
Figura 6 Raccolta documenti contenente alcuni documenti che sono stati caricati
Figura 6 Raccolta documenti contenente alcuni documenti che sono stati caricati

Oltre gli elementi di base
SharePoint fornisce un set di funzionalità di gran lunga superiori rispetto a quelle offerte dalle cartelle pubbliche. Oltre a garantire le stesse funzionalità fornite dalle cartelle pubbliche, SharePoint Server offre funzionalità più potenti che consentono di estendere l'utilità degli usi comuni. Tra queste funzionalità vi sono:
  • Cronologia delle versioni
  • Controllo delle approvazioni
  • Procedure di estrazione
  • Controllo dei flussi di lavoro
  • Criteri di conservazione dei documenti
  • Controllo
  • RSS
Le funzionalità come queste sono fondamentali per qualsiasi piattaforma di gestione del contenuto aziendale e SharePoint fornisce una solida struttura semplice da utilizzare. Questa funzionalità migliorata può essere attivata per molte delle funzionalità di SharePoint, tra cui Calendari, Attività, Aree discussioni e Raccolte documenti.
Per configurare questa funzionalità, selezionare il menu Impostazioni e scegliere l'opzione relativa alle impostazioni, ad esempio l'opzione Impostazioni raccolta documenti, come illustrato nella Figura 7. Verrà visualizzata la pagina Impostazioni in cui è possibile visualizzare tutte le opzioni di configurazione e personalizzazione disponibili. Il collegamento Impostazioni controllo versioni nella colonna Impostazioni generali, ad esempio, consente di configurare la cronologia delle versioni.
Figura 7 Selezione dell'opzione Impostazioni per configurare la funzionalità migliorata
Figura 7 Selezione dell'opzione Impostazioni per configurare la funzionalità migliorata
Come detto in precedenza, questa funzionalità fornisce un record delle modifiche dei documenti, specificando tra l'altro gli autori e le date delle modifiche apportate, e consente agli utenti di visualizzare e ripristinare versioni precedenti, se necessario. È anche possibile controllare il numero di versioni memorizzare da SharePoint. Una volta raggiunto il limite stabilito, gli elementi vengono eliminati senza essere inviati nel Cestino di SharePoint.
La sezione relativa al controllo delle versioni consente di configurare i requisiti per l'estrazione e l'approvazione del contenuto. Quando l'opzione Approvazione contenuto è attivata, prima di essere resi disponibili ad altri utenti, tutti gli elementi inviati devono essere approvati. Gli elementi che non sono stati approvati restano in sospeso. Il processo di estrazione fornisce il controllo del contenuto impedendo a più utenti di lavorare su uno stesso file contemporaneamente.
I flussi di lavoro rappresentano un'altra utile funzionalità offerta da SharePoint che manca alle cartelle pubbliche. Fondamentalmente, i flussi di lavoro offrono un approccio strutturato ai processi aziendali che può consentire di semplificare le operazioni aziendali. In SharePoint i flussi di lavoro sono una serie di attività predefinite che automatizzano lo spostamento di un documento nelle diverse fasi di un processo stabilito. Il processo può essere iterativo, il che richiede che ogni fase sia completata prima di passare alla successiva, o parallelo, il che consente a tutte le attività di essere completate in qualsiasi momento. I flussi di lavoro predefiniti inclusi in SharePoint sono:
  • Approvazione
  • Raccolta commenti e suggerimenti
  • Raccolta firme
  • Approvazione dell'eliminazione
I criteri di gestione delle informazioni vengono utilizzati per garantire la conformità ai regolamenti e ai requisiti aziendali. Un criterio è composto da una serie di regole relative alla gestione e al controllo dei documenti. SharePoint Server supporta regole personalizzate, ma anche regole predefinite, tra cui:
  • Controllo
  • Scadenza
  • Etichette
  • Codici a barre
Il Controllo consente di registrare gli eventi in base a una serie di azioni definite nelle impostazioni del sito. È possibile controllare queste azioni, ad esempio l'apertura di un documento, il download o la visualizzazione di un elemento o delle relative proprietà, la modifica di un documento, l'archiviazione o l'estrazione di un documento, lo spostamento o la copia di elementi e l'eliminazione o il ripristino di elementi.
La Scadenza del contenuto consente di eliminare il contenuto per mantenere la conformità con i criteri di conservazione dei dati aziendali. I dati possono scadere in una data particolare o allo scadere di un periodo prefissato di tempo in seguito a un evento, ad esempio la creazione di un documento.
Le Etichette vengono utilizzare in fase di stampa per aggiungere testo alle immagini. Nella pratica, questo criterio può essere utilizzato in diversi modi. Ad esempio, è possibile richiedere che tutti i documenti della Raccolta documenti condivisa delle risorse umane contengano un avviso sulla riservatezza per mantenere la conformità ai regolamenti dell'ufficio legale.
I Codice a barre forniscono un metodo di registrazione formale per i documenti in linea e cartacei. SharePoint creerà un identificatore univoco per ciascun documento e gli utenti possono inserire un'immagine del codice a barre nel proprio documento.
Un altro miglioramento significativo offerto da SharePoint è rappresentato dall'integrazione con i feed RSS. I calendari, le raccolte contatti e documenti e le aree discussioni forniscono un feed RSS al quale un utente può registrarsi. Gli utenti possono ricevere aggiornamenti automatici per tenere traccia delle proprie responsabilità giorno dopo giorno con un semplice lettore RSS, ad esempio Outlook 2007.

Per concludere
Microsoft Office SharePoint Server 2007 fornisce funzionalità aziendali e offre una più valida alternativa alle cartelle pubbliche di Exchange. Una struttura amministrativa solida consente di implementare semplicemente una soluzione per condividere calendari, contatti e documenti. È inoltre possibile creare diversi modi per comunicare, tra cui forum di discussioni, blog e wiki.

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


 Comunicazioni: Accesso a Outlook Web Access con smart card
Comunicazioni Victor Akinnagbe and Ted Dressel and Jason Opdycke

Accesso a Outlook Web Access con smart card
Panoramica:
  • Autenticazione a due fattori
  • Delega vincolata Kerberos
  • Configurazione di ISA Server e di Exchange

I dipendenti mobili rappresentano per le organizzazioni IT una delle principali problematiche correlate alla protezione. Gli utenti remoti necessitano di accesso protetto a dati e servizi, ad esempio la posta elettronica. La sfortunata realtà è che, tuttavia, i collegamenti
più deboli della catena di protezione coinvolgono password vulnerabili, malware (ad esempio keystroke logger) e virus sui computer remoti che tentano di accedere alle risorse interne dell'organizzazione.
Un metodo per aumentare la protezione nell'ambiente mobile consiste nel rimuovere uno di questi collegamenti vulnerabili, ovvero le password (anche se l'idea di consentire l'accesso a un account senza una password per l'autenticazione può destare non poca preoccupazione). Una delle principali tecniche utilizzate per eliminare i problemi associati alle password è nota come autenticazione a due fattori (talvolta chiamata autenticazione a più fattori). Anziché basarsi su un singolo metodo, una password, per consentire l'accesso, l'autenticazione a due fattori prevede l'utilizzo di metodi di autenticazione aggiuntivi, tra cui la combinazione di nome utente/password, un dispositivo fisico, come una smart card, o un identificatore biometrico, ad esempio un'impronta digitale.
In un'organizzazione con utenti mobili è necessario in genere aprire il firewall per consentire l'accesso remoto alla rete aziendale. Un firewall standard offre una strategia di riduzione dei rischi di base fornendo l'isolamento a livello di rete tra le reti interne ed esterne (vedere la Figura 1). Per garantire un livello di protezione aggiuntivo, le porte vengono semplicemente chiuse e, se occorre stabilire una comunicazione con un dispositivo sulla rete interna, le porte vengono inoltrate verso la posizione appropriata. Sebbene queste tecniche forniscano una protezione significativa a livello di rete, attualmente la crescente complessità degli attacchi impone la necessità di più livelli di protezione della rete.
Figura 1 Firewall standard con porte bloccate o inoltrate
Figura 1 Firewall standard con porte bloccate o inoltrate
Poiché i servizi aziendali più comuni generalmente utilizzati dai dipendenti mobili sono la posta elettronica e la messaggistica, la configurazione dell'infrastruttura Exchange in modo protetto riveste più che mai un'importanza cruciale. Consentire l'accesso degli utenti alla posta elettronica tramite Outlook® Web Access (OWA) rappresenta una soluzione per fornire servizi protetti ai dipendenti mobili. Un altro metodo chiave consiste nel garantire una autenticazione a due fattori più protetta per OWA tramite smart card. In questo articolo verranno esaminati nel dettaglio i problemi di configurazione e di installazione che è opportuno tenere in considerazione quando si attiva la distribuzione OWA abilitata all'utilizzo di smart card.

Soluzione migliore di un firewall
L'utilizzo di Microsoft® Internet Security and Acceleration (ISA) Server 2006 sulla rete può semplificare l'attività di apertura della rete agli utenti remoti in modo più protetto. ISA Server 2006 include diverse funzionalità per il miglioramento della protezione, quale la rete privata virtuale (VPN) abilitata all'utilizzo di smart card, autenticazione LDAP (Lightweight Directory Access Protocol) ad Active Directory® e delega vincolata Kerberos. ISA Server presenta delle lievi differenze rispetto a un firewall standard. Fornisce più livelli di protezione non solo operando a livello di rete, (questa protezione aggiuntiva viene fornita sia che venga utilizzato in sostituzione che in combinazione con firewall hardware standard), ma anche fornendo funzionalità di protezione aggiuntive non supportate in genere dai firewall tradizionali, come i filtri applicazione. Non si desidera fornire la possibilità di utilizzare il metodo HTTP POST per uno specifico sito Web ospitato? Si desidera forzare la conformità RFC nei messaggi SMTP prima che raggiungano il server Exchange? Si desidera controllare i pacchetti HTTP SSL (Secure Sockets Layer) prima che vengano trasmessi in rete? ISA Server è in grado di gestire tutte queste attività e molto altro per assicurare che venga inoltrato alla rete interna o perimetrale solo traffico filtrato e pulito.
Le sessioni SSL rappresentano in qualche modo un problema per i firewall standard. Mentre passano attraverso il firewall, i pacchetti rimangono crittografati (il che indica che SSL funziona correttamente). Pertanto, se un'applicazione come OWA viene pubblicata attraverso un firewall hardware o software mediante SSL, l'unico tipo di controllo apprezzabile che può essere eseguito dal firewall standard è l'ispezione del contenuto dei pacchetti. Le semplici attività di apertura e inoltro delle porte possono lasciare esposta una significativa area della superficie di attacco. Poiché non viene eseguita alcuna ispezione effettiva al confine della rete, è possibile che vengano instradati verso la rete interna pacchetti non ispezionati e non autenticati.
ISA Server 2006 può fungere da endpoint SSL per i client HTTP, assicurando che solo il traffico autenticato raggiunga il server Exchange pubblicato. ISA Server supporta una funzionalità molto utile denominata bridging SSL. In genere, un pacchetto viene crittografato da un client che sta comunicando tramite una sessione SSL standard con ISA Server. Grazie alla funzionalità bridging SSL, ISA Server è in grado di terminare la crittografia SSL in modalità locale, ispezionare il pacchetto non crittografato, autenticare l'utente ad Active Directory (se necessario), crittografare nuovamente il pacchetto mediante SSL e passare il pacchetto crittografato al server Exchange appropriato (vedere la Figura 2). Utilizzando questa tecnica, bridging SSL consente di ridurre gli attacchi nascosti all'interno di una sessione SSL camuffati in maniera tale da sembrare nient'altro che BLOB crittografati di dati trasmessi a un firewall non compatibile con l'applicazione.
Figura 2 Una vista del traffico a livello di applicazione in ISA Server
Figura 2 Una vista del traffico a livello di applicazione in ISA Server
Il traffico preautenticato che raggiunge il server è un importante punto da tenere presente quando si parla di delega vincolata Kerberos. In un firewall standard, le porte vengono semplicemente inoltrate al server Exchange e lo stesso server front-end è responsabile per l'esecuzione delle attività di autenticazione per coloro che potrebbero rivelarsi utenti malintenzionati. Quando l'autenticazione è necessaria, ISA Server è in grado di contattare direttamente Active Directory ed effettuare la richiesta di credenziali per conto dell'utente. Se l'utente viene autenticato, ISA Server inoltrerà il messaggio al server front-end Exchange. Il server front-end non deve più eseguire l'autenticazione di richieste casuali di utenti sconosciuti e può essere utilizzato esclusivamente per inviare tramite proxy le richieste ai server back-end. ISA Server 2006 inoltre può utilizzare la delega vincolata Kerberos per consentire l'accesso basato sui certificati a tecnologie come Windows SharePoint Services ed Exchange ActiveSync.
Exchange Server 2003 includeva il supporto per l'autenticazione basata su Kerberos tra i server front-end e back-end per gli account di accesso OWA (per proteggere il traffico di questo client occorre utilizzare il protocollo IPsec). Exchange Server supporta inoltre l'autenticazione Kerberos per i server cassette postali cluster.

Attivazione dell'autenticazione basata su smart card
L'implementazione dell'autenticazione basata su smart card per OWA ha rappresentato una vera e propria sfida. Tuttavia, è stata sviluppata una soluzione basata sulla funzionalità di delega vincolata Kerberos, ora disponibile in ISA Server 2006. La soluzione consente a un utente di inviare le credenziali tramite un certificato per eseguire l'autenticazione a OWA. La delega vincolata Kerberos è un miglioramento che è stato accolto con maggiore entusiasmo rispetto al supporto della delega Kerberos in Windows® 2000, che prevedeva l'utilizzo della delega non vincolata. La funzione vincolata di Kerberos garantisce maggiore protezione e limita il potenziale rischio di attacchi sofisticati che fanno uso della rappresentazione.
Nello scenario abilitato all'utilizzo di smart card, ISA Server 2006 contatta Active Directory per eseguire l'autenticazione dell'utente in quanto l'utente non dispone di accesso instradabile a un centro distribuzione chiavi (KDC, Key Distribution Center) dalla rete esterna. ISA Server rinvia ad Active Directory il mapping tra certificato e utente per l'autenticazione dell'utente e acquisisce i rispettivi ticket Kerberos in base al nome dell'entità utente (UPN, User Principal Name). In questo caso, ISA Server fornisce la funzionalità di delega vincolata Kerberos a un server front-end Exchange tramite i servizi di proxy inverso e di filtro a livello di applicazione. Se la delega viene eseguita senza un proxy inverso, il maggiore rischio di exploit potrebbe influire sull'integrità della rete o del dominio Active Directory.
Exchange Server 2003 e Exchange Server 2007 supportano entrambi l'autenticazione di base e integrata. Per consentire il corretto funzionamento dell'autenticazione basata su smart card a OWA, è necessario tuttavia applicare un aggiornamento software a Exchange Server 2003. Per ulteriori informazioni, vedere l'articolo "Descrizione della nuova funzionalità di Exchange Server 2003 che supporta l'autenticazione basata s smart card a Outlook Web Access". È necessario disporre di un dominio che operi nella modalità funzionale nativa di Windows Server® 2003, tutti i server di Exchange Server 2003 coinvolti devono disporre di SP2 o versione successiva e occorre utilizzare un server ISA Server 2006 che funga da proxy inverso per il sito OWA.
Dopo aver installato l'aggiornamento software e configurato i server ISA ed Exchange, gli utenti possono eseguire l'autenticazione di una sessione OWA mediante l'uso di smart card. Nella Figura 3 viene illustrato il flusso degli eventi necessari per l'autenticazione basata su smart card. Un utente inizia aprendo il sito OWA in Internet Explorer® (1). In effetti, l'utente si connette a ISA Server e gli viene richiesto un certificato anziché un nome utente e una password per avviare la sessione OWA. Il certificato appropriato viene archiviato sulla smart card, per la quale l'utente necessita di un codice PIN.
Figura 3 Autenticazione di OWA con una smart card
Figura 3 Autenticazione di OWA con una smart card
La convalida del certificato (2) viene gestita tramite un elenco di revoche di certificati (CRL) o una richiesta del protocollo di stato del certificato in linea (OCSP), in base alla configurazione di ISA Server e di altro software installato. ISA Server effettua una richiesta a un controller di dominio per verificare le credenziali dell'utente. Se la richiesta non riesce, ISA Server presenta una pagina di errore all'utente e nessuna richiesta perverrà al server front-end Exchange.
Dopo che le credenziali sono state verificate, viene generato il ticket Kerberos e la richiesta viene passata al server front-end Exchange mediante l'autenticazione integrata (3). Una volta ricevuta la richiesta, il server front-end Exchange convalida il ticket Kerberos e individua il server cassette postali back-end dell'utente (4).
Il server front-end richiede un ticket Kerberos per il server back-end appropriato tramite la delega vincolata Kerberos e invia tramite proxy la richiesta delle cassette postali al server back-end mediante l'autenticazione integrata (5). La richiesta viene elaborata dal server back-end (6) e i dati delle cassette postali vengono restituiti al server front-end Exchange (7). I dati HTML per la pagina OWA vengono passati a ISA Server (8), che quindi li trasmette di nuovo al computer client (9).

Configurazione dell'ambiente Exchange
L'articolo della Knowledge Base menzionato in precedenza descrive l'aggiornamento software per Exchange Server 2003 e contiene informazioni utili per l'esecuzione del processo di attivazione della delega vincolata Kerberos mediante ISA Server 2006 ed Exchange Server 2003.
L'azione principale che l'aggiornamento software consente è l'automatizzazione del processo di delega vincolata Kerberos dal server front-end Exchange ai rispettivi server back-end. L'aggiornamento non automatizzerà il processo di delega vincolata Kerberos da ISA Server al server front-end in quanto ISA Server non fa parte dell'organizzazione di Exchange. Questa delega dovrà essere attivata manualmente da ciascuna istanza di ISA Server a ciascun server front-end Exchange.
L'aggiornamento software aggiunge una nuova scheda al Gestore di sistema di Exchange (ESM, Exchange System Manager) che consente di designare un server front-end Exchange come KCD-FE (vedere la Figura 4), che consente a sua volta di inserire tale server nella scheda relativa alla delega dei rispettivi server back-end Exchange.
Figura 4 Attivazione della delega vincolata Kerberos
Figura 4 Attivazione della delega vincolata Kerberos
Anche la nuova interfaccia utente consente di specificare nelle proprietà del gruppo amministrativo le credenziali da utilizzare per la compilazione dell'attributo msDS-AllowedToDelegateTo (A2D2), come illustrato nella Figura 5. Questo è l'attributo responsabile per la delega vincolata Kerberos.
Figura 5 Impostazione dell'account che controlla la delega
Figura 5 Impostazione dell'account che controlla la delega
Rispettando il principio del privilegio minimo, è possibile utilizzare un account utente standard e concedere a tale account l'autorità di delegare utenti e computer tramite un oggetto Criteri di gruppo. Dopo che gli è stata concessa questa autorizzazione elevata, l'account può essere utilizzato come account di servizio per automatizzare il processo di delega vincolata Kerberos per il rispettivo gruppo amministrativo.
Accertarsi di eseguire le operazioni appropriate per impedire che un utente malintenzionato possa compromettere l'account del servizio di delega vincolata Kerberos. Anche se l'account non è un amministratore di dominio, l'accesso a tale account potrebbe provocare attacchi sofisticati che possono sfruttare la delega Kerberos. Poiché l'account avrà la capacità di stabilire nuove associazioni Kerberos, è consigliabile utilizzarlo con cautela. Adottare le precauzioni necessarie per garantire la protezione e l'integrità di questo account: una password lunga e complessa, maggiore controllo, tecniche di disabilitazione dell'account e così via.
L'aggiornamento software Exchange consente inoltre di apportare una modifica molto importante all'interfaccia di ESM relativa all'autenticazione integrata. In precedenza, in Exchange Server 2003, quando un server veniva designato come server front-end, l'opzione per l'attivazione dell'autenticazione integrata di Windows per le directory virtuali HTTP (in Server virtuale HTTP) era disattivata (vedere la Figura 6).
Figura 6a L'aggiornamento consente l'autenticazione integrata
Figura 6a L'aggiornamento consente l'autenticazione integrata
Figura 6b L'aggiornamento consente l'autenticazione integrata
Figura 6b L'aggiornamento consente l'autenticazione integrata
Questo avveniva perché l'autenticazione integrata non era supportata sui server front-end Exchange a causa di problemi tecnici, come il fatto che i server proxy interrompevano le sessioni NTLM, gli utenti che utilizzavano l'autenticazione Kerberos necessitavano di una connessione ad Active Directory e gli utenti Internet in genere non facevano parte del dominio. Queste limitazioni sono state rimosse grazie all'aggiornamento descritto nell'articolo della Knowledge Base menzionato in precedenza. Con l'aggiornamento installato, è possibile accedere semplicemente alla directory virtuale e selezionare la casella per impostare l'autenticazione integrata di Windows come meccanismo per la verifica delle credenziali utente. Una volta selezionata questa casella, viene automaticamente impostato un attributo denominato msexchAuthenticationFlags nell'oggetto directory virtuale in Active Directory (è possibile visualizzarlo utilizzando lo snap-in Adsiedit.msc per Microsoft Management Console).
È possibile che gli utenti che controllano la posta tramite OWA conoscano il nome dei rispettivi server back-end Exchange e si connettono a tali server utilizzando l'autenticazione integrata dalla rete Intranet aziendale. La differenza nell'esperienza dell'utente con l'autenticazione integrata è rappresentata dal fatto che, poiché si è connessi alla rete, non viene richiesto un nome utente e una password in quanto Internet Explorer eseguirà automaticamente l'autenticazione dell'utente al sito Web. Questo rappresenta un enorme vantaggio per gli utenti connessi alla rete aziendale, ma gli utenti esterni e, in particolar modo gli utenti OWA, in genere non sono connessi a un dominio quando accedono dall'esterno della rete a un server front-end Exchange. Questo processo viene illustrato in dettaglio nell'articolo della Knowledge Base "Modalità di autenticazione dei client browser in IIS".
In Exchange Server, l'aggiornamento consente di compilare la scheda relativa alla delega per l'utilizzo dell'attributo A2D2 anziché dell'attributo SPN (Service Principal Name, nome dell'entità servizio) in Active Directory. Se si esamina l'oggetto computer di Exchange utilizzando Adsiedit.msc, si noteranno due attributi distinti: l'attributo A2D2, che corrisponde all'elenco delle deleghe vincolate Kerberos, e l'attributo SPN, che funge da punto di specifica dell'account e punto di individuazione del servizio Kerberos. Sebbene i due attributi interagiscano tra loro per consentire l'attivazione della delega vincolata Kerberos, occorre modificare solo l'attributo A2D2 tramite l'interfaccia grafica.
In Windows l'attributo HOST SPN integrato può essere utilizzato come alias per l'individuazione di altri servizi. Ne consegue che, per consentire il funzionamento della delega vincolata Kerberos per la delega dal server front-end Exchange al server back-end, non è necessario utilizzare setspn.exe. Sebbene sia possibile specificare in modo esplicito HTTP/Nomeserver nell'elenco di attributi SPN, questa soluzione lascia maggiore spazio a errori da parte dell'amministratore e non è necessaria per il funzionamento della delega vincolata Kerberos. La delega vincolata Kerberos prevede la ricerca dell'attributo A2D2 in Active Directory. Quando questo attributo non viene compilato (o viene compilato con il valore SPN errato), la delega vincolata Kerberos non funziona tra i rispettivi server. Su un cluster Exchange, tuttavia, per poter funzionare in modo corretto, l'attributo A2D2 del server front-end deve essere configurato in modo che faccia riferimento all'account del computer nodo cluster.
Come osservato in precedenza, un dominio Windows Server 2003 contenente i server Exchange 2003 deve operare nella modalità funzionale nativa di Windows Server 2003. La delega vincolata Kerberos non può essere utilizzata a meno che non si raggiunga tale livello di funzionalità del dominio. Se il dominio è ancora in modalità mista e si installa l'aggiornamento software di cui si è discusso in precedenza, la delega sembrerà funzionare correttamente ma le registrazioni SPN non riusciranno. La delega vincolata Kerberos è inoltre una funzione di dominio, non una funzione a livello di foresta. questo implica che per Exchange Server 2003, ISA Server e i server front-end e back-end Exchange devono essere membri dello stesso dominio (anche se gli utenti di domini differenti possono comunque eseguire l'autenticazione alla delega vincolata Kerberos). Un'istanza di ISA Server che non è membro di un dominio o che è membro di un dominio differente non funzionerà come parte di questa soluzione.

Configurazione del sito OWA
È consigliabile non utilizzare il servizio Amministratore di IIS per qualsiasi tipo di modifica di autenticazione a OWA. Anche se OWA viene eseguito su IIS e risponderà alle modifiche nella metabase come qualsiasi altro sito Web, Exchange introduce un certo grado di complessità con il processo Directory Services to Metabase (DS2MB). Il processo DS2MB replicherà le modifiche da Active Directory nella metabase di IIS con una procedura unidirezionale che sovrascriverà tutte le modifiche apportate direttamente a IIS. L'impatto di questo processo è che se un amministratore apporta una modifica direttamente alla metabase di IIS (come l'impostazione dell'autenticazione integrata), la soluzione sembrerà funzionare in modo corretto ma smetterà di funzionare non appena viene avviato il successivo ciclo di replica del processo DS2MB.
L'opzione per l'attivazione dell'autenticazione integrata di Windows per le directory virtuali HTTP è stata resa disponibile in ESM in quanto questa applicazione esegue direttamente le modifiche in Active Directory, il che determina la replica delle modifiche nella metabase di IIS. Tenere presente che, sebbene l'arresto del servizio Supervisore sistema determini l'arresto del processo DS2MB, consentendo di apportare modifiche alla metabase di IIS e impedendone la sovrascrittura, è consigliabile non eseguire questa operazione. Al successivo avvio di Supervisore sistema, questo servizio esegue il polling delle modifiche da Active Directory e la soluzione verrà disattivata automaticamente.
Nella scheda relativa alla delega sono contenute le opzioni per Utilizza solo Kerberos e Utilizza un qualsiasi protocollo di autenticazione. Basandosi sulla semplice logica, si dovrebbe selezionare Utilizza solo Kerberos in quanto la soluzione in questione utilizza la delega vincolata Kerberos; tuttavia, questa è una delle numerose situazioni IT in cui la logica comune non è applicabile. Al contrario, è consigliabile selezionare l'opzione Utilizza un qualsiasi protocollo di autenticazione (come illustrato nella Figura 7) in quanto la richiesta non perviene come richiesta Kerberos ma come richiesta HTTP con un certificato corrispondente mappato a un account Active Directory.
Figura 7 Correzione delle impostazioni di autenticazione per le smart card
Figura 7 Correzione delle impostazioni di autenticazione per le smart card
In questo caso, ISA Server richiede il certificato PKI dell'utente mediante SSL. Poiché la richiesta in arrivo non è un ticket Kerberos, è necessario eseguire una transizione per consentire il corretto funzionamento della delega vincolata Kerberos. Pertanto, l'impostazione dell'opzione Utilizza solo Kerberos interromperà la catena di comunicazione in ISA Server. Tenere presente, tuttavia, che l'opzione Utilizza solo Kerberos funziona per la delega dal server front-end Exchange al server back-end in quanto il server front-end prevede la ricezione solo dei ticket Kerberos inviati da ISA Server.
Le directory virtuali \Exchange e \Public sono le uniche posizioni che devono contenere informazioni sulle cartelle pubbliche e sugli utenti privati. La configurazione SSL in Exchange non rappresenta una novità per la delega vincolata Kerberos o l'autenticazione a due fattori, ma una conseguenza dell'attivazione SSL standard in OWA con credenziali di autenticazione di base. È consigliabile seguire i metodi documentati per attivare SSL in OWA, in quanto l'attivazione non corretta di SSL può determinare il malfunzionamento di OWA oltre a causare problemi con ESM.

Dettagli di configurazione aggiuntivi
Quando si implementa questa soluzione, è molto più semplice eseguire la distribuzione di ISA Server e di Exchange seguendo la procedura standard. Non inserire l'intera soluzione di delega vincolata Kerberos con tutte le impostazioni configurate (soprattutto se in precedenza ISA Server non era incluso nella distribuzione). Questo può complicare il processo di risoluzione dei problemi in caso di errore di un componente o nel caso in cui una fase del processo non dovesse riuscire. È molto più semplice distribuire ISA Server ed Exchange seguendo la procedura standard (con nome utente e password ma senza l'autenticazione basata su form), assicurarsi che l'installazione funzioni in modo corretto ed eseguire la transizione alla delega vincolata Kerberos e all'autenticazione basata sui certificati.
In genere, l'autenticazione basata su form non può essere utilizzata con un client OWA abilitato all'utilizzo di smart card. L'autenticazione basata su form indica che un utente ha un nome utente e una password da inviare tramite il modulo di Outlook standard. Tuttavia, con l'autenticazione a due fattori basata su smart card, l'utente avrà solo una smart card e non una password. Pertanto, l'autenticazione basata su form non prevede alcun metodo per accettare o inviare solo il certificato per l'autenticazione. L'utilizzo dell'autenticazione basata su form in qualsiasi punto della catena, ad esempio su un server front-end dietro ISA Server, impedirà il corretto funzionamento della configurazione del client OWA abilitato all'utilizzo di smart card. Se si attiva l'autenticazione basata su form, la directory virtuale di Exchange verrà impostata forzatamente sull'autenticazione di base e, di conseguenza, anche la metabase di IIS verrà impostata sull'autenticazione di base.
In uno scenario che prevede una combinazione di utenti che dispongono sia di nome utente/password che di smart card, è possibile attivare l'autenticazione fallback sul listener Web ISA e, quando un utente preme ESC dopo che gli sono state richieste le credenziali basate sui certificati, gli verranno richieste anche le credenziali standard basate su nome utente/password anche se l'autenticazione integrata è attivata dietro ISA Server sul server Exchange. Inoltre, ISA Server può causare il timeout della sessione SSL in modo analogo alle funzioni di autenticazione basata su form.

Conclusioni
Il supporto delle smart card per l'autenticazione a OWA rappresenta una funzionalità aggiuntiva di Exchange Server 2003 ed Exchange Server 2007 accolta con grande entusiasmo. Grazie alla possibilità di accedere a OWA mediante un certificato, gli utenti non devono più preoccuparsi di ricordare password lunghe e complesse e gli amministratori ora hanno a disposizione uno strumento efficace contro keystroke logger e altre forme di malware che possono individuare le credenziali utente da un sistema infetto. Per ulteriori informazioni, vedere le l'intestazione laterale "Risorse".
La corretta configurazione di ISA Server per l'autenticazione a due fattori con smart card consente di migliorare ulteriormente la protezione globale mediante l'applicazione di filtri a livello di applicazione sull'applicazione OWA pubblicata. Inoltre, ISA Server 2006 dispone del supporto integrato per la pubblicazione di Exchange Server 2003 e di Exchange Server 2007 tramite le semplici procedure guidate di pubblicazione e, pertanto, ISA Server resta un investimento ottimale per le organizzazioni che eseguono la transizione a Exchange Server 2007.
Risorse
  • Come condividere i file rimossi dalla funzionalità di filtro "Safe HTML" in Outlook Web Access per Exchange Server 2003
  • Risoluzione dei problemi relativi alla delega Kerberos
  • Servizio di aggiornamento della metabase
  • Autenticazione in ISA Server 2006
  • Delega vincolata e transizione del protocollo Kerberos
  • TechNet Webcast: implementazione dell'autenticazione a più fattori tramite smart card

Victor Akinnagbe ricopre il ruolo di Premier Field Engineer nella sede di Microsoft nell'area di Washington D.C. Il principale centro di interesse della sua attività è rappresentato da questioni relative a protezione, infrastruttura e messaggistica.
Ted Dressel ricopre il ruolo di consulente nella sede di Microsoft nell'area di Washington D.C. Il principale centro di interesse della sua attività è rappresentato da questioni relative a protezione e infrastruttura.
Jason Opdycke ricopre il ruolo di Premier Field Engineer nella sede di Microsoft nell'area di Charlotte. Le sue principali aree di interesse sono la protezione e l'infrastruttura.


 Amministrazione di Windows: Il servizio ActiveX Installer in Windows Vista
Amministrazione di Windows Rob Campbell and Joel Yoker

Il servizio ActiveX Installer in Windows Vista
Panoramica:
  • Problematiche dei controlli ActiveX
  • Modalità di installazione dei controlli ActiveX
  • Autorizzazioni rischiose
  • Un processo più sicuro in Windows Vista

È sempre la stessa storia: per migliorare in modo sostanziale la protezione, è necessario rinunciare a un certo grado di libertà o di flessibilità. Nella maggior parte delle organizzazioni, uno degli obiettivi è rafforzare il sistema operativo per desktop nel tentativo di fornire un ambiente di elaborazione più protetto
per gli utenti finali. L'attività di protezione del desktop viene in genere affrontata dagli amministratori IT attraverso una combinazione di impostazioni dei criteri di protezione, autorizzazioni utente, elenchi di controllo di accesso (ACL) per file e Registro di sistema e restrizioni dei servizi di sistema.
Una difficoltà comune nello sviluppo di un ambiente desktop protetto riguarda il modo in cui attenuare le minacce che circondano i controlli ActiveX® dannosi e allo stesso tempo mantenere un livello di compatibilità delle applicazioni adeguato. Una sfida che dura da molti anni. Fortunatamente, il nuovo servizio ActiveX Installer in Windows Vista™ consente oggi di risolvere problematiche specifiche della gestione dei controlli ActiveX negli ambienti aziendali, fornendo un sistema semplice e facilmente gestibile mediante cui gli utenti standard, che normalmente non sarebbero autorizzati a installare controlli ActiveX, possono installarli da siti Web approvati. Il controllo Criteri di gruppo sul servizio ActiveX Installer consente agli amministratori IT di determinare quali controlli possono essere installati dagli utenti, indipendentemente dalle autorizzazioni di cui questi ultimi dispongono.
In questo articolo, verranno esaminate le problematiche di tipo amministrativo riguardanti i controlli ActiveX, il modo in cui questi problemi venivano risolti nelle versioni precedenti di Windows® e come il servizio ActiveX Installer di Window Vista fornisca un sistema unico ed efficiente per la gestione dell'installazione dei controlli ActiveX.

Che cos'è un controllo ActiveX?
Un controllo ActiveX è un codice eseguibile (in genere un file OCX inserito in un file CAB) installato e richiamato dall'utente tramite Internet Explorer®. I controlli ActiveX vengono creati dagli sviluppatori Web per aggiungere alle applicazioni Web funzionalità che non sarebbero facilmente realizzabili con l'HTML standard o con un semplice script.
Una delle funzionalità principali dei controlli ActiveX è rappresentata dal semplice modello di distribuzione di tipo "scarica ed esegui". I controlli ActiveX vengono installati e richiamati tramite il tag Object HTML, che presenta un attributo chiamato CODEBASE che indica a Internet Explorer (mediante un URL) dove recuperare il controllo se non è già stato installato nel computer dell'utente. In questo caso, Internet Explorer scarica il pacchetto di installazione associato, esegue una verifica di attendibilità sull'oggetto e richiede all'utente l'autorizzazione per l'installazione tramite la Barra informazioni (illustrata nella Figura 1). Durante l'installazione, il controllo viene registrato e richiamato dalla pagina di rendering. Una volta installato, potrà essere richiamato da qualsiasi utente standard. Questo semplice meccanismo di distribuzione ed esecuzione ha lo scopo di fornire agli sviluppatori un agevole sistema di distribuzione dei componenti agli utenti dell'applicazione Web. Il problema di questo metodo di distribuzione è che gli utenti standard non possono installare direttamente i controlli ActiveX, poiché è necessario disporre di privilegi amministrativi per completare l'installazione.
Figura 1 Barra informazioni per l'installazione di un controllo ActiveX
Figura 1 Barra informazioni per l'installazione di un controllo ActiveX
Quando i controlli ActiveX furono inizialmente introdotti in Internet Explorer 4.0, Internet apparve un luogo molto più semplice. Oggi, poiché il codice eseguibile distribuito sul Web può rappresentare una minaccia notevole, Windows concede solo agli utenti che dispongono di diritti di amministratore locale la possibilità di installare i controlli ActiveX e quindi solo se l'installazione è approvata in base alle impostazioni dei criteri. Una volta installato da un amministratore, il controllo ActiveX può essere richiamato da qualsiasi utente del sistema. Questo comportamento è facilitato da una serie di elenchi di controllo di accesso per file e Registro di sistema presenti in Windows. Anche se in questo modo si impedisce agli utenti standard di installare i controlli ActiveX, non si riducono però i rischi per gli amministratori locali e gli utenti standard (con autorizzazioni predefinite modificate) che ne eseguono l'installazione.
Sebbene la protezione predefinita in Windows, che consente la possibilità di eseguire l'installazione solo a coloro che dispongono di privilegi amministrativi, risolva il problema dei controlli ActiveX a livello individuale, non viene risolto il problema della loro gestione in un'organizzazione di grandi dimensioni. Una delle problematiche frequenti negli ambienti aziendali riguarda il modo in cui consentire l'utilizzo dei controlli ActiveX considerati attendibili da parte dell'organizzazione IT e allo stesso tempo attenuare le minacce potenziali rappresentate da controlli esterni non attendibili. Alla fine, la decisione di installare un particolare controllo ActiveX, sicuro o dannoso che sia, è spesso lasciata al singolo utente, secondo i diritti di cui dispone. Per contrastare le minacce, alcune organizzazioni bloccano tutti i controlli ActiveX, mentre altre consentono l'installazione da parte degli utenti finali ma tentando di gestire i malware installati.
Un altro metodo per evitare l'installazione di controlli dannosi consiste nell'attivare i diritti dell'utente standard con restrizioni e fare in modo che l'amministratore IT preinstalli tutti i controlli necessari nella piattaforma desktop. Questo metodo è valido se i controlli ActiveX in uso sono di natura relativamente statica, se vengono modificati mediante un processo di rilascio pianificato insieme agli aggiornamenti desktop o se l'organizzazione utilizza un meccanismo di distribuzione del software come Systems Management Server. Tuttavia, la gestione continuativa, le esigenze sempre mutevoli degli sviluppatori di applicazioni interne e le dipendenze dai controlli esterni continueranno a rappresentare una sfida con questi tipi di approccio.
Quando gli utenti dispongono di privilegi amministrativi, il problema è diverso e riguarda il sistema per impedire a tali utenti l'installazione di controlli non approvati. In questo caso, si presuppone il diritto dell'utente finale a installare i controlli ActiveX dal momento che l'utente dispone di privilegi amministrativi (si noti che l'accesso degli utenti finali come amministratori locali è una condizione di alto rischio per l'organizzazione, non consigliabile per la maggior parte degli ambienti aziendali).
Una soluzione può essere offerta da un server di download dei componenti Internet che ospita i controlli approvati. In questo caso è necessaria la modifica della stringa CodeBaseSearchPath nel Registro di sistema del client. In genere, quando nella pagina HTML richiesta viene rilevato un tag Object contenente l'attributo CODEBASE, i client Windows vengono diretti ai percorsi specificati nei dati di CodeBaseSearchPath. Per impostazione predefinita, questa stringa del Registro di sistema contiene la parola chiave CODEBASE e gli URL Internet per la raccolta dei controlli ActiveX. Per implementare un server di download dei componenti Internet, è necessario sostituire i dati predefiniti di CodeBaseSearchPath con l'URL del server interno in cui verranno ospitati i controlli approvati dall'organizzazione. Analogamente all'approccio precedente, questa soluzione richiede una gestione continuativa e comporta il costo e la complessità di ospitare un server interno per i controlli ActiveX.
Esistono altre soluzioni, ad esempio la modifica dell'area di Internet Explorer URLActions, la specifica di controlli approvati dall'amministratore mediante Criteri di gruppo e il blocco dell'installazione di tutti i controlli sul perimetro mediante le regole del firewall. Ma, come si può notare, tutti questi approcci comportano problemi e molti vengono alla fine abbandonati per mancanza di flessibilità. Inoltre, per alcune di queste soluzioni è in ogni caso necessario che l'utente disponga di diritti amministrativi. In conclusione, queste modifiche tentano di risolvere parti del problema, ad esempio il controllo (o il blocco) dell'origine dei controlli ActiveX, dei punti da cui possono essere richiamati e così via; ma in effetti queste soluzioni non attenuano il problema fondamentale che gli utenti senza diritti amministrativi non possono installare i controlli ActiveX.

Il servizio ActiveX Installer
Il servizio ActiveX Installer di Windows Vista consente agli amministratori di reti Intranet di gestire i controlli ActiveX e mantenere allo stesso tempo una condizione di protezione elevata attraverso l'accesso degli utenti come utenti standard con impostazioni del file system predefinite. Il servizio prevede la scelta di opzioni di Criteri di gruppo per configurare le origini attendibili dei controlli ActiveX e un processo broker per installare i controlli da tali origini attendibili per conto degli utenti standard. Il vantaggio principale è la possibilità di mantenere una condizione di protezione non amministrativa sulle workstation degli utenti unitamente a un controllo amministrativo centralizzato. Per l'identificazione delle origini attendibili (in genere URL Internet o Intranet) dei controlli ActiveX, il servizio dipende dall'amministratore IT. Quando da Internet Explorer viene richiamato un controllo a seguito di un tag Object, il servizio ActiveX Installer esegue le operazioni seguenti:
  1. Verifica se il controllo è installato. In caso negativo, sarà necessario installarlo prima di utilizzarlo.
  2. Controlla l'impostazione dei relativi criteri per verificare se l'origine del controllo è attendibile. Per questa verifica, il nome host dell'URL specificato nell'attributo CODEBASE del tag Object viene confrontato con l'elenco dei percorsi attendibili specificati nei criteri.
  3. Scarica e installa il controllo per conto dell'utente.
Se il nome host dell'URL di origine non è elencato nell'impostazione dei criteri del servizio ActiveX Installer, verrà visualizzato il normale messaggio di Controllo account utente in cui viene indicata la necessità di disporre di diritti amministrativi per completare l'installazione. Nel registro eventi applicazioni verrà inoltre registrato un evento con ID 4097 e origine AxInstallService, che segnala il tentativo di installazione del controllo ActiveX unitamente al percorso di download specifico del controllo. Un esempio di evento 4097 è illustrato nella Figura 2. I dati di questa voce del registro eventi possono essere utilizzati dall'amministratore della rete Intranet per modificare i Criteri di gruppo e consentire l'installazione del controllo mediante il servizio ActiveX Installer in occasione di successivi accessi al sito Web.
Figura 2 Evento AxInstallService 4097
Figura 2 Evento AxInstallService 4097
Il servizio ActiveX Installer è un componente facoltativo incluso nelle SKU Business, Enterprise e Ultimate di Windows Vista ed è possibile attivarlo mediante un'opzione automatica o mediante la finestra di dialogo Pannello di controllo (Programmi | Programmi e funzionalità | Attivazione o disattivazione delle funzionalità Windows), come illustrato nella Figura 3. Una volta attivato, il servizio eseguirà i passaggi precedentemente descritti ogni volta che un controllo viene richiesto da Internet Explorer.
Figura 3 Attivazione del servizio ActiveX Installer in Pannello di controllo
Figura 3 Attivazione del servizio ActiveX Installer in Pannello di controllo
Grazie alla possibilità di associare attività agli eventi offerta da Windows Vista, un amministratore può ricevere una notifica dal servizio ActiveX Installer quando, ad esempio, viene bloccata l'installazione di un controllo ActiveX. È importante notare che non è possibile presumere sempre che il controllo ActiveX venga installato dal nome host dello stesso URL a cui l'utente finale accede dal sito Web. Per questa ragione, le informazioni fornite dall'evento AxInstallService 4097 (tentativo di installazione) possono rivelarsi incredibilmente utili per identificare l'host da cui avviene il tentativo di installazione del controllo.
Utilizzando le informazioni ottenute sull'evento, è possibile configurare il percorso attendibile in Criteri di gruppo. Le impostazioni relative al servizio ActiveX Installer per i criteri di gruppo o locali si trovano nelle impostazioni Configurazione computer (come illustrato nella Figura 4). Le impostazioni del criterio Siti di installazione approvati per i controlli ActiveX consentono di specificare gli URL host delle posizioni attendibili (vedere la Figura 5). Per l'impostazione dei siti approvati sono necessarie due informazioni: l'origine da cui è possibile installare il controllo ActiveX e il comportamento dell'installazione.
Figura 4 Impostazioni in Editor oggetti Criteri di gruppo
Figura 4 Impostazioni in Editor oggetti Criteri di gruppo
Figura 5 Siti di installazione approvati per il servizio ActiveX Installer
Figura 5 Siti di installazione approvati per il servizio ActiveX Installer
Innanzitutto, come detto in precedenza, è necessario un URL host per indicare il percorso attendibile del controllo. A differenza delle soluzioni precedenti, per le quali era necessario conoscere il CLSID del controllo (che spesso cambia quando i controlli vengono rivisti dai rispettivi sviluppatori), il servizio ActiveX Installer consente l'installazione di qualsiasi controllo dal percorso attendibile, riducendo in questo modo il carico complessivo delle attività amministrative. La seconda informazione è rappresentata da una stringa delimitata da virgole costituita da quattro valori, ognuno dei quali definisce il comportamento dell'operazione di download dei controlli ActiveX. Tali valori specificano quattro proprietà: TPSSignedControl, SignedControl, UnsignedControl e ServerCertificatePolicy. Per le prime due proprietà (TPSSignedControl e SignedControl) i valori consentiti sono 0, 1 o 2 e sono simili ai valori delle impostazioni URLAction. Un valore pari a 0 impedisce l'installazione del controllo, un valore pari a 1 genera un messaggio in cui viene richiesta all'utente la conferma per eseguire l'installazione, un valore pari a 2 produce l'installazione automatica del controllo per conto dell'utente. Poiché i controlli senza firma elettronica non possono essere installati automaticamente, il valore di UnsignedControl può essere soltanto 0 o 1. Si noti che, se non si specifica alcun criterio, verranno utilizzati i valori predefiniti 2, 1 e 0.
L'ultima proprietà specifica il comportamento dell'installazione in base alle impostazioni del certificato del controllo delle impostazioni con firma elettronica. Come per maggior parte dei siti SSL, i certificati devono superare una serie di test di protezione per garantirne la validità. A volte le proprietà dei certificati non valide sono la realtà delle implementazioni dei controlli ActiveX con firma elettronica. Attraverso la sua configurazione, il servizio ActiveX Installer consente agli amministratori di ridurre le informazioni non valide talvolta presentate dai certificati su base URL per URL. L'ultima proprietà è rappresentata da una maschera di bit con una combinazione di valori illustrata nella Figura 6.
Figure 6 ServerCertificatePolicy (Close Figure 6)

Valore | Definizione
0x00001000 | Ignora un nome canonico non valido nel certificato.
0x00000100 | Ignora le autorità di certificazione sconosciute.
0x00002000 | Ignora una data di certificato non valida.
0x00000200 | Ignora un utilizzo errato del certificato.
L'impostazione predefinita è 0, il che significa che devono essere superati tutti i controlli di protezione prima che il servizio ActiveX Installer completi l'installazione. La combinazione dell'impostazione dell'host e di questi quattro valori viene specificata nell'impostazione dei criteri, come illustrato nella Figura 7.
Figura 7 URL host approvati del servizio ActiveX Installer
Figura 7 URL host approvati del servizio ActiveX Installer

Conclusioni
Il servizio ActiveX Installer consente di configurare i Criteri di gruppo per definire quali controlli ActiveX possono essere installati dagli utenti senza necessità di privilegi amministrativi o di operazioni di configurazione complesse. Un controllo a questo livello poteva essere problematico nelle versioni precedenti di Windows e le soluzioni precedentemente disponibili comportavano spesso limitazioni notevoli o un sovraccarico di operazioni di gestione. Grazie a questo nuovo servizio, le organizzazioni dispongono di un ulteriore strumento per un approccio ai diritti dell'utente finale basato su privilegi minimi, consentendo l'implementazione di un modello utente standard in cui gli utenti finali non devono necessariamente disporre di privilegi amministrativi. In Windows Vista l'amministratore IT svolge un ruolo centrale, avendo la possibilità di scegliere i controlli ActiveX considerati attendibili all'interno dell'ambiente aziendale come determinato dall'organizzazione e non dall'utente finale.

Rob Campbell è uno specialista tecnico senior del team federale Microsoft. Lavora in particolare allo sviluppo e alla distribuzione di soluzioni di protezione per i clienti del governo federale degli Stati Uniti.
Joel Yoker è un consulente senior del team federale Microsoft. Lavora in particolare allo sviluppo e alla distribuzione di soluzioni di protezione per i clienti del governo federale degli Stati Uniti.


 Dal redattore: Sei gradi
Dal redattore
Sei gradi
Joshua Trupin

Ti sei mai sentito un po' staccato dal resto del mondo? Sei rimasto seduto nel tuo ufficio, con gli occhi fissi nel vuoto, domandandoti se lì fuori esista una forma di una vita intelligente? Se ci sia effettivamente qualcuno? Forse no, specialmente se la tua casella di posta è perennemente piena fino al colmo come la mia.
Malgrado ciò, mi è capitato ultimamente di provare tormenti del genere che mi hanno portato a decidere che dovevo mettermi in comunicazione con il mondo. Mi sono quindi iscritto a uno di quei siti di networking sociale incentrati sulle esigenze di business e ho cominciato ad aggiungere gente, persone con cui avevo lavorato, parlato a una conferenza o di cui avevo letto un articolo. Dopo una settimana, nel mio elenco c'erano 58 contatti. Grande!
Ma questo era solo il primo livello. Al secondo livello, conoscenti di conoscenti, avevo più di 3.500 amici. E poiché questi 3.500 contatti avevano ciascuno i loro contatti personali, sono passato a 277.000 contatti di terzo grado in un batter d'occhio. Con un rapido calcolo in Excel, presumendo una media di 50 contatti a persona, il risultato è che conosco più di 34 miliardi di persone al sesto grado di contatti. Fatti da parte, Kevin Bacon! Conosco più persone io di quante esistono sul pianeta Terra. Improvvisamente il vuoto brulicava di gente.
Si è posto però un nuovo problema: come gestire tutte queste relazioni? Sono aperto a tutti i suggerimenti. Utilizzi attualmente un sito di networking sociale/aziendale? Come dividi le persone con cui vuoi parlare da quelle che vuoi evitare? Vai nel TechNet Magazine http://blogs.technet.com/tnmag e raccontaci che ne pensi di questo scottante problema.
Se la questione del networking del Web 2.0 non rientra nei tuoi interessi, non preoccuparti. Nel numero di TechNet Magazine di questo mese verrà illustrato come migliorare le comunicazioni grazie a un utilizzo più efficiente di Exchange Server, con cinque articoli che spiegano tutto quel che è necessario sapere per estendere le potenzialità di messaggistica della tua organizzazione.
Uno degli argomenti di questo mese sarà l'autenticazione delle smart card mediante Outlook Web Access. È sempre consigliabile richiedere una forma di autenticazione fisica prima di concedere l'accesso alle risorse dell'azienda e le smart card rendono possibile questa funzionalità da qualsiasi luogo. Verrà inoltre esaminato il ripristino di emergenza con Exchange Server, come sostituire le cartelle pubbliche con SharePoint in Exchange Server 2007 e come migliorare la protezione dei dispositivi mobili con Windows Mobile 6. E naturalmente sarà presente Exchange Queue & A, probabilmente la tua rubrica preferita se non hai avuto nulla a che fare con la messaggistica. Ehi, altre tre persone sono appena apparse sulla mia rete. È meglio che vada a vedere se devo salutarli o fare finta di dormire.
—Joshua Trupin

Si ringraziano i seguenti esperti tecnici di Microsoft: Kristian Andaker, Chris Corio, Jim Harrison, Chad Jones, Michael Lee, Shawn McGrath, Michael Murgolo, Eric Perlin, Michelle Rutzer, Gavriella Schuste e Jim Truher.


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

Monitoraggio delle connessioni remote
RecordTS
www.tsfactory.com
Hai mai desiderato poter dare un'occhiata alle sessioni di Terminal Server o Desktop remoto? Forse per sapere che cosa stava accadendo prima che la sessione di Desktop remoto interferisse con il sito Web oppure perché si è verificato un problema su Terminal Server che sembra impossibile da replicare. Forse sei preoccupato per la protezione della proprietà intellettuale oppure è necessario creare un rapido registro o una presentazione delle impostazioni di configurazione del server SharePoint® in un ambiente di prova. Se ti sei imbattuto in una di queste situazioni, dovresti esaminare RecordTS di TSFactory (un'azienda creata da Cláudio Rodrigues, Microsoft MVP per Servizi terminal).
RecordTS è disponibile in due versioni: Terminal Server Edition e Remote Desktop Edition. La scelta della versione dipenderà dai tipi di connessioni che si desidera monitorare. Come indicato nel sito Web del prodotto, RecordTS funziona come una "videocamera di sicurezza" nelle sessioni di Terminal Server o Desktop remoto, agendo in sostanza come un proxy tra Servizi terminal e la sessione dell'utente finale. In questo modo è in grado di registrare tutti gli spostamenti e le azioni eseguite in una sessione.
L'installazione è intuitiva e avviene mediante una semplice procedura guidata che consente di scegliere la directory dati in cui memorizzare le sessioni salvate. L'applicazione installa uno snap-in MMC (che consente di configurare il servizio), il servizio RecordTS e un'utilità di riproduzione sessioni per esaminare le sessioni registrate. Dopo l'apertura dello snap-in MMC, facendo clic con il pulsante destro del mouse sulla cartella del servizio, verrà visualizzata una schermata delle proprietà in cui è possibile configurare le impostazioni, ad esempio la porta su cui si desidera eseguire il servizio (questa particolare impostazione è utile nel caso in cui le sessioni di Servizi terminal siano state trasferite a una porta non standard). Nella scheda Storage, è possibile impostare la cartella di archiviazione predefinita su una cartella locale o un percorso UNC.
È inoltre possibile configurare la struttura di directory delle sessioni memorizzate. Ad esempio, si possono utilizzare il dominio, l'utente, la data e l'ora per organizzare i dati salvati. Ma l'impostazione forse più importante, nel caso in cui le sessioni vengano memorizzate su un disco locale, è quella relativa all'operazione da eseguire se lo spazio sul disco diventa insufficiente. È possibile infatti scegliere di non consentire nuove connessioni e disconnettere quelle correnti (scelta di maggiore protezione) oppure di disattivare la registrazione della sessione (scelta da eseguirsi se non si desidera interrompere la produttività).
Nella scheda Security, è possibile specificare se aggiungere una firma digitale a tutte le sessioni registrate selezionando un certificato esistente o creando un certificato autofirmato, un'operazione utile quando si prevede di utilizzare lo strumento per fini di controllo o responsabilità. Nella scheda Users, è possibile specificare gli utenti di cui registrare o non registrare le sessioni.
RecordTS può quindi costituire uno strumento prezioso per la protezione e il controllo ed è possibile prevederne un utilizzo più ampio, ad esempio per la registrazione di una presentazione riguardante procedure. Personalmente trovo che sia una funzionalità molto utile da aggiungere alla casella degli strumenti.

Prezzo: per RecordTS Remote Desktop Edition si parte da 495 dollari, per RecordTS Terminal Services Edition da 995 dollari.

Monitoraggio degli host
Advanced Host Monitor
www.ks-soft.net
Quando il lavoro prevede il supporto operativo di un'infrastruttura critica per le strategie aziendali, esiste un elemento di cui non è possibile fare a meno: uno strumento di monitoraggio degli host valido e affidabile. Anche se si dispone di hardware estremamente solido e di uno stack di applicazioni stabile e affidabile senza singoli punti di errore, è in ogni caso necessario uno strumento di monitoraggio degli host completo che segnali quando il sistema ridondante debba essere attivato.
Advanced Host Monitor, prodotto da KS-Soft, vanta 58 metodi di test diversi e 30 metodi di avviso e consente di controllare elementi quali informazioni sui processi, sessioni utente, carico medio, memoria e così via. L'applicazione fornisce test specifici per Windows®, test per Linux/UNIX e controlli indipendenti dalla piattaforma. A differenza dei test per Windows, per i test per Linux/UNIX è necessaria l'installazione di un agente di monitoraggio remoto nel client.
È inoltre disponibile un test di monitoraggio per Strumentazione gestione Windows (WMI). È infatti possibile ricercare la query corretta mediante l'applicazione WMI Explorer incorporata, che consente di individuare e scegliere l'elemento appropriato, oltre che eseguire la query per verificare che restituisca i dati necessari.
Advanced Host Monitor dispone anche di diversi test correlati ai database, ad esempio un test delle query ODBC, che verifica la disponibilità di un'origine dati ODBC, esegue una query e ne controlla il risultato rispetto a un valore noto. È inoltre possibile controllare la capacità di un host di accettare sessioni in ingresso per i server di database SQL Server™, MySQL, Oracle, Postgres, Sybase e Interbase.
Sono presenti diversi testi correlati a dischi e file per semplificare il controllo della disponibilità di spazio libero, quote, cartelle o file e condivisioni UNC. Sono inoltre disponibili i test standard correlati alla rete: controlli CP/UDP generali, test di posta elettronica (per SMTP, POP3 e IMAP), controlli di inoltro di posta elettronica, test di tempi e contenuti HTTP e così via. È possibile inoltre creare interdipendenze fra i test di monitoraggio per collegare i controlli in cascata, un'opzione molto utile. I test possono essere programmati in base a quelle che vengono definite pianificazioni regolari e irregolari, consentendo una certa granularità nei modelli di test.
Alcuni metodi di avviso prevedono l'invio di messaggi tramite SMS, ICQ, posta elettronica, un registro eventi o una finestra popup oppure possono generare altri eventi, ad esempio l'avvio o l'arresto di servizi, il riavvio del computer o l'esecuzione di un programma esterno.
Con entrambe le versioni Professional ed Enterprise di Advanced Host Monitor, è disponibile KS-Soft IP-tools, un insieme di 19 utilità di rete TCP/IP che include scansioni di porte/protocolli e monitoraggio delle trap SNMP, che consentono di ricevere ed elaborare messaggi trap SNMP. Le due versioni dispongono inoltre di un analizzatore di registro e di un componente per la creazione di report che consentono di rilevare le tendenze dei dati di monitoraggio cronologici per i report sui tempi di attività e le revisioni di analisi delle prestazioni.
L'interfaccia stessa fornisce una rapida panoramica su più test contemporaneamente e, grazie ad essa, è possibile individuare con facilità i problemi relativi agli host monitorati.
Prezzo: 599 dollari per l'edizione Enterprise, 275 dollari per l'edizione Professional,

Pulitura disco
WinDirStat
www.windirstat.info
Come le case e gli appartamenti, le posizioni di archiviazione dei file tendono con il tempo a congestionarsi di materiale che in un dato momento aveva uno scopo, ma che ora occupa soltanto spazio prezioso. Una piccola pulizia di primavera può essere molto utile, ma, a differenza delle case, una struttura di directory non fornisce alcun indizio visivo chiaro su dove iniziare l'operazione di rimozione degli elementi inutili. Esiste fortunatamente un ottimo strumento di visualizzazione in grado di semplificare l'individuazione dei file che occupano molto spazio.
Il programma GPL WinDirStat, uno strumento per Windows ispirato da kdirstat per Linux KDE, visualizza i file presenti sull'unità selezionata come una serie di rettangoli colorati. Le dimensioni dei rettangoli rappresentano quelle dei file e consentono quindi di individuare con facilità i vecchi file ISO o ZIP non necessari.
Una volta selezionata l'unità locale (o un insieme di unità locali), il programma analizza la struttura di directory creando una mappa in memoria dei file e quindi ne presenta la visualizzazione nel riquadro inferiore della GUI. Facendo clic su un rettangolo colorato all'interno di questo riquadro, la visualizzazione del riquadro superiore (simile a Esplora risorse) si sposta alla posizione del file con l'indicazione di utili dati statistici, ad esempio la dimensione file, la data dell'ultima modifica e altri attributi. Viene inoltre visualizzata la percentuale della sottostruttura occupata dal file.
I colori variano a seconda dei tipi di file. Se si fa clic su un tipo di file nella parte superiore destra, nel riquadro inferiore verranno evidenziati tutti i file di quel determinato tipo. Questa funzionalità risulta utile, ad esempio, quando è necessario identificare tutti quegli MP3 nascosti che gli utenti hanno nel file server. È inoltre possibile visualizzare la percentuale di byte occupata da tali file nella partizione.
Prezzo:Download gratuito.

Recensioni
Enemy at the Water Cooler
syngress.oreilly.com
Per quasi tutte le aziende è indispensabile essere connesse a Internet e la maggior parte di esse è consapevole dei pericoli rappresentati dai tentativi di attacco pressoché costanti provenienti dall'esterno, tanto da compromettere i punti di connessione che dividono la parte "esterna" da quella "interna" della loro infrastruttura informatica. Tuttavia, molte trascurano la minaccia ancora più dannosa presente all'interno dell'organizzazione. Le potenzialità di queste cosiddette minacce dall'interno vengono accuratamente illustrate nel libro Enemy at the Water Cooler: Real-Life Stories of Insider Threats and Enterprise Security Management Countermeasures di Brian Contos (Syngress, 2006).
L'autore fornisce esempi di storie vere di attacchi compiuti in passato illustrandone le conseguenze sulle aziende coinvolte e afferma che la protezione è un processo continuo costituito da una "combinazione di persone, processi e tecnologie". Attraverso questo libro, l'autore mira a illustrare le potenzialità delle soluzioni software di gestione della protezione aziendale (ESM, Enterprise Security Management) per attenuare le minacce dall'interno.
In quanto responsabile della sicurezza di ArcSight, Contos ricorre molto spesso a presentazioni della soluzione software ESM della sua azienda, ma questo non sminuisce il valore complessivo del suo lavoro. Il libro manca di dettagli tecnici approfonditi, ma consente di farsi un'idea delle aree in cui migliorare i processi di protezione all'interno della propria organizzazione, attraverso l'analisi degli errori altrui e la conoscenza di ciò che una soluzione ESM correttamente implementata è in grado di fare per ridurre l'esposizione a un attacco dall'interno.
Nel capitolo di introduzione "Cyber Crime and Cyber Criminals 101", Contos fornisce una panoramica su alcuni dei diversi tipi di autori di attacchi e sulle loro motivazioni con un breve riepilogo delle tecniche impiegate, quali sovraccarichi del buffer, impacchettamento del codice e minacce Warhol.
Nel capitolo successivo vengono esaminati in modo più approfondito gli aspetti specifici delle minacce dall'interno, tra cui i sistemi mediante i quali un dipendente interno può danneggiare l'azienda, il concetto di gestione del rischio e il modo in cui affrontare le minacce da un punto di vista tecnico. In questo ambito viene fornita una breve panoramica sui privilegi minimi, l'autenticazione avanzata, il controllo dell'accesso, il rilevamento e la gestione degli incidenti, aprendo così la strada a una discussione sulle soluzioni software ESM. Come già accennato, si tende a trattare unicamente il prodotto ArcSight, ma l'analisi delle funzioni chiave è applicabile a qualsiasi sistema.
Nel libro vengono presentati alcuni scenari estratti da un campione rappresentativo di vari settori e ambienti, con informazioni dettagliate sui diversi tipi di minacce dall'interno e su come sono state individuate (e talvolta attenuate). Questi casi di studio potrebbero fare luce su alcune procedure aziendali in uso e forse offrire soluzioni per la riduzione del rischio di attacchi dall'interno.
Prezzo: $49.95.

Scrivi a Casella degli strumenti
Se hai uno strumento o un'utilità che vorresti vedere recensiti qui, scrivi all'autore all'indirizzo tntools@microsoft.com.

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


 SQL: Domande&amp;Risposte: Clustering interno, blocchi misteriosi, account dell'amministratore di sistema e altro ancora
SQL: Domande&Risposte
Clustering interno, blocchi misteriosi, account dell'amministratore di sistema e altro ancora
A cura di Nancy Michell

D: Ho bisogno di comprendere meglio il funzionamento del clustering. Il nostro ambiente sarà costituito da Windows Server® 2003 a 64 bit in cui viene eseguito SQL Server™ 2005, una Web farm SQL Server Reporting Services (SSRS) (distribuzione con scalabilità orizzontale del server di report), un server di catalogo TempDB SSRS e SQL Server che distribuisce i dati da un database di terze parti tramite un server collegato e in cui verranno memorizzati i dati per SSRS.
Desideriamo un cluster a 3 nodi attivo/attivo/passivo. Il nodo 1 dovrebbe essere attivo e servire per memorizzare i dati distribuiti dal database di terze parti. Il nodo 2 dovrebbe essere anch'esso attivo e servire per memorizzare il catalogo SSRS. Il nodo 3 dovrebbe essere passivo e servire come failover per il nodo 1 o 2. È possibile avere un aiuto?

A: Sfortunatamente, sono in troppi a essere fuorviati dai termini attivo/attivo e attivo/passivo quando si tratta di clustering di SQL Server. Si pensa, infatti, che il clustering di SQL possa supportare la "scalabilità orizzontale" di un'istanza di database o di SQL su più server. Ma non è così. In SQL Server, non è disponibile un'istanza o un database attivo/attivo. Per istanza "istanza" si intende un'installazione di SQL Server con i database corrispondenti. Il nostro clustering per l'istanza di SQL Server è sempre di tipo attivo (1) a passivo (n) (si noti che il valore di n varia da 1 a 7 a seconda della versione di SQL Server) ed è per questo motivo che viene chiamato clustering di failover.
Una volta compreso questo, è possibile iniziare a considerare l'installazione di più istanze di clustering di failover in un set di nodi. Ad esempio, tre server fisici che utilizzano dischi condivisi potrebbero avere un'istanza attiva per impostazione predefinita sul nodo 1 e una seconda istanza attiva per impostazione predefinita sul nodo 2, con il failover di entrambe eseguito sul nodo 3. Le istanze sono completamente separate, non condividono dati e non sono di tipo attivo/attivo. Sono invece entrambe di tipo attivo/passivo e condividono la stessa istanza di failover. Se il failover di entrambe viene eseguito sul nodo 3, la sfida consiste nel sapere se cederà sotto il carico. Strutturalmente, il failover è progettato per basarsi su una capacità di elaborazione uguale. Se, per l'elaborazione in condizioni di funzionamento normale, per un carico di picco sono necessari due nodi, difficilmente il nodo 3 sopravvivrà al carico di picco normalmente assegnato a due nodi.
Ciò detto, dato il costo dell'hardware in grado di eseguire un cluster, è comprensibile che le persone valutino la probabilità di un errore simultaneo di entrambi i nodi principali che costringe l'intero carico su un solo nodo. In virtù di tale considerazione, è possibile decidere di assumersi il rischio anziché acquistare hardware con una capacità di failover al 100 percento.
Per fortuna ci sono anche delle buone notizie: SQL Server 2005 è dotato di un numero maggiore di opzioni per l'alta disponibilità (HA, High Availability), con alternative in grado di eseguire il failover più rapidamente rispetto a un cluster e che possono prevedere persino copie duplicate di dati (il clustering si basa su una singola SAN). Tra queste sono incluse il mirroring, la replica peer-to-peer e altre opzioni. Grazie a queste nuove alternative, sono disponibili molte più opzioni in grado di soddisfare ogni sorta di esigenze, inclusa la possibilità di combinare diverse funzionalità per l'alta disponibilità.
Microsoft® Cluster Configuration Validation Wizard (ClusPrep), attualmente disponibile per il download, sostituisce quello che in precedenza era il test mediante Hardware Certification List (HCL), in base al quale potevano essere necessari mesi per convalidare una configurazione completa al fine di ritenerla in grado di supportare condizioni di clustering. Lo strumento di convalida dell'hardware viene ora posto nelle mani dell'amministratore di database, con un'ulteriore riduzione dei costi (in termini di denaro e di tempo) per la certificazione dell'hardware e la possibilità di convalidare e distribuire anche hardware eterogeneo all'interno di un singolo set di nodi del cluster.

D: Dopo 12 ore, una procedura di eliminazione in uno dei computer risulta sospesa, ma non bloccata. L'esame del piano delle query più lente rivela la presenza di un trigger in esecuzione per 87.327 secondi, facendo presupporre una sospensione della procedura in tale trigger. In che modo è possibile visualizzare l'istruzione in sospeso?

R: È molto probabile che un ciclo all'interno del trigger non abbia termine per vari motivi. Se la sospensione dura da molto tempo e si desidera visualizzare l'istruzione in esecuzione, eseguire il codice illustrato nella Figura 1. In questo modo verrà restituita l'istruzione attualmente in esecuzione, che dovrebbe essere quella che sta causando la sospensione del computer.
Figure 1 Individuazione dell'istruzione attualmente in esecuzione (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

D: Ho necessità di supportare la replica transazionale attraverso un firewall. Il server di pubblicazione e quello di distribuzione si trovano all'esterno del firewall, il sottoscrittore all'interno. L'ascolto del sottoscrittore è impostato su 1433 e i nomi dei computer utilizzati sono i seguenti: server di pubblicazione: PUBMACHINE, server di distribuzione: DISTMACHINE, sottoscrittore: SUBMACHINE. Quali porte è necessario aprire per consentire la riuscita della snapshot iniziale e del push di pubblicazione?

R: Se si utilizza una sottoscrizione push, l'apertura della porta SQL Server (1433 nel caso specifico) dovrebbe essere sufficiente, dato che l'agente di distribuzione verrà eseguito nel computer di distribuzione (all'esterno del firewall) e probabilmente disporrà di accesso locale ai file di snapshot generati dall'agente snapshot. Se invece si utilizza una sottoscrizione pull, l'agente di distribuzione in esecuzione nel computer del sottoscrittore dovrà in qualche modo accedere ai file di snapshot attraverso il firewall. Ecco le opzioni da prendere in considerazione.
Partendo dal presupposto che i file di snapshot siano già accessibili da una condivisione file all'esterno del firewall, è possibile aprire le porte di condivisione file di Windows® attraverso il firewall, in modo che l'agente di distribuzione in esecuzione all'interno del firewall possa accedere ai file di snapshot situati all'esterno (fare attenzione alle implicazioni di protezione che questa operazione può comportare per altre parti dell'infrastruttura). Si noti che, se è stato configurato un percorso locale come posizione predefinita della snapshot (impostazione predefinita di SSMS), potrebbe essere necessario utilizzare l'opzione /AltSnapshotFolder dell'agente di distribuzione per sostituire la posizione di prelievo del file di snapshot.
È inoltre possibile configurare la replica in modo da utilizzare l'FTP per il trasferimento dei file di snapshot (in questo caso è necessario aprire la porta 21).

D: Vorrei sapere se la disattivazione dell'account dell'amministratore di sistema in SQL Server 2005 presenta degli inconvenienti e se costituisce un reale valore aggiunto per la protezione. Esiste un white paper sull'argomento?

R: In una nuova installazione di SQL Server 2005 senza attivazione della modalità mista, l'account dell'amministratore di sistema è disattivato per impostazione predefinita e per esso viene generata automaticamente una password. È comunque possibile eseguirne la disattivazione manuale. Non esiste un white paper a proposito, ma la disattivazione e la ridenominazione degli account di accesso sono trattate in un articolo sulle procedure consigliate.
Se si desidera proteggersi da tentativi di violazione dell'account dell'amministratore di sistema, è possibile anche ridenominarlo. Non dimenticare che, se si attiva un account disattivato, è necessario impostare per esso una nuova password.
Per rispondere alla domanda se questa operazione offra un'effettiva protezione, ricordare che la maggiore protezione fornita dalla disattivazione dell'account deriva dal fatto che è inutile indovinare la password quando l'account è disattivato. Indipendentemente dal tempo a disposizione del pirata informatico o del virus, un attacco di forza bruta a un account bloccato non avrà mai esito positivo. Con la ridenominazione o la disattivazione dell'amministratore di sistema, le applicazioni che per la connettività dipendono dall'utilizzo di questo account verranno interrotte. L'individuazione e la modifica o l'eliminazione di queste applicazioni vanno quindi considerate in ogni caso come priorità. Come già accennato, l'account non può essere utilizzato per la connessione al database fino a quando non viene riattivato. Inoltre, poiché il processo di autenticazione non riesce in precedenza, un tentativo fallito richiederà un carico minore sul sistema attaccato.

D: In uno dei database di elaborazione delle transazioni in linea (OLP) di dimensioni maggiori è presente un file di registro la cui dimensione è il doppio di quella del file di dati. Ho tentato di utilizzare i comandi seguenti per ridurre il file di registro a una dimensione ragionevole, ma è necessario ridurlo ulteriormente:
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

R: È consigliabile modificare il database di backup in un'istruzione del registro di backup. In alternativa, è possibile impostare il database in modalità di ripristino semplice ed eseguire l'istruzione shrinkfile. Al termine della compattazione del registro, impostare il database sul modello di recupero precedente ed eseguire il backup del database. Se ancora non si ottiene una compattazione, verificare che non siano presenti transazioni aperte (utilizzare dbcc opentran). Ulteriori informazioni sono disponibili nell'articolo seguente della Knowledge Base: support.microsoft.com/kb/907511.

D: Se si verifica un failover durante un processo pianificato di SQL Server Agent, cosa succede al processo dopo il failover? Devo riavviarlo manualmente?

R: Sì, è necessario avviarlo manualmente se non è in atto qualche altro processo. Se non si vuole riavviare manualmente i processi, è possibile scrivere uno script che consente di aggiornare una tabella una volta terminato un processo. Se il valore è uguale a 1, il processo è stato eseguito. Ogni altro valore indica che il processo non è stato completato e verrà eseguito successivamente un secondo processo con l'emissione del comando di avvio. Pertanto, anche se il processo deve essere eseguito nuovamente se si verifica un failover durante il suo passaggio, mediante uno script è possibile ridurre in parte le preoccupazioni legate a questi processi notturni fondamentali che devono essere assolutamente completati prima della giornata lavorativa seguente.
Suggerimento: aggiornamento e DBCC UPDATEUSAGE
Si sta eseguendo l'aggiornamento da SQL Server 2000 a SQL Server 2005?
In tal caso, accertarsi di eseguire DBCC UPDATEUSAGE immediatamente dopo l'aggiornamento dei database.
Il comando DBCC UPDATEUSAGE segnala e corregge le pagine e le inesattezze di conteggio delle righe nelle viste del catalogo, un'operazione necessaria perché queste inesattezze potrebbero causare la restituzione di report sull'utilizzo dello spazio non corretti da parte della stored procedure di sistema sp_spaceused. In SQL Server 2005, questi valori sono sempre mantenuti in modo corretto e pertanto nei relativi database non saranno mai presenti conteggi inesatti. Poiché è invece possibile che i database aggiornati a SQL Server 2005 contengano conteggi non validi, è consigliabile eseguire DBCC UPDATEUSAGE dopo l'aggiornamento.
Funzionamento di DBCC UPDATEUSAGE Questo comando corregge le righe, le pagine utilizzate, le pagine riservate, le pagine foglia e i conteggi delle pagine di dati per ogni partizione di una tabella o di un indice. Se nelle tabelle di sistema non ci sono inesattezze, non viene restituito alcun dato. Se invece vengono rilevate e corrette inesattezze e non è stato utilizzato WITH NO_INFOMSGS, vengono restituite le righe e le colonne aggiornate nelle tabelle di sistema.
DBCC UPDATEUSAGE può inoltre essere utilizzato per sincronizzare i contatori di utilizzo dello spazio. Poiché la sua esecuzione può richiedere del tempo in caso di tabelle o di database di grandi dimensioni, è in genere consigliabile utilizzare tale comando solo quando si sospetta la restituzione di valori non corretti da parte di sp_spaceused. Si noti che sp_spaceused accetta un parametro facoltativo per l'esecuzione di DBCC UPDATEUSAGE prima di restituire le informazioni sullo spazio relative alla tabella o all'indice.
In SQL Server 2005, DBCC CHECKDB è stato migliorato per rilevare quando i conteggi delle pagine o delle righe diventano negativi. In questo caso, verrà visualizzato un avviso in cui viene consigliato di eseguire DBCC UPDATEUSAGE per risolvere il problema. Sebbene il problema sembri causato dall'aggiornamento del database a SQL Server 2005, i conteggi inesatti esistevano già prima della procedura di aggiornamento.
Come esempio, ecco come aggiornare i conteggi delle pagine, delle righe o di entrambe per tutti gli oggetti presenti nel database corrente. Con il comando seguente viene specificato 0 come nome del database e vengono restituite le informazioni aggiornate relative al database corrente:
DBCC UPDATEUSAGE (0);
GO
Per aggiornare i conteggi delle pagine, delle righe o di entrambe per, ad esempio, AdventureWorks, e inoltre sopprimere i messaggi informativi, eseguire un comando simile al seguente, mediante cui viene specificato AdventureWorks come nome del database e quindi vengono soppressi tutti i messaggi informativi:
USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO
Per ulteriori informazioni, ricercare DBCC UpdateUsage nella documentazione in linea di SQL Server.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 Utilit&#224; sotto i riflettori: SMSMap
Utilità sotto i riflettori
SMSMap
Jeff Tondt
Scarica il codice per questo articolo: UtilitySpotlight2007_07.exe (2477KB)

Un'immagine vale mille parole. Questo famoso proverbio richiama il concetto per cui è possibile comunicare storie complicate con una singola immagine o anche che un'immagine può essere più convincente di una considerevole quantità di testo. Descrive inoltre in modo appropriato gli obiettivi della visualizzazione, per la quale è necessario assimilare rapidamente notevoli quantità di dati.
Per un appassionato di System Management Server (SMS) come me, la possibilità di visualizzare l'intera gerarchia di SMS in un'immagine mi aiuta a comprendere l'organizzazione dell'infrastruttura. Una tale immagine potrebbe essere utilizzata, ad esempio, per presentare ai responsabili la situazione preliminare e successiva di un piano di migrazione di SMS. In determinati casi di risoluzione dei problemi, un tale diagramma potrebbe rivelarsi molto utile nella ricerca di una soluzione o almeno per ricevere aiuto da altri. Inoltre, qualsiasi amministratore di SMS responsabile deve documentare la gerarchia del sistema per una miriade di altre ragioni.

Acquisizione dell'immagine
Un diagramma del genere può anche essere tracciato direttamente. È senza dubbio possibile rimboccarsi le maniche, disegnare manualmente la gerarchia di SMS e documentare manualmente le impostazioni del sito. Se i server SMS sono monitorati da Microsoft® Operations Manager (MOM), è possibile fare in modo che quest'ultimo generi il diagramma della gerarchia, sebbene sia necessario osservare che MOM non è molto orientato all'immagine e certamente non documenta le impostazioni del sito. È probabile che siano disponibili altri metodi o strumenti pratici, ma non ho ancora trovato nulla di soddisfacente che sia in grado di creare un'immagine efficace e aiuti a documentare le impostazioni del sito.
Quindi ho deciso di crearne uno per conto mio e così è nato SMSMap 1.0. SMSMap è un'applicazione Visual Basic® .NET che utilizza le librerie gestite di SMS disponibili nell'SDK di SMS e automatizza Microsoft Visio® tramite COM. L'utilità esegue una query sul server di un sito SMS di destinazione, crea quindi un semplice diagramma di Visio ed esporta le impostazioni del sito in un file XML. La scelta XML è stata determinata dal fatto che rappresenta il metodo più compatibile per documentare le impostazioni del sito. Ho scelto di illustrare anche i ruoli SMS, non solo i server fisici correlati ad altri server SMS. Questo consente di manipolare il diagramma tramite i livelli di Visio per osservare la gerarchia di SMS da diversi punti di vista.
Figura 1 Formato radiale
Figura 1 Formato radiale
Attualmente, il programma consente di selezionare sei formati diversi per il diagramma di Visio. Ad esempio, nella Figura 1 è illustrata una gerarchia di SMS molto semplice che utilizza il formato radiale, mentre nella Figura 2 è illustrata la stessa gerarchia con l'ausilio del formato diagramma di flusso. L'utilità funziona altrettanto bene con gerarchie molto più grandi, ma in questo contesto ho preferito privilegiare la semplicità.
Figura 2 Formato diagramma di flusso
Figura 2 Formato diagramma di flusso
È probabile che l'evoluzione futura di SMSMap preveda la documentazione di tutte le impostazioni del sito. Attualmente, vengono documentati solo i ruoli del sito SMS e tutte le delimitazioni. Con il minimo sforzo, è possibile esportare molte altre impostazioni del sito nel file XML.

Utilizzo di SMSMap
I file del codice sorgente e di installazione di SMSMap sono disponibili sul TechNet Magazinehttp://www.technetmagazine.com/code07.aspx. Per l'installazione, è sufficiente eseguire SMSMapSetup.msi, che guida nello svolgimento della procedura. Va ricordato che SMSMap utilizza Visio, che quindi deve essere già stato installato. Dopo l'installazione, eseguire C:\Program Files\Microsoft\smsmap\smsmap.exe, a meno che non sia stata scelta una posizione di installazione diversa da quella predefinita.
SMSMap può essere eseguito da qualsiasi computer, non necessariamente dal server del sito, anche perché è abbastanza improbabile che nei server dei siti SMS sia installato Visio. Immettere il nome del Site Server SMS dal quale deve essere originata la query. Questo può essere il sito centrale se la query deve includere l'intera gerarchia o un qualsiasi server del sito primario figlio, nel qual caso si ottiene solo la gerarchia a partire da quel punto. Quindi, immettere l'account che ha l'autorizzazione per eseguire la query di SMS utilizzando il formato dominio\nome utente e la relativa password. La password non verrà visualizzata, garantendo così la riservatezza anche in presenza di altri.
Sei pulsanti di opzione consentono di selezionare il layout ed è possibile scegliere se rappresentare o meno i ruoli SMS nel disegno. Queste caselle di controllo sono situate nella scheda Options. La pressione del pulsante Draw avvia l'utilità. Per prima cosa viene verificata la disponibilità di Visio, quindi viene eseguita la query del server del sito primario di SMS e vengono aggiunti gli oggetti al diagramma di Visio. L'aspetto del diagramma di Visio durante lo scaricamento degli oggetti non è ottimale, ma al termine SMSMap provvede a organizzarli in base al formato selezionato inizialmente.
Approfondimenti
Fin qui è stato illustrato il motivo e il modo in cui documentare la gerarchia di SMS utilizzando SMSMap. Per gli sviluppatori che prediligono gli aspetti più tecnici passiamo a esaminare più da vicino il funzionamento dell'utilità.
Per raccogliere le informazioni, SMSMap utilizza Managed SMS Site Server Interfaces e gli assembly di interoperabilità primaria di Visio per generare un diagramma di Visio che organizza tutte le forme necessarie. SMS 2003 SDK versione 3.1 contiene la versione più recente delle Managed SMS Site Server Interfaces. Questo set di interfacce gestite consente di connettere e configurare un SMS Site Server tramite qualsiasi linguaggio o applicazione compatibile con Microsoft .NET Framework.
Le interfacce utilizzano lo spazio dei nomi di System.Management per interagire con un provider SMS tramite Strumentazione gestione Windows® (WMI). Per utilizzare le interfacce è necessario sviluppare l'applicazione tramite un linguaggio compatibile con .NET, ad esempio, C#, Visual Basic .NET e così via, e fare riferimento al file Microsoft.SystemsManagementServer.Automation.dll fornito dall'assembly .NET con SMS SDK.
Le classi di .NET Management eliminano molte delle idiosincrasie del modello a oggetti WMI per proporre un modello orientato agli oggetti coerente. Le attività di base di connessione WMI, enumerazione di oggetti, esecuzione di metodi, eliminazione di oggetti, recupero di oggetti e cattura di eventi possono essere ottenute tramite le classi di .NET Management.

Assembly di interoperabilità primaria di Visio
Un assembly di interoperabilità primaria consente di utilizzare codice gestito per controllare applicazioni COM quali Visio a livello di programmazione. Gli assembly di interoperabilità primaria di Visio consentono di integrare ed estendere la funzionalità di Visio in applicazioni gestite.
Se .NET Framework è già presente sul computer, quando successivamente viene installato Visio, il programma di installazione aggiunge gli assembly di interoperabilità primaria di Visio alla Cache di assembly globale nel computer. È possibile aggiungere un riferimento agli assembly di interoperabilità primaria di Visio dalle applicazioni gestite.
Dopo avere aggiunto il riferimento al progetto, è possibile iniziare a lavorare con gli oggetti di Visio dall'applicazione gestita. Visio dispone di un modello a oggetti esteso che fornisce un set di classi, interfacce ed enumerazioni in modo che sia possibile creare diagrammi a livello di programmazione.

Flusso del programma
Dopo avere descritto le interfacce componente principali di Visio e SMS, verrà illustrato il flusso dell'utilità stessa.
La prima cosa da fare quando si utilizzano le interfacce gestite è stabilire la connessione con il provider SMS. Ciò può essere ottenuto creando una nuova istanza della classe SMSProvider. Internamente, questa classe individuerà il fornitore SMS per il server del sito specificato e si connetterà tramite un set di credenziali specifico. Se il provider si trova nel computer locale, per la connessione verranno utilizzate le credenziali dell'utente attualmente connesso invece di quelle fornite. Anche se è possibile seguire SMSMap sul server SMS, è consigliabile scegliere una workstation separata sulla quale è installato Visio. Per ovvie ragioni, sulla maggior parte dei server del sito SMS Visio non è installato.
Quando si accede ai dati sul sito SMS tramite la classe SMSProvider, i diritti di protezione vengono considerati come se venisse utilizzata la console di amministrazione SMS. Questo significa, ad esempio, che se si tenta di configurare le impostazioni per un server del sito tramite SMSProvider, l'account utilizzato per la connessione al provider deve disporre dello stesso set di diritti che verrebbe utilizzato con la console di amministrazione.
La classe SMSProvider fornisce un metodo GetSiteSettings che consente di ottenere le impostazioni del sito corrente, al quale appartiene il provider, o di qualsiasi sito con un codice di sito specifico. Il frammento di codice illustrato nella Figura 3 mostra la connessione di SMSMap al provider del server del sito di destinazione. Le credenziali utente devono essere passate nel formato Dominio\Utente. È anche possibile specificare "." per indicare il computer corrente. Nella Figura 3 è incluso anche il codice che consente di visualizzare il risultato nell'interfaccia utente e nel registro.
Figure 3 Frammento di GetSiteSettings (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
Il passaggio successivo consiste nel configurare il file XML per la raccolta e la registrazione delle informazioni SMS per il server del sito di destinazione, come illustrato nella Figura 4.
Figure 4 Creazione del file XML (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
Quindi, il sito di destinazione deve essere disegnato nel diagramma di Visio e aggiornato nell'interfaccia utente e nel registro, come si può vedere nella Figura 5.
Figure 5 Disegno del sito in Visio (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
Per scorrere l'intera gerarchia nel sito di destinazione, viene eseguito lo stesso codice di base descritto in precedenza che esegue la query di SMS e disegna in Visio. Questa funzione è denominata Level e viene richiamata in modo ricorsivo per garantire che la query consideri tutti i siti figlio indipendentemente dalla dimensione della gerarchia. Level raccoglie le informazioni del sito SMS e le registra nel file XML, nell'interfaccia utente e nel registro per ciascun sito figlio compreso nel sito di destinazione. Infine, nella Figura 6 viene illustrata la formattazione del diagramma di Visio mediante il formato selezionato all'avvio dell'utilità. Quindi, il file XML e il registro vengono chiusi.
Figure 6 Conclusioni (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

Per iniziare
Ovviamente, questo è solo un inizio e vi sono molte possibilità di miglioramento. I punti di gestione della periferica richiedono un approfondimento in quanto non sono presenti nell'SDK. Per documentare completamente un sito è possibile aggiungere altre impostazioni. È possibile inoltre aggiungere una varietà più ampia di impostazioni di layout di Visio per ottenere un risultato visivamente migliore delle gerarchie piccole e grandi. Ciascun tipo di layout comporta difficoltà specifiche nella creazione di visualizzazioni efficaci. Inoltre, un altro passo importante è certamente l'aggiunta del supporto di System Center Configuration Manager 2007. Tuttavia, anche questa prima versione di SMSMap è in grado di aiutare gli amministratori di SMS a visualizzare il quadro generale e sperimentare alcuni scenari con i livelli e la trasparenza di Visio.
Se si esegue il download del codice sorgente, è possibile ampliare l'utilità in modo da soddisfare esigenze specifiche. SMSMap è stato testato su Windows XP SP2 con Visio 2003 e Windows Vista™ Enterprise con Visio 2007. Qualsiasi suggerimento per migliorare questa utilità può essere inviato per posta elettronica a jeff.tondt@microsoft.com.

Jeff Tondt è un consulente senior dei servizi di consulenza Microsoft. Lavora in particolare nelle aree di gestione dei sistemi, automazione e gestione delle patch. È un esperto di SMS (System Management Server) e può essere contattato all'indirizzo jeff.tondt@microsoft.com.


 Funzionamento di IT: Risoluzione degli errori RPC
Funzionamento di IT
Risoluzione degli errori RPC
Zubair Alexander

A chi nel corso degli anni ha lavorato con piattaforme server Windows sarà probabilmente capitato di incontrare errori di chiamata a una procedura remota (RPC, Remote Procedure Call). Tali errori segnalano che il server RPC non è disponibile o che non ci sono più endpoint disponibili oppure forniscono qualche altro avviso enigmatico. Se questi messaggi creano disorientamento, consiglio di continuare a leggere. In questo articolo verranno
infatti esaminati alcuni errori comuni e varie tecniche da utilizzare per identificare gli errori RPC visualizzati e verranno illustrate alcune soluzioni a problemi specifici. Ma prima di affrontare gli errori RPC specifici e le relative soluzioni, sarà utile una solida base per quanto riguarda la terminologia RPC.

Che cos'è RPC?
RPC è un metodo di comunicazione interprocesso (IPC, Interprocess Communication) utilizzato da client e server per comunicare gli uni con gli altri. In poche parole, viene utilizzato dai programmi, in genere in un computer client, per eseguire un programma in un computer server. I client Microsoft® Outlook®, ad esempio, comunicano con Microsoft Exchange Server mediante RPC. Il computer client invia un messaggio al computer server con determinati argomenti e il server risponde al client con un messaggio contenente i risultati del programma eseguito.
Parte integrante di questo processo è l'endpoint, ovvero la porta o il gruppo di porte in un computer che viene monitorato da un server per rilevare le richieste dei client in ingresso. Più specificatamente, si tratta di un indirizzo specifico della rete di un processo server utilizzato per le chiamate RCP.
L'Endpoint Mapper, che fa parte del sottosistema RPC, si occupa della risposta alle richieste dei client per la risoluzione degli endpoint dinamici e in alcune situazioni esegue anche l'assegnazione dinamica degli endpoint ai server.
Un altro importante componente RPC è il servizio Localizzatore, che gestisce un elenco di servizi e server RPC sulla rete. Un client Windows® si connette al controller di dominio sulle porte SMB (Server Message Block) (TCP 139 e 445) ed esegue la ricerca dei servizi o dei server RPC attraverso il servizio Localizzatore.
La maggior parte dei servizi Windows incorporati comunica reciprocamente mediante RPC. Ad esempio, i servizi di certificazione, DCOM, FRS, MSMQ, MAPI e il servizio di replica di Active Directory® utilizzano RPC per la comunicazione. Di conseguenza, se il servizio RPC non funziona correttamente su una rete, è possibile che si verifichino vari problemi di comunicazione.

Errori RPC
Esaminiamo ora alcuni dei possibili errori che possono verificarsi in relazione al servizio RPC, anche se non si tratta assolutamente di un elenco completo.
Quando il servizio di Replica file ha esito negativo, potrebbe trattarsi del temuto errore di RPC non disponibile. Se si tenta di eseguire il mapping di un'unità, è possibile che venga restituito un errore di accesso negato. Quando si utilizza Utenti e computer di Active Directory, potrebbe essere visualizzato un messaggio di errore che comunica che il dominio specificato non esiste o non è raggiungibile. Durante l'accesso a un dominio potrebbe essere restituito un messaggio di errore che segnala che è impossibile accedere al dominio poiché l'account del computer del sistema nel dominio primario è assente o la relativa password non è corretta.
Quando il client Microsoft Outlook tenta di comunicare con Exchange Server, in caso di errori RPC è possibile che venga restituito al client un messaggio fuorviante in cui viene comunicato che le informazioni per l'accesso non sono corrette o che è impossibile eseguire l'accesso.
Oltre a questi errori, quando il servizio RPC non è disponibile, potrebbero verificarsi altri problemi. Ad esempio, potrebbe non essere possibile sfogliare il dominio in Risorse di rete o aprire lo snap-in Criteri di gruppo.
Questi sono solo alcuni dei casi in cui non ci si aspetta che la causa dei problemi sia dovuta a chiamate RCP. Ce ne sono molti altri e, ogni volta che si ha a che fare con processi remoti, gli errori RPC possono essere la causa principale delle difficoltà incontrate. Come riconoscere con certezza e soprattutto individuare l'errore esatto? Andiamo a scoprirlo.

Risoluzione dei problemi
Se si sospettano problemi con il servizio RPC, esistono alcuni strumenti che possono essere utilizzati per individuare i problemi.
Uno di questi è lo strumento Repadmin. Questo programma viene solitamente utilizzato per monitorare e risolvere i problemi di replica di Active Directory, ma può essere utilizzato anche per risolvere i problemi dell'RPC Endpoint Mapper. Per eseguirlo, al prompt dei comandi, digitare repadmin /bind. Se si sono verificati problemi RPC, è possibile che venga visualizzato un messaggio del tipo: "Nessun endpoint disponibile nel mapping degli endpoint". Questo è il primo indizio di problema correlato al servizio RPC.
Un'altra possibilità consiste nell'utilizzare lo strumento di diagnostica del controller di dominio (DCDiag), un programma da riga di comando per la diagnosi dei problemi relativi ai controller di dominio. Se viene visualizzato un messaggio di errore in cui viene indicato uno stato 1722 e che il server RPC non è disponibile, significa che è presente un problema RPC appena individuato dallo strumento di diagnostica del controller di dominio.
Quando si utilizza Ntdsutil (uno strumento da riga di comando utilizzato per la gestione di Active Directory e l'esecuzione di varie attività di manutenzione), a volte possono verificarsi errori RPC durante il tentativo di connessione al server. Molto probabilmente verrà visualizzato uno degli errori più comuni, ad esempio "Nessun endpoint disponibile nel mapping degli endpoint". Ancora una volta, si tratta di un indizio di possibili problemi con il servizio RPC. Anche lo strumento Gpotool, che verifica la coerenza degli oggetti Criteri di gruppo nei controller di dominio, restituirà errori simili se la causa è imputabile al servizio RPC.
Il file Dcpromo.log, che viene generato quando un server Windows 2000 Server o Windows Server® 2003 viene promosso a controller di dominio utilizzando lo strumento Dcpromo, può rivelare anch'esso la presenza di errori RPC. Ad esempio, se la promozione non riesce, è consigliabile esaminare il log, che si trova nella cartella %windir%\debug. Gli errori elencati forniranno indicazioni secondo cui il servizio directory non è riuscito a replicare la partizione o a creare l'oggetto. Alla fine del messaggio ci sarà un codice di errore. Ecco un esempio del tipo di messaggio di errore che potrebbe essere visualizzato nel file Dcpromo.log:

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
Si noti il codice di errore 1722, che è presente quattro volte nel messaggio e indica che il server RPC non è disponibile. Nella Figura 1 sono riportati alcuni codici di errore con le relative descrizioni, ma è possibile trovarne altri all'indirizzo msdn2.microsoft.com/ms681386.
Figure 1 Codici di errore e relativa descrizione (Close Figure 1)

Codice di errore | Descrizione
58 | Il server specificato non può effettuare l'operazione richiesta.
1721 | Le risorse disponibili non sono sufficienti per completare l'operazione.
1722 | Server RPC non disponibile.
1723 | Server RPC troppo impegnato per completare l'operazione.
1727 | La chiamata di procedura remota non è riuscita e non è stata eseguita.
1753 | Nessun endpoint disponibile nel mapping degli endpoint.

Risoluzione degli errori RPC
Dopo aver visto in che modo è possibile individuare gli errori RPC, esaminiamo alcune soluzioni.
I client Microsoft si connettono all'RPC Endpoint Mapper sulla porta 135. L'Endpoint Mapper comunica quindi al client la porta su cui è in ascolto un servizio richiesto. I numeri di porta vengono assegnati in modo dinamico e sono compresi tra 1024 e 65535. Quando vengono visualizzati degli errori, ad esempio 1753, che indicano che nessun endpoint è disponibile nel mapping degli endpoint, significa che l'RPC Endpoint Mapper non è stato in grado di utilizzare per un servizio una porta di numero superiore a 1024. In seguito questo argomento verrà esaminato più in dettaglio.
La prima cosa da fare è controllare lo stato del servizio RPC sul server. A seconda del ruolo del server, lo stato del servizio RPC e del servizio Localizzatore RPC deve corrispondere a quello riportato nella Figura 2. Se uno dei due servizi non è configurato come illustrato nella figura, provare a regolare lo stato, riavviare il server e quindi eseguire un test per verificare se il problema è stato risolto.
Figure 2 Stato del servizio RPC (Close Figure 2)

Ruolo del server | Servizio RPC | Servizio Localizzatore RPC
Windows Server 2003 - Controller di dominio | Avviato, automatico | Arrestato, manuale
Windows Server 2003 - Server membro | Avviato, automatico | Arrestato, manuale
Windows Server 2003 - Server autonomo | Avviato, automatico | Arrestato, manuale
Windows 2000 Server - Controller di dominio | Avviato, automatico | Arrestato, automatico
Windows 2000 Server - Server membro | Avviato, automatico | Avviato, manuale
Windows 2000 Server - Server autonomo | Avviato, automatico | Arrestato, manuale
Verificare che sul client il ping del server che presenta problemi di connettività abbia esito positivo. Ad esempio, in caso di problemi di comunicazione con un server denominato DC1 il cui indirizzo IP è 192.168.1.200, utilizzare il comando seguente al prompt dei comandi per verificare che il DNS stia risolvendo correttamente l'host DC1:
Ping –a 192.168.1.200
Accertarsi di utilizzare l'opzione -a con l'indirizzo IP, non con il nome host.
Se tutto funziona correttamente, si dovrebbe ottenere da DC1 una risposta simile a quella illustrata nella Figura 3. Si noti che anziché risolvere semplicemente l'indirizzo IP 192.168.1.200, il ping ha risolto anche il nome host dc1.contoso.com. Questo conferma che la risoluzione del nome DNS funziona correttamente e risolve l'host dc1.contoso.com esattamente come previsto.
Figure 3 Risposta del ping (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
È inoltre consigliabile verificare che il Registro di sistema del client Windows XP o Windows 2000 contenga almeno i quattro ClientProtocols elencati nel riquadro a destra nella Figura 4.
Figura 4 RPC ClientProtocols elencati nel Registro di sistema
Figura 4 RPC ClientProtocols elencati nel Registro di sistema
Se una delle voci è assente, aggiungere un nuovo valore di stringa con il nome e il tipo di dati illustrati nella Figura 4. Per impostazione predefinita, è presente una quinta voce denominata ncacn_nb_tcp, che viene utilizzata per identificare NetBIOS su TCP come famiglia di protocolli per l'endpoint. A seconda della configurazione, è possibile che questa voce non sia elencata in ClientProtocols, ma è possibile aggiungerla manualmente per vedere se gli errori RPC vengono risolti.
Si notino le chiavi presenti nella la cartella RPC nel riquadro di sinistra della figura, ovvero ClientProtocols, NameService, Netbios e SecurityService. Se viene visualizzata una chiave denominata Internet senza valori, provare a rimuoverla e a riavviare il computer. Potrebbe essere di aiuto alla risoluzione del problema. Come sempre, prestare attenzione quando si modifica il Registro di sistema di Windows.
Poiché, come citato in precedenza, il servizio RPC utilizza porte comprese tra 1024 e 65535, è necessario che queste porte non siano bloccate da un firewall. Il modo più semplice per verificare che una porta sia aperta è utilizzare lo strumento Port Query, disponibile in due versioni: una versione da riga di comando (PortQry) e una versione GUI (PortQueryUI).
PortQry può essere scaricato dall'Area download Microsoft. Per ulteriori informazioni, vedere l'articolo "Descrizione dell'utilità della riga di comando Portqry.exe". In questo articolo viene fornita una breve descrizione dei rapporti di stato di PortQry con esempi di comandi da utilizzare per la risoluzione dei problemi. Ricordare che è possibile utilizzare anche la versione GUI, che è molto più semplice e che può essere scaricata all'indirizzo go.microsoft.com/fwlink/?LinkId=73740.
Quando si utilizza lo strumento Port Query, è necessario eseguirlo su un computer che non presenta errori RPC e quindi sul computer in cui si stanno verificando. Ad esempio, se si desidera verificare che la porta 135, utilizzata dall'RPC Endpoint Mapper, è aperta, al prompt dei comandi utilizzare PortQry come segue:
portqry -n [servername] -e 135
Sia che si utilizzi PortQuery o PortQueryUI, il risultato ottenuto dovrebbe essere simile al seguente:
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
L'ultima riga indica che la porta 135 è aperta. In caso contrario, sarebbe stato indicato NOT LISTENING.
Per verificare un intervallo di porte, inserire l'intervallo dei numeri di porta separati da virgole, ad esempio "135,1024-5000".

Ulteriori soluzioni
Se sono stati tentati tutti gli espedienti indicati fin qui e il problema resta ancora senza soluzione, sono possibili alcune opzioni aggiuntive. A seconda dei problemi specifici nell'ambiente in uso, è possibile provare con una delle modifiche seguenti nel Registro di sistema (attenzione: prima di apportare qualsiasi modifica nel Registro di sistema, è importante eseguire il backup del sistema, specialmente del Registro di sistema, in modo che, se le cose vanno male, sarà possibile ripristinare il computer nello stato precedente).
Una possibilità consiste nel regolare MaxUserPort per specificare il numero di porta massimo che può essere assegnato dal protocollo TCP quando viene richiesta una porta utente disponibile. Per impostazione predefinita, in Windows Server 2003 il valore MaxUserPort è impostato su 5000, il che significa che viene utilizzato 5000 come numero di porta massimo, anche se la voce non esiste. A seconda della configurazione, questa voce potrebbe non essere presente nel Registro di sistema, nel qual caso è possibile aggiungerla nella posizione illustrata nella Figura 5.
Figura 5 Impostazione di MaxUserPort nel Registro di sistema
Figura 5 Impostazione di MaxUserPort nel Registro di sistema
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
Quando si modifica il Registro di sistema, è necessario considerare gli altri eventuali effetti collaterali, il che non è sempre facile. La modifica di questa voce può influire su Microsoft Exchange Server nel caso in cui il valore venga impostato al di sotto di 50.000. Se Exchange Server Analyzer rileva che il valore della chiave MaxUserPort del Registro di sistema è minore di 50.000, verrà visualizzato un avviso. È consigliabile impostare il valore su 60.000; in caso contrario potrebbero essere generati messaggi di avviso del proxy NSPI (Name Service Provider Interface), ad esempio l'evento 9040. Per ulteriori informazioni, vedere il documento Microsoft "Il valore MaxUserPort è troppo basso ".
Un'altra possibilità è regolare TcpMaxDataRetransmissions. I pacchetti TCP attendono la ricezione di un riconoscimento dall'estremità ricevente. Se questo non perviene prima della scadenza del timer, i pacchetti vengono nuovamente trasmessi per il numero di volte massimo indicato da TcpMaxDataRetransmissions. Il valore predefinito per questo parametro è 5, ma è possibile provare con un valore pari a 4 o anche 3. Non utilizzare un valore inferiore a 3.
Se la voce TcpMaxDataRetransmissions del Registro di sistema non esiste, è possibile aggiungerla nella posizione seguente in questo modo:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
Per ulteriori informazioni su TcpMaxDataRetransmissions, vedere l'articolo 170359 della Microsoft Knowledge Base "Come modificare il valore di timeout massimo per la ritrasmissione TCP/IP".
Un altro valore del Registro di sistema che è possibile sperimentare è TcpTimedWaitDelay. Se un client utilizza troppe porte, è molto probabile che le porte si esauriscano prima che le connessioni chiuse vengano rilasciate dal protocollo TCP/IP. Questo avviene perché TCP/IP non rilascia la connessione fino a quando non è trascorso un periodo di tempo pari al doppio della durata massima del segmento (MSL, Maximum Segment Lifetime) (questo periodo viene definito stato di attesa). Inoltre, poiché ogni MSL è impostato su 120 secondi e TCP/IP non rilascia la connessione finché non sono trascorsi due MSL, saranno necessari 240 secondi (4 minuti) per il rilascio di una connessione chiusa. Si noti che questo è un problema noto di Windows NT® corretto con un service pack; di conseguenza ci sono oggi molte meno probabilità che si verifichi questo problema. Tuttavia, Microsoft consiglia la regolazione di questa impostazione come una delle possibili soluzioni degli errori dell'RPC Endpoint Mapper, come spiegato nell'articolo della Knowledge Base "Come risolvere un problema con l'RPC Endpoint Mapper".
TcpTimedWaitDelay viene aggiunto nel Registro di sistema nella posizione seguente:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
Per ulteriori informazioni su TcpTimedWaitDelay, vedere l'articolo della Knowledge Base "Quando le porte per i client Windows NT terminano". Sebbene non vengano consigliati valori specifici, si può provare a ridurre TcpTimedWaitDelay a 60 (secondi) in decimale, ovvero 3c in esadecimale.

Conclusioni
Gli errori RPC possono essere la causa principale di numerosi errori di comunicazione sulla rete. Esistono fortunatamente alcuni sistemi creativi con cui è possibile risolvere questi problemi di difficile comprensione. Alcuni degli strumenti suggeriti sono incorporati, mentre altri sono disponibili nel Resource Kit di Windows Server. Molti di essi sono elencati nella Figura 6. Questi strumenti possono essere utilizzati per individuare la causa e la posizione degli errori RPC per poi applicare una delle tecniche trattate in questo articolo per risolvere la condizione di errore.
Figure 6 Strumenti per la risoluzione dei problemi RPC (Close Figure 6)

Strumento | Descrizione
DCDiag | Analizza lo stato dei controller di dominio.
Visualizzatore eventi | Visualizza gli eventi registrati.
Gpotool | Determina se i criteri sono validi e coerenti.
NetDiag | Utilizzato per verificare la connettività di rete.
Network Monitor | Monitora e acquisisce informazioni sul traffico di rete.
Ntdsutil | Fornisce funzionalità di gestione per Active Directory.
PortQry, PortQueryUI | Utilizzati per verificare la connettività TCP/IP.
Repadmin | Individua i problemi di replica tra i controller di dominio Windows.
RPCDump | In genere utilizzato insieme a Network Monitor.
RPCPing | Utilizzato per confermare la connettività RPC.

Zubair Alexander, MCSE, MCT e Microsoft MVP, è proprietario di SeattlePro Enterprises, una società di consulenza e formazione IT. La sua esperienza si estende su tutto il settore: autore, assistente universitario, consulente, tecnico di rete, conferenziere, architetto della protezione, amministratore di sistemi, redattore tecnico e istruttore. È possibile contattarlo all'indirizzo alexander@techgalaxy.net.


 The Cable Guy: Traffico IPv6 su connessioni VPN
The Cable Guy
Traffico IPv6 su connessioni VPN
Joseph Davies

Quando si inizia a valutare il ruolo del protocollo IPv6 sulla Intranet e a pianificarne la distribuzione, è necessario comprendere in che modo il traffico IPv6 viene supportato sulle connessioni VPN (Virtual Private Network) in Windows. Grazie alle connessioni VPN, è possibile estendere la rete privata per comprendere collegamenti attraverso
reti pubbliche, ad esempio Internet. Le connessioni VPN sono protette mediante protocolli di autenticazione avanzata per convalidare le credenziali dell'utente che sta effettuando la connessione e metodi di crittografia per garantire la riservatezza dei dati.
In Windows® XP e Windows Server® 2003 è incluso uno stack del protocollo IPv6, che però non è supportato da molti servizi di base e componenti di rete. Windows Vista™ e Windows Server 2008, nome in codice precedente "Longhorn", dispongono invece di un supporto completo per IPv6, installato e attivato per impostazione predefinita e quasi tutti i servizi e le applicazioni di rete incluse al loro interno supportano tale protocollo. Questo mese, esaminerò il supporto fornito da Windows Vista, Windows Server 2008, Windows XP e Windows Server 2003 per il traffico IPv6 inviato su connessioni VPN stabilite attraverso reti Internet IPv4 e IPv6.

Connessioni VPN attraverso rete Internet IPv4
Per la maggior parte delle reti Intranet attuali, le connessioni VPN vengono create attraverso la rete Internet IPv4. Nella Figura 1 sono illustrati i componenti basati su Windows per le connessioni VPN di questo tipo. Essi sono:
Figura 1 Componenti basati su Windows per connessioni VPN attraverso rete Internet IPv4
Figura 1 Componenti basati su Windows per connessioni VPN attraverso rete Internet IPv4
Client VPN Il client VPN è un computer da cui viene avviata una connessione VPN di accesso remoto a un server VPN e che comunica con le risorse Intranet. Una connessione VPN di accesso remoto consente al client VPN di agire come se fosse connesso direttamente alla rete Intranet. Su un client VPN può essere eseguita la versione client o server di Windows.
Server VPN Questo computer ascolta i tentativi di connessione VPN remota, applica i requisiti di autenticazione e connessione e indirizza i pacchetti tra i client VPN e le risorse Intranet. Su un server VPN viene in genere eseguita una versione server di Windows con il servizio Routing e Accesso remoto.
Router VPN Un router VPN è un computer che avvia o ascolta i tentativi di connessione VPN da sito a sito. Una connessione VPN da sito a sito connette due porzioni di una rete Intranet. Su un router VPN viene eseguita una versione server di Windows e il servizio Routing e Accesso remoto.
Connessione VPN Una connessione VPN costituisce il collegamento logico tra il client VPN e il server VPN o tra i router VPN, come definito dall'incapsulamento di un protocollo VPN.
Intranet compatibile con IPv6 Questa Intranet è in grado di inoltrare il traffico IPv6 in modo nativo o con tunnel come pacchetti IPv4.
Host IPv6/IPv4 Questo nodo Intranet invia e riceve il traffico IPv6 in modo nativo o con tunnel come pacchetti IPv4.
I protocolli VPN che possono essere utilizzati da client, server e router VPN basati su Windows per incapsulare i pacchetti inviati attraverso la connessione VPN sono i seguenti: PPTP (Point-to-Point Tunneling Protocol), L2TP/IPsec (Layer Two Tunneling Protocol with Internet Protocol security) e SSTP (Secure Socket Tunneling Protocol). SSTP è supportato soltanto da Windows Vista con Service Pack 1 (SP1 in fase di beta testing) e Windows Server 2008.
Per le connessioni VPN attraverso rete Internet IPv4, sono disponibili due metodi per l'invio del traffico IPv6: pacchetti IPv6 con tunnel come pacchetti IPv4, di seguito definito traffico IPv6 su IPv4 e traffico IPv6 nativo.
In questo articolo, il supporto del traffico IPv6 attraverso connessioni VPN viene indicato in termini di protocolli VPN e versioni di Windows. Per le connessioni VPN di accesso remoto, una determinata combinazione di protocollo VPN e versione di Windows significa il supporto da parte di entrambi i componenti client e server di accesso remoto.

Traffico IPv6 su IPv4
Mediante questo metodo, un client di accesso remoto o un host IPv6/IPv4 della rete Intranet incapsula i pacchetti IPv6 con un'intestazione IPv4 e ne invia il risultato come pacchetto IPv4. Per le reti Intranet, la tecnologia di transizione a IPv6 ISATAP (IntraSite Automatic Tunnel Addressing Protocol) consente ai nodi IPv6/IPv4 di scambiare il traffico IPv6 attraverso una rete Intranet solo IPv4. Con ISATAP, è possibile attivare la connettività IPv6 sulla rete Intranet solo IPv4 senza dover necessariamente configurare o aggiornare i router esistenti per supportare l'indirizzamento e l'inoltro IPv6 nativo. Per ulteriori informazioni su ISATAP, vedere l'articolo "Tecnologie di transizione IPv6" all'indirizzo microsoft.com/technet/network/ipv6/ipv6coexist.mspx.
Nella Figura 2 è illustrata la struttura generale dei pacchetti per il traffico VPN quando viene inviato un pacchetto IPv4 utilizzando una connessione VPN attraverso la rete Internet IPv4. Il pacchetto IPv4 viene incapsulato dal protocollo VPN con un'intestazione e, a seconda del protocollo VPN, un trailer. Il risultato viene quindi incapsulato con un'intestazione IPv4 che consente l'inoltro attraverso la rete Internet IPv4.
Figura 2 Pacchetti IPv4 per una connessione VPN attraverso la rete Internet IPv4
Figura 2 Pacchetti IPv4 per una connessione VPN attraverso la rete Internet IPv4
Per il traffico IPv6 su IPv4, il payload del pacchetto IPv4 inviato attraverso la connessione VPN è costituito da un pacchetto IPv6. Nella Figura 3 è illustrata la struttura generale dei pacchetti per il traffico VPN quando viene inviato un pacchetto IPv6 su IPv4 utilizzando una connessione VPN attraverso la rete Internet IPv4.
Figura 3 Pacchetti IPv6 su IPv4 per una connessione VPN attraverso la rete Internet IPv4
Figura 3 Pacchetti IPv6 su IPv4 per una connessione VPN attraverso la rete Internet IPv4
Per le connessioni VPN di accesso remoto, il traffico IPv6 su IPv4 attraverso la rete Internet IPv4 è supportato dai protocolli PPTP e L2TP/IPsec in Windows Vista, Windows Server 2008, Windows XP SP1 o versione successiva e Windows Server 2003 e dal protocollo SSTP in Windows Vista SP1 e Windows Server 2008. Per le connessioni VPN da sito a sito, il traffico IPv6 su IPv4 attraverso la rete Internet IPv4 è supportato dai protocolli PPTP e L2TP/IPsec in Windows Server 2008 e Windows Server 2003.

Traffico IPv6 nativo
Per il traffico IPv6 nativo, il client, il server o il router VPN invia i pacchetti IPv6 attraverso la connessione VPN senza l'incapsulamento IPv4 iniziale. Questo avviene sulle reti Intranet che dispongono di connettività IPv6 nativa ed è necessario che i client, i server e i router VPN supportino il protocollo IPv6CP (IPv6 Control Protocol), RFC 2472, che definisce il modo in cui i nodi IPv6 negoziano le opzioni di configurazione IPv6 per le connessioni basate su PPP (Point-to-point Protocol). Windows Vista e Windows Server 2008 supportano il protocollo IPV6CP, ma non altrettanto Windows XP e Windows Server 2003. Nella Figura 4 è illustrata la struttura generale dei pacchetti per il traffico VPN quando viene inviato un pacchetto IPv6 nativo utilizzando una connessione VPN attraverso la rete Internet IPv4.
Figura 4 Pacchetti IPv6 nativi per una connessione VPN attraverso la rete Internet IPv4
Figura 4 Pacchetti IPv6 nativi per una connessione VPN attraverso la rete Internet IPv4
Per le connessioni VPN di accesso remoto, il traffico IPv6 nativo attraverso la rete Internet IPv4 è supportato dai protocolli PPTP e L2TP/IPsec in Windows Vista e Windows Server 2008 e dal protocollo SSTP in Windows Vista SP1 e Windows Server 2008. Per le connessioni VPN da sito a sito, il traffico IPv6 nativo che viaggia attraverso la rete Internet IPv4 è supportato dai protocolli PPTP e L2TP/IPsec in Windows Server 2008.

Connessioni VPN attraverso rete Internet IPv6
Le connessioni VPN possono avvenire anche attraverso la rete Internet IPv6. Tali connessioni sono attualmente poco frequenti, ma si diffonderanno con l'aumento dell'offerta di servizi IPv6 da parte dei provider di servizi Internet ai loro clienti e man mano che le organizzazioni includeranno questo tipo di connettività nelle reti perimetrali alla rete Intranet.
Per supportare le connessioni VPN attraverso rete Internet Pv6, i protocolli VPN utilizzati devono supportare le connessioni su IPv6. In Windows Vista e Windows Server 2008, i protocolli VPN L2TP/IPsec e SSTP supportano le connessioni VPN di accesso remoto su IPv6. In Windows Server 2008, il protocollo L2TP/IPsec supporta le connessioni da sito a sito su IPv6. Le connessioni VPN attraverso rete Internet IPv6 utilizzano lo stesso insieme di componenti utilizzato per le connessioni VPN sia di accesso remoto sia da sito a sito attraverso la rete Internet IPv4.
Esistono inoltre due metodi per l'invio di pacchetti IPv6 sulla rete Internet IPv6: come traffico IPv6 su Pv4 e come traffico IPv6 nativo. Nella Figura 5 è illustrata la struttura generale dei pacchetti IPv6 su IPv4 quando vengono inviati su una connessione VPN attraverso la rete Internet IPv6.
Figura 5 Pacchetti IPv6 su IPv4 per una connessione VPN attraverso la rete Internet IPv6
Figura 5 Pacchetti IPv6 su IPv4 per una connessione VPN attraverso la rete Internet IPv6
Per le connessioni VPN di accesso remoto, il traffico IPv6 su IPv4 attraverso la rete Internet IPv6 è supportato dal protocollo L2TP/IPsec in Windows Vista e Windows Server 2008 e dal protocollo SSTP in Windows Vista SP1 e Windows Server 2008. Per le connessioni VPN da sito a sito, il traffico IPv6 su IPv4 attraverso la rete Internet IPv6 è supportato dal protocollo L2TP/IPsec in Windows Server 2008. Analogamente al traffico IPv6 su IPv4 sulla rete Internet IPv4, per il traffico IPv6 su IPv4 sulla rete Internet IPv6 è necessaria la distribuzione di una tecnologia di transizione a IPv6 come ISATAP sulla rete Intranet.
Nella Figura 6 è illustrata la struttura generale dei pacchetti IPv6 nativi quando vengono inviati su una connessione VPN attraverso la rete Internet IPv6. Analogamente al traffico IPv6 nativo sulla rete Internet IPv4, per il traffico IPv6 nativo sulla rete Internet IPv6 sono necessari il supporto del protocollo IPV6CP e la distribuzione della connettività IPv6 nativa sulla rete Intranet.
Figura 6 Pacchetti IPv6 nativi per una connessione VPN attraverso la rete Internet IPv6
Figura 6 Pacchetti IPv6 nativi per una connessione VPN attraverso la rete Internet IPv6
Per le connessioni VPN di accesso remoto, il traffico IPv6 nativo attraverso la rete Internet IPv6 è supportato dai protocolli L2TP/IPsec e L2TP/IPsec in Windows Vista e Windows Server 2008 e dal protocollo SSTP in Windows Vista SP1 e Windows Server 2008. Per le connessioni VPN da sito a sito, il traffico IPv6 nativo attraverso la rete Internet IPv6 è supportato dal protocollo L2TP/IPsec in Windows Server 2008.

Conclusioni
Nella Figura 7 sono illustrati i quattro metodi per l'invio del traffico IPv6 su connessioni VPN e il supporto fornito in Windows per i due diversi tipi di connessioni di VPN. In poche parole, se si utilizza una tecnologia di transizione a IPv6 come ISATAP sulla rete Intranet, è possibile inviare traffico IPv6 su IPv4 su connessioni VPN attraverso reti Internet IPv4 e IPv6. Se la rete Intranet supporta la connettività IPv6 nativa, è possibile inviare traffico IPv6 nativo su connessioni VPN attraverso le reti Internet sia IPv4 sia IPv6 con Windows Vista e Windows Server 2008.
Figure 7 Supporto del traffico IPv6 su connessioni VPN in Windows (Close Figure 7)

Metodo di invio del traffico IPv6 | Connessioni VPN di accesso remoto | Connessioni VPN da sito a sito
Traffico IPv6 su IPv4 sulla rete Internet IPv4 | PPTP e L2TP/IPsec in Windows Vista, Windows Server 2008, Windows XP SP1 o versione successiva e Windows Server 2003 SSTP in Windows Vista SP1 e Windows Server 2008 | PPTP e L2TP/IPsec in Windows Server 2008 e Windows Server 2003
Traffico IPv6 nativo sulla rete Internet IPv4 | PPTP e L2TP/IPsec in Windows Vista e Windows Server 2008 SSTP in Windows Vista SP1 e Windows Server 2008 | PPTP e L2TP/IPsec in Windows Server 2008
Traffico IPv6 su IPv4 sulla rete Internet IPv6 | L2TP/IPsec in Windows Vista e Windows Server 2008 SSTP in Windows Vista SP1 e Windows Server 2008 | L2TP/IPsec in Windows Server 2008
Traffico IPv6 nativo sulla rete Internet IPv6 | L2TP/IPsec in Windows Vista e Windows Server 2008 SSTP in Windows Vista SP1 e Windows Server 2008 | L2TP/IPsec in Windows Server 2008

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


 Windows PowerShell: Riflessioni sulla pipeline
Windows PowerShell
Riflessioni sulla pipeline
Don Jones

Molto è stato detto a proposito del perché Windows PowerShell sia diverso, nuovo e interessante, malgrado sia basato su concetti di interfaccia della riga di comando in circolazione da decenni, principalmente sui sistemi operativi basati su UNIX e Linux. Tuttavia, la terminologia comune che Windows PowerShell condivide con i suoi predecessori può portare
a trascurare le reali caratteristiche di flessibilità ed esclusività di Windows PowerShell nonché la notevole idoneità per un ambiente Windows®.
Una delle funzionalità più discusse di Windows PowerShell è la pipeline, che però, sfortunatamente, è anche una di quelle meno capite. Ciò è dovuto all'uso di una terminologia definita nel corso dei primi anni '70 per rappresentare funzionalità completamente diverse e meno efficaci.

Origine delle pipe
Una delle prime shell UNIX mai create è stata la shell Thompson, che era molto primitiva e presentava solo i più elementari elementi del linguaggio di script senza variabili. L'impostazione della shell era volutamente modesta in quanto l'unica funzione che doveva svolgere era quella di eseguire programmi. Tuttavia, essa ha introdotto un concetto chiave che ha contribuito a migliorare le altre shell di quel tempo: le pipe. Grazie all'utilizzo dei simboli < e >, era possibile indicare alla shell di reindirizzare l'input e l'output da e verso diversi comandi. Un utente era così in grado, ad esempio, di reindirizzare l'output di un comando su un file.
Questa sintassi è stata successivamente ampliata in modo che l'output di un comando potesse anche essere reindirizzato all'input di un altro comando, consentendo di concatenare lunghe sequenze di comandi per svolgere operazioni più complicate. Con la versione 4 della shell, il carattere di linea verticale "|" è stato adottato per il piping diventando così noto come il carattere pipe. Perfino le prima versioni di MS-DOS® hanno implementato il piping di base per mezzo di questi caratteri, consentendo, ad esempio, di reindirizzare l'output del comando Type nell'input del comando More per visualizzare lunghi file di testo una pagina alla volta.
Anche se quando venne rilasciata la versione 6 di UNIX nel 1975, la shell di Thompson era ampiamente considerata come inadeguata, il concetto di pipe si radicò a fondo tra gli sviluppatori di shell e gli utenti e venne portato avanti in varie tecnologie tuttora in uso.

Piping del testo
Una limitazione di quasi tutte le shell è la natura intrinsecamente basata sul testo. Nei sistemi operativi basati su UNIX questa di fatto non è una limitazione, ma rispecchia piuttosto il tipo di funzionamento del sistema operativo stesso. Quasi tutte le risorse in UNIX possono essere rappresentate come un file di qualche tipo, il che significa che la possibilità di reindirizzare il testo da un comando a un altro offre un notevole grado di potenza e flessibilità.
Tuttavia, il testo costituisce una limitazione nel momento in cui è necessario passare alle informazioni di gestione. Ad esempio, se dovessi presentare un elenco dei servizi in esecuzione su un computer Windows, la cosa diventerebbe certamente più chiara. Probabilmente, inserirei il nome del servizio nella prima colonna e la relativa modalità di avvio nella seconda. L'efficace cervello umano analizzerebbe o convertirebbe in modo trasparente e immediato il testo visualizzato in informazioni significative con cui sarebbe possibile lavorare. I computer, però, non sono così intelligenti: per fare in modo che un computer svolga un'operazione utile con un tale elenco, sarebbe necessario indicargli che la prima colonna è composta di caratteri da 1 a 20, mentre i caratteri da 22 fino a 40 denotano la seconda e così via.
Per lungo tempo, questo tipo di analisi dei file di testo ha rappresentato l'unico modo per gli amministratori di concatenare insieme più comandi. Infatti, i linguaggi di script quali VBScript e Perl si distinguono nella manipolazione delle stringhe principalmente perché devono essere in grado di accettare output di testo da un programma o da un comando per poi analizzarlo e tradurlo in dati utili per svolgere attività successive. Ad esempio, mi è capitato di scrivere processi VBScript che accettavano l'output di testo del comando Dir, lo analizzavano per individuare nomi di file e date, quindi spostavano i file inutilizzati in una posizione di archivio. L'analisi delle stringhe è estremamente difficile a causa delle eccezioni, variazioni nell'input dei dati, che si verificano quasi sempre, imponendo di rivedere la logica nello script per gestire tutte le combinazioni possibili.
Come forma di script amministrativo o di automazione in un ambiente Windows, l'analisi delle stringhe si rivela meno utile. La ragione è che Windows stesso non memorizza molte informazioni in un formato di testo di facile accesso. Vengono invece utilizzati archivi centrati sui dati, quali Active Directory®, il Registro di sistema di Windows e l'archivio certificati, in modo che i creatori di script debbano utilizzare dapprima uno strumento per creare un qualsiasi tipo di output del testo e in seguito uno script per analizzare questo testo da utilizzare successivamente.

Gli oggetti sono più semplici
Le cose per gli sviluppatori di software Windows sono sempre state un po' più semplici. Inizialmente, Microsoft ha sviluppato COM appositamente per rappresentare i complessi funzionamenti interni di Windows in un una modalità più facile da utilizzare. Attualmente, Microsoft® .NET Framework svolge lo stesso compito: rappresenta il funzionamento interno del software in una modalità standardizzata.
Genericamente, entrambi COM e .NET espongono gli elementi sotto forma di oggetti. Uno sviluppatore di software potrebbe obiettare a questa semplificazione, ma ai fini della nostra discussione, un semplice termine è sufficiente. Tutti questi oggetti prevedono membri di diverso tipo. Per i nostri scopi, le proprietà e i metodi degli oggetti costituiscono l'aspetto più interessante. Una proprietà descrive sostanzialmente un oggetto oppure modifica l'oggetto o il relativo comportamento. Ad esempio, un oggetto servizio può avere una proprietà che contiene il nome del servizio e un'altra proprietà che contiene la modalità di avvio del servizio. I metodi indicano a un oggetto di fare qualcosa. Un oggetto servizio potrebbe comprendere metodi chiamati Stop, Start, Pause e Resume, ad esempio, per rappresentare le diverse operazioni che può svolgere.
Da un punto di vista della programmazione o degli script, il riferimento ai membri di un oggetto avviene per mezzo di una notazione puntata. Gli oggetti vengono spesso assegnati a variabili, fornendo un metodo per manipolare fisicamente l'oggetto. Ad esempio, se alla variabile $service è assegnato un servizio, è possibile interrompere tale servizio mediante la sintassi $service.Stop. Allo stesso modo è possibile recuperare il nome visualizzato del servizio visualizzando $service.Name.

Oggetti nella pipe
Poiché Windows è un sistema operativo grande e complesso e poiché non memorizza i propri dati di gestione nelle rappresentazioni in stile testo, le precedenti tecniche della shell non sono assolutamente adeguate. Ad esempio, supponiamo di avere uno strumento della riga di comando di nome SvcList.exe che produce un elenco formattato di servizi e delle relative modalità di avvio. Nella shell della riga di comando di Windows, che tiene saldamente le proprie radici nella più che decennale shell del DOS, posso fare qualcosa di simile a quanto riportato di seguito:
SvcList.exe | MyScript.vbs
Questa istruzione recupera un elenco di servizi e lo reindirizza su un file VBScript. A questo punto si potrebbe scrivere un file VBScript per analizzare l'elenco formattato e svolgere l'operazione desiderata, magari estrarre tutti i servizi con la modalità di avvio Disattivato. Quest'attività richiederebbe molto tempo. Fondamentalmente, il problema è che l'output di SvcList.exe è specifico in quanto non condivide un formato comune che può essere facilmente sfruttato da altri comandi.
Gli oggetti, tuttavia, sono in grado di fornire questo formato comune e questa è la ragione per cui la pipeline di Windows PowerShell funziona con interi oggetti, non solo con il testo. Quando si esegue un cmdlet del tipo Get-WMIObject, si produce un gruppo o insieme, alla maniera dei programmatori, di oggetti. Ciascun oggetto è dotato di proprietà e metodi che ne consentono la manipolazione. Se gli oggetti vengono reindirizzati verso il cmdlet Where-Object, è possibile filtrarli in modo da visualizzare solo quelli desiderati. Where-Object non deve analizzare alcun testo perché in realtà riceve oggetti. Ad esempio:
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
Oppure, se si preferisce la sintassi più breve disponibile tramite alias:
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
L'aspetto interessante è che Windows PowerShell passa sempre gli oggetti alla pipeline. È solo alla fine della pipeline, dove non c'è altro a cui passare gli oggetti, che la shell genera una rappresentazione di testo degli oggetti utilizzando le relative regole di formattazione incorporate. Si prenda, ad esempio, in considerazione quanto segue:
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
Questa serie di tre cmdlet recupera tutti i servizi dal computer locale, filtra tutti quelli che non utilizzano l'account LocalSystem per accedere, quindi passa il resto al cmdlet Select-Object che invia in output solo le due proprietà, Name e StartMode, che ho chiesto di selezionare. Il risultato è un semplice report di servizi che accedono in qualità di LocalSystem, magari a fini del controllo della protezione.
Poiché tutti i cmdlet condividono un formato dati comune, gli oggetti, sono in grado di condividere reciprocamente dati senza alcuna complicata analisi di stringhe. Inoltre, poiché Windows PowerShell è in grado di creare una rappresentazione testuale di un oggetto, la fine di questa pipe è certamente un output di testo leggibile. Nella Figura 1 è illustrato un esempio dell'output prodotto.
Figura 1 Output di testo prodotto da una serie di cmdlet reindirizzati passati con gli oggetti
Figura 1 Output di testo prodotto da una serie di cmdlet reindirizzati passati con gli oggetti

L'entusiasmo suscitato dalle pipe
La ragione dell'efficacia del piping in Windows PowerShell è che tutto al suo interno è un oggetto, completo di proprietà e metodi che è possibile utilizzare. Anche un file di testo è tecnicamente un insieme di oggetti stringa, in cui ciascuna riga funge da oggetto stringa univoco e indipendente. Creare, ad esempio, con Blocco Note un file di testo di nome C:\Computers.txt. Riempire il file con testo, quindi procedere come segue in Windows PowerShell:
Get-Content C:\Computers.txt | Select-Object Length | Format-List
Oppure, anche qui, se si preferisce digitare di meno, è possibile utilizzare gli alias:
gc C:\Computers.txt | select Length | fl
Questo codice fornisce un elenco che indica la lunghezza di ogni riga del file di testo, in caratteri. Get-Content recupera gli oggetti stringa dal file, Select-Object estrae proprietà Lenght di ciascuno, quindi Format-List crea il gradevole output di testo leggibile. Anche se non è uno strumento amministrativo di grande utilità pratica, illustra con semplicità che in Windows PowerShell anche una riga di testo è un oggetto.
La possibilità di reindirizzare oggetti da cmdlet a cmdlet, o anche da cmdlet a script, consente di creare "comandi di una riga" estremamente potenti. Queste sono stringhe di esempio di cmdlet uniti in una lunga pipeline che rifiniscono ulteriormente un set di oggetti per fornire esattamente il risultato desiderato. Senza praticamente alcun lavoro di script o programmazione, i cmdlet di Windows PowerShell raccordati in una pipeline appropriata sono in grado di ottenere notevoli risultati.

Supporto delle generazioni future
Il fatto che anche i futuri prodotti server di Microsoft saranno basati su Windows PowerShell estende questa funzionalità. Ad esempio, nell'implementazione di un nuovo computer Exchange Server 2007 è possibile utilizzare Windows PowerShell per recuperare tutte le cassette postali, filtrare quelle che non si trovano nell'ufficio in cui è situato il nuovo server di posta e spostarle su un nuovo server, con una sola riga di testo senza l'ausilio di script. Il team di Exchange Server 2007 ha pubblicato un lungo elenco di efficaci comandi di una riga. Questi dimostrano realmente la potenza della pipeline e delle attività amministrative che consente di svolgere.
Il trucco con Windows PowerShell è di comprendere che, pur essendo basato su concetti e filosofie di lunga data provenienti dal mondo UNIX, questo nuovo strumento è adatto in modo particolare all'amministrazione di Windows. Non si deve quindi lasciare che una semplice analogia terminologica induca a pensare che Windows PowerShell sia una semplice imitazione della shell UNIX per Windows. Windows PowerShell contiene alcuni concetti nuovi che sfruttano i vantaggi della piattaforma Windows ed è strettamente collegato al modo di operare di Windows.

Don Jones è un Windows PowerShell MVP e autore di Windows PowerShell 101 (ScriptingTraining.com). È possibile contattare Don all'indirizzo www.ScriptingAnswers.com.


 Hey, Scripting Guy!: Negli script, come nella vita, l'aspetto &#232; importante
Hey, Scripting Guy!
Negli script, come nella vita, l'aspetto è importante
Gli Scripting Guy di Microsoft

Per centinaia, anche migliaia, di anni, filosofi e saggi ci hanno insegnato che per giudicare qualcuno o qualcosa è necessario andare oltre l'aspetto fisico. Attenzione, questo non significa che si debbano giudicare le persone, in fin dei conti la bellezza è un concetto estremamente soggettivo. Essi affermano: La vera bellezza proviene da dentro, non da fuori, e ciò che siamo è molto più importante di come appariamo.
A tutto questo, gli Scripting Guy possono aggiungere solo una cosa: stupidaggini.
Esatto, stupidaggini. Gli Scripting Guy sono i primi ad ammettere che in un mondo perfetto l'aspetto fisico non fa la differenza. D'altra parte, non viviamo in un mondo perfetto. Se lo fosse, patatine fritte e coppe di gelato alla panna sarebbero due dei nostri alimenti principali. Che piaccia o no, anche l'aspetto è importante. Questo vale per gli script come per qualsiasi altra cosa.
Gli Scripting Guy sono consapevoli che sono poche le persone che si commuovono di fronte alla meraviglia assoluta di uno script VBScript eseguito in una finestra di comando. Uno di questi può essere lo Scripting Guy Dean Tsaltas, ma è l'unico che ci viene in mente.
D'altra parte, è anche vero che in questo in mondo high-tech, gli autori di script non si limitano più a scrivere script che vengono eseguiti in una finestra di comando. Grazie alle applicazioni HTML (HTA, HTML Application), gli autori di script possono avvalersi della potenza di DHTML per creare le GUI per i propri script. Queste stesse tecniche HTML possono essere utilizzate per creare gadget di Windows Vista™, un nuovo aspetto capace di rivoluzionare l'utilizzo degli script di amministrazione di sistema che abbiamo conosciuto finora. Ma sai una cosa? Non appena si inizia a parlare di GUI, tutte le vecchie nozioni sulla bellezza esteriore svaniscono. Per gli script eseguiti in un ambiente grafico, l'aspetto è importante tanto quanto il funzionamento e le prestazioni.
E questo è un problema. Dopotutto, siamo creatori di script: che ne sappiamo della creazione di interfacce utente grafiche? Pare che non abbiamo molta fortuna, vero?
Forse. Ma può anche essere vero il contrario. Qualcuno ha detto, "Per fortuna che ci sono gli Scripting Guy"?
No davvero. Qualcuno l'ha detto? Può essere che qualcuno abbia borbottato qualcosa del genere...
Va bene, non importa. Qualcuno avrebbe dovuto dirlo perché gli Scripting Guy sono qui per prestare il loro aiuto, che lo si voglia o meno.
Per introdurti al meraviglioso mondo delle GUI, diamo un'occhiata alla parte iniziale di una piccola e semplice HTA. Per ulteriori informazioni sulla creazione di HTA, consultare l'HTA Developers Center.
Nella Figura 1 è illustrata la prima parte di un immaginario sistema di informazioni per desktop. Come si può vedere, abbiamo iniziato inserendo un piccolo grafico nell'angolo superiore destro della finestra HTA. Il concetto è che quando l'HTA viene caricata la prima volta, recupera il nome dell'utente connesso e di conseguenza visualizza su questa immagine il relativo nome e quello del computer. Successivamente, all'HTA verranno aggiunte molte altre funzioni ma, come si suol dire, prima le cose essenziali.
Figura 1 L'inizio della nostra gradevole interfaccia grafica HTA
Figura 1 L'inizio della nostra gradevole interfaccia grafica HTA
No, di fatto non siamo sicuri di chi si tratta. Forse un altro di quei filosofi. Forse Voltaire. Questo sembra il tipo di cosa che direbbe Voltaire.
Ammettiamolo, questa è un'applicazione molto semplice e la sua...bellezza... non commuoverebbe lo Scripting Guy Dean. Tuttavia, svolge un'ottima funzione dimostrativa con un concetto di base applicabile a situazioni diverse. Dopotutto, il funzionamento di molti di quei pretenziosi gadget di Windows Vista si basa su un principio simile: visualizzano semplicemente un grafico colorato, ad esempio, un indicatore o un quadrante, sul quale scrivono poi del testo. Il risultato è che sembra di avere a disposizione un simpatico indicatore che visualizza lo spazio disponibile su disco, mentre in realtà si tratta semplicemente di un grafico generico sul quale viene sovrascritto qualche testo dinamico.
OK, per dir la verità tutto ciò non ha molto senso per noi. Tuttavia, procedendo con la trattazione di questo articolo le cose dovrebbero risultare più chiare.
Il concetto di visualizzare un grafico sul quale scrivere poi del testo pone un solo problema: non funziona. Invece, tramite i tag HTML di base è possibile ottenere qualcosa di simile a quanto è illustrato nella Figura 2. Non è esattamente quello che avevamo in mente. Forse Nietzsche, il quale disse che "l'uomo non può assolutamente sperare di sovrapporre del testo su un grafico, perlomeno non in una HTA", aveva ragione.
Figura 2 Un primo tentativo di sovrapporre del testo
Figura 2 Un primo tentativo di sovrapporre del testo
Oppure, può essere che Nietzsche avesse torto: abbiamo sentito qualcuno dire "Bene, non importa". In realtà, non è possibile ottenere ciò che desideriamo con l'ausilio del normale linguaggio HTML: non funziona in questo modo. Certo, in teoria potremmo impostare il nostro grafico in background e utilizzare tabelle e spazi unificatori e tutti gli altri tipi piccoli trucchi a disposizione per sovrapporre il testo all'immagine. Ma diciamo "in teoria" per una buona ragione; fatta eccezione per i casi più semplici, questa strategia non funziona mai.
Di fatto, esiste un metodo decisamente migliore per creare fantasiosi layout in una HTA o in un gadget di Windows Vista: I fogli di stile CSS, conosciuti anche come CSS.
CSS viene utilizzato per definire i caratteri, i margini e gli allineamenti, i colori e altri aspetti della presentazione di un documento. Ciò vale in particolare per le pagine Web. Tuttavia, poiché le HTA e i gadget non sono fondamentalmente altro che pagine Web, i fogli di stile CSS sono perfettamente applicabili anche in questo caso. È praticamente impossibile avviare una discussione su tutto quello che è possibile fare con i fogli di stile CSS, quindi per ulteriori informazioni si rimanda alla pratica e approfondita documentazione di riferimento CSS disponibile in MSDN®. Per ora, basti dire che è possibile utilizzare CSS per controllare in dettaglio il layout dell'HTA, compresa la possibilità di sovrapporre un elemento, ovvero il nostro testo, sopra un altro (il nostro grafico).
Spiegheremo come ottenere questo risultato, ma prima di procedere, diamo uno sguardo al codice di una HTA molto semplice mostrata nella Figura 3.
Figure 3 Per concludere, ecco lo script... (Close Figure 3)
<SCRIPT LANGUAGE=”VBScript”>

Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub

</SCRIPT>

<img src=“test2.jpg“ align=“right“>
<span id=UserData style=“position:absolute;left:770px;top:150px“></span>
Come si può vedere, non c'è molto. Abbiamo una subroutine Window_OnLoad che, come lascia intuire il nome, viene eseguita automaticamente ogni volta che l'HTA viene caricata o aggiornata. La subroutine verrà esaminata tra breve. Inoltre, sono presenti due elementi HTML: il nostro grafico e una sezione span. Come è certamente noto, utilizziamo questa porzione di tag per inserire il grafico, con l'attributo di allineamento per garantire che l'immagine venga visualizzata sul lato destro della finestra:
<img src=”test2.jpg” align=”right”>
Questo ci porta ai tag HTML della sezione span:
<span id=UserData style=”position:absolute;
left:770px;top:150px”></span>
Sì, qui è stato utilizzato un tag span. Ma che cosa è un tag span? A tutti gli effetti, una sezione span è semplicemente un'area denominata dell'HTA; è una sezione "delimitata" della finestra HTA che è possibile identificare a livello di programmazione, principalmente perché le è stato assegnato l'ID UserData. Dopo avere impostato una sezione span, è possibile scrivere una subroutine che le assegna il testo o il codice HTML. In effetti, questo è ciò che abbiamo fatto nella nostra HTA.
Ma, come abbiamo anticipato, parleremo di questo più avanti. Prima è necessario considerare il parametro di stile aggiunto al tag span:
style=”position:absolute;left:770px;top:150px”
questo parametro, come si può intuire, è la chiave per posizionare correttamente il testo dinamico sul grafico. Qui vengono specificati tre attributi di stile separati.
Position All'HTA è stato indicato di posizionare la sezione span in modo assoluto. Ciò significa sostanzialmente che la sezione span deve rimanere sempre nella stessa posizione, anche se ciò significa che, come accade in questo caso, il testo viene scritto sopra un altro elemento, ad esempio, un grafico.
Left Questo specifica semplicemente la posizione della sezione span relativa al bordo sinistro della finestra HTA. In questo caso, la sezione span deve iniziare a 770 pixel (770px) da sinistra.
Top Questa impostazione è simile all'attributo Left, tranne che questa volta viene specificata la posizione della sezione span relativa al bordo superiore della finestra HTA. In questo caso, la sezione span inizia a 150 pixel (150px) dal bordo superiore della finestra.
Come facevamo a sapere che desideravamo impostare il lato sinistro della sezione span a 770 pixel e quello superiore a 150 pixel? Per essere sinceri, non lo sapevamo e abbiamo tirato a indovinare; dopo avere inserito il grafico sulla pagina abbiamo assegnato dei valori agli attributi Left e Top della sezione span. Quindi abbiamo aperto l'HTA e osservato il risultato. Come si può intuire, la posizione era leggermente fuori posto, così abbiamo regolato i valori, aggiornato l'HTA e verificato nuovamente. L'operazione è stata ripetuta alcune volte finché, come Riccioli d'Oro, abbiamo trovato qualcosa che andava bene.
Nota: conosci la storia di Riccioli d'Oro e i tre orsi, i loro letti e le sedie, il porridge che era troppo caldo o troppo a freddo, e così via. E no, non sappiamo se Riccioli d'Oro può essere considerata un grande filosofo o meno. Si può comunque affermare che, visto il modo in cui ella non ha avuto alcun problema a irrompere in casa d'altri, mangiare il loro porridge, sedere sulle loro sedie e dormire nei loro letti, aveva certamente una propria filosofia.
In ogni modo, nella Figura 4 è illustrata la nostra HTA. Concesso, può non sembrare un'opera d'arte, ma d'altra parte, ci piacerebbe vedere in che modo Picasso riuscirebbe a programmare la stampa di informazioni su un grafico.
Figura 4 La potenza dello stile
Figura 4 La potenza dello stile
Parliamo del modo in cui abbiamo stampato delle informazioni su un grafico a livello di programmazione? Bene, abbiamo buone notizie: è giunto il momento di parlare della subroutine Window_OnLoad, illustrata nella Figura 5.
Figure 5 Subroutine Window_OnLoad (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” & _
  strUser & “<br>” & strComputer & “</font></p>”
End Sub
Guardandola un po' più da vicino, si può notare che non c'è molto da dire. La subroutine inizia creando un'istanza dell'oggetto Wscript.Network. Quindi vengono utilizzate queste righe di codice per recuperare il nome utente, il dominio e il nome del computer:
strUser = objNetwork.UserDomain & “\” & _
  objNetwork.UserName
strComputer= objNetwork.ComputerName
Queste, ovviamente, sono le informazioni che devono essere scritte nella finestra HTA. È sufficiente combinare la variabile strUser e strComputer con alcuni tag HTML, quindi assegnare la stringa risultante alla proprietà InnerHTML della sezione:
UserData.InnerHTML = _
  “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” _
  & strUser & “<br>” & strComputer & _
  “</font></p>”
Sì, riconosciamo che è una porzione di codice leggermente complicata. Ma non è poi così male. Sembra complicata semplicemente perché vengono combinati alcuni elementi in un'unica stringa. Si inizia con un tag di paragrafo aperto, nel quale viene specificato che il testo deve essere centrato.
“<p align = ‘center’> “
Quindi, troviamo un tag di apertura font, nel quale viene specificato l'utilizzo di testo di colore bianco della dimensione di 18 punti:
“<font style=’font-size:18pt;color:white’>”
strUser è la variabile che contiene il nome utente, nel formato Dominio\NomeUtente. "<br>" inserisce un'interruzione di riga. Ciò consente di visualizzare il nome utente su una riga separata e il nome del computer su una seconda riga. strComputer è la variabile che contiene il nome del computer. Infine, vengono aggiunti i tag di chiusura del carattere e del paragrafo:
“</font></p>”
Esaminando le varie porzioni singolarmente, si può notare che il codice non è poi così complicato come si poteva supporre.
A proposito, è possibile posizionare praticamente qualsiasi elemento HTML finalizzato al posizionamento. Ad esempio, supponiamo di voler centrare un pulsante sotto il grafico. A tal scopo, è sufficiente aggiungere il codice seguente all'HTA:
<input type=”button” value=”Test Button” style=”position:absolute;left:820px;top:300px”>
L'HTA dovrebbe risultare come nella Figura 6.
Figura 6 Un bel pulsante
Figura 6 Un bel pulsante
Nuovamente, il posizionamento corretto del pulsante richiederà qualche tentativo, senza però richiedere troppo tempo. Infatti, con un po' di buona volontà matematica, è probabilmente possibile determinare in anticipo la posizione corretta. Tutto ciò che è necessario conoscere è la larghezza e l'altezza di ciascun oggetto, qualcosa che si può specificare tramite il parametro di stile, e la larghezza e l'altezza della finestra HTA. Per impostazione predefinita, almeno nel computer di prova degli Scripting Guy, le HTA hanno dimensioni di sono circa 1020 pixel di larghezza e 685 pixel di altezza (ovviamente, i risultati possono variare). Se non c'è altro, è possibile partire con i valori indicati e regolarli in base alle esigenze.
Questa è ovviamente un'introduzione ai fogli di stile CSS un po' troppo breve, ma costituisce un'indicazione sufficiente per iniziare a creare script dall'aspetto piacevole. I filosofi possono deridere questi sforzi e affermare che la vera bellezza di uno script si trova all'interno, non all'esterno. Ma guardiamo le cose in questo modo. Chi sono i più grandi filosofi di tutti i tempi? Esatto: Platone, Socrate, Aristotele, per citarne alcuni. Partendo da questa affermazione, vorremmo porre una domanda: hai mai visto una fotografia di questi filosofi? Non è interessante che non esista alcuna fotografie di persone che affermano che la bellezza non conta? Non pare un po' curioso? Qualcosa su cui riflettere.

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


 Exchange Queue &amp; A: Ruoli Trasporto Edge e Hub, computer virtuali e altro ancora
Exchange Queue & A
Ruoli Trasporto Edge e Hub, computer virtuali e altro ancora
KC Lemson and Nino Bilic

Nel numero di maggio 2007 di Exchange Queue & A sono stati illustrati i problemi correlati all'archiviazione dei file .pst nelle condivisioni di rete. Il team addetto alla gestione delle prestazioni di Windows Server ha di recente avviato un blog in cui ha trattato
questo argomento esplorandone tutti i dettagli tecnici; è consigliabile pertanto accedere al collegamento. A questo punto, è possibile passare alle domande.

D È necessario distribuire il ruolo del server Edge se si intende distribuire Microsoft Exchange Server 2007?

R No, la distribuzione di Exchange Server 2007 non implica la necessità di distribuire il server Edge. È possibile utilizzare un singolo computer su cui eseguire contemporaneamente programmi antispam e antivirus e i ruoli del server di base (ad esempio Cassette postali, Accesso client e Trasporto Hub) che accettano i messaggi di posta elettronica per il proprio dominio.

D Quali sono le differenze tra i ruoli del server Trasporto Edge e Trasporto Hub? Quali sono gli svantaggi se non si distribuisce il server Edge?

R Lo scopo principale del ruolo Hub è instradare la posta all'interno dell'organizzazione e applicare i criteri aziendali a tali messaggi. Con il ruolo Hub, le regole di trasporto sono basate sugli oggetti di Active Directory®: utenti, liste di distribuzione e così via. Il ruolo Hub consente inoltre di aggiungere dichiarazioni di non responsabilità ai messaggi o ai messaggi del journal inviati a gruppi di utenti in quanto è probabile che si desideri basare tali regole sull'appartenenza ad Active Directory. Potrebbe essere necessario ad esempio inserire nel journal tutti i messaggi inviati a DLOfUsersOnLitigationHold o aggiungere dichiarazioni di non responsabilità alla posta in uscita inviata da DLOfMembersOfLegalTeam. Sebbene sia possibile eseguire agenti antispam sul server hub, tali agenti non sono attivati per impostazione predefinita e pertanto sarà necessario installarli manualmente eseguendo lo script install-antispamagents disponibile nella directory \scripts sul server.
Lo scopo principale del ruolo Edge è instradare la posta in arrivo e in uscita dall'organizzazione ed eseguire la pulizia di tali messaggi (antivirus, antispam, filtro contenuto o filtro allegati e così via). Quando si installa un server Edge, viene attivata la funzionalità antispam. Una delle funzionalità uniche del ruolo Edge è rappresentata dal fatto che non è necessario che tale ruolo venga aggiunto a un dominio Windows®; può essere eseguito in un'installazione di Windows Server® autonoma che non fa parte di un dominio Windows, ma può essere comunque gestito come parte dell'organizzazione di Exchange 2007 nella foresta aziendale.
Questo è particolarmente vantaggioso in una rete perimetrale nel caso in cui si desideri utilizzare il server in un gruppo di lavoro o si disponga di una foresta separata progettata esplicitamente per i computer inclusi nella rete perimetrale. Per praticità, i server Edge distribuiti in questa situazione possono eseguire la pulizia di tutti i messaggi e il routing della posta tra la rete aziendale e Internet, ma nello stesso tempo possono essere gestiti secondo modalità coerenti con le altre operazioni di amministrazione dei sistemi di Exchange 2007.
Su un server Edge, le regole di trasporto sono basate su indirizzi SMTP, non su oggetti Active Directory; è tuttavia possibile utilizzare naturalmente gli indirizzi SMTP delle liste di distribuzione o degli utenti in Active Directory. Nella maggior parte dei casi, le regole di trasporto del ruolo Edge sono basate su un sottoinsieme delle regole di trasporto del ruolo Hub, fatta eccezione per l'azione di quarantena, che è disponibile solo sui server Edge.
Alcune funzionalità dei server Edge sono inoltre esposte tramite agenti non disponibili sul server Trasporto Hub: rimozione di allegati e riscrittura di indirizzi. Per rimozione degli allegati si intende la capacità di eliminare in modo selettivo allegati potenzialmente pericolosi con estensioni come .exe e .com. L'agente di riscrittura degli indirizzi consente di riscrivere le intestazioni dei messaggi di posta elettronica in modo che, anche se il dominio e gli indirizzi del proxy SMTP predefiniti negli account utente sono ad esempio @contoso.com, i messaggi in uscita per Internet risultano provenienti da @northwindtraders.com. Inoltre, poiché i server Edge eseguono il routing solo in base al dominio o allo spazio degli indirizzi, se si condivide lo stesso spazio di indirizzi SMTP tra Exchange e un altro sistema di posta elettronica, sarà necessario eseguire il routing sul server Hub o eseguirlo insieme all'agente di riscrittura degli indirizzi sul server Edge.
Un'altra importante considerazione riguarda la capacità o meno di un server Exchange 2007 di accedere direttamente a Internet (indipendentemente dal ruolo del server, Hub o Edge). In altre parole, Exchange 2007 è in grado di ricevere in qualche modo le connessioni alla porta 25 nel record MX del dominio. È possibile che si disponga già di un gateway SMTP, un viruswall o altra soluzione su Internet che accetta la posta per il dominio e la trasmette a Exchange all'interno della rete aziendale. Se si distribuiscono server Hub o Edge con connessione a Internet, è possibile sfruttare i vantaggi di una delle più ingegnose funzionalità di Exchange 2007: aggregazione dell'elenco indirizzi attendibili. Con l'aggregazione dell'elenco indirizzi attendibili, gli utenti che aggiungono mittenti al relativo elenco indirizzi attendibili in Microsoft Outlook® (operazione che in genere eseguono per i notiziari Internet o la posta elettronica inviata dai rivenditori) saranno in grado di propagare in maniera protetta tali elenchi ai ruoli Hub o Edge in modo che i messaggi provenienti da questi mittenti ignorino il filtro contenuto. Ovviamente, i messaggi considerati spam da un utente possono essere notiziari importanti per un altro, per cui gli elenchi indirizzi attendibili vengono aggregati in base a ciascun utente. Per ulteriori informazioni sulla modalità di funzionamento di questa funzionalità, consultare la documentazione di Exchange 2007.
Se si decide di eseguire una distribuzione in cui un server in esecuzione con il ruolo Hub accetta la posta elettronica Internet per il dominio, è bene tenere presenti alcune considerazioni. Assicurarsi innanzitutto di implementare una buona soluzione di filtraggio firewall o porta in modo che il server in uso riceva solo connessioni sulle porte necessarie, ad esempio la porta 25. Tenere presente inoltre che è necessario installare gli agenti antispam in quanto non sono installati né attivati per impostazione predefinita. Poiché lo scenario di distribuzione più comune del server Hub viene eseguito all'interno della rete aziendale, non sono consentite connessioni anonime; è necessario controllare il gruppo di autorizzazione AnonymousUsers sul connettore di ricezione della porta 25. Accertarsi inoltre di abilitare l'aggregazione dell'elenco indirizzi attendibili e pianificarne l'esecuzione a intervalli periodici in modo che, quando gli utenti aggiornano gli elenchi indirizzi attendibili nelle relative cassette postali, i messaggi inviati a tali utenti dai relativi elenchi Mittenti attendibili ignorino il filtro contenuto. Ulteriori dettagli sono disponibili sul nostro blog.
Nel seguente codice viene illustrato un comando AT che aggiorna tutte le cassette postali ogni giorno alle ore 23:00 su tutti i server utilizzando un file batch denominato SafeList.bat:
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
Nel seguente codice viene mostrato il contenuto del file SafeList.bat:
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
Se occorre verificare il corretto funzionamento delle impostazioni, ulteriori informazioni sono disponibili nella documentazione di Exchange 2007.

D Dopo aver avviato l'immagine Virtual PC su cui risiede Exchange, si verificano problemi durante il tentativo di contattare la directory o il server LDAP. La connessione telnet al 389 non dà alcun problema e tutti i servizi funzionano in modo corretto. Perché?

R Anch'io ho avuto questo problema lo scorso anno in Tech•Ed. Avevo esportato una copia di Virtual PC da un computer in ufficio sul mio computer portatile con l'intenzione di utilizzarla per alcune dimostrazioni per i membri della stampa che stavano pubblicando articoli in coincidenza con l'avvio di Exchange 2007 Beta 2 il mese successivo.
Avevo eseguito un milione di demo del prodotto e, contando sull'affidabilità della build, avevo trascurato la fase di preparazione. Si può immaginare il sudore sulla mia fronte quando dopo avviato Virtual PC il lunedì mattina, poche ore prima del primo incontro, ho scoperto che il programma non era in grado di contattare un controller di dominio. Grazie all'alta concentrazione di persone tecnicamente qualificate, il problema fu identificato rapidamente.
Il problema verificatosi in Tech•Ed era il risultato dell'esecuzione di Virtual PC sul mio estremamente lento computer portatile. Il problema era il risultato di una race condition con DNS e Active Directory. Il server DNS sull'immagine era stato configurato per l'integrazione con Active Directory, ma a causa della sequenza i cui i servizi nell'immagine erano stati caricati (e alla mancanza di velocità del mio portatile), i servizi di directory necessari non si erano avviati quando il server DNS ha tentato di contattare Active Directory.
Questa situazione può verificarsi su qualsiasi server che abbia il controller di dominio ed Exchange sullo stesso computer (non deve essere un'immagine virtualizzata), ma può verificarsi con maggiore probabilità in un ambiente virtualizzato in cui vi sono rallentamenti aggiuntivi, in particolare con un portatile poco "muscoloso" come il mio.
Ho notato che un problema simile si verifica con immagini Virtual PC copiate tra due computer, in particolare quando uno dei due computer si trova in un rete differente. Se ci si è imbattuti in un problema di questo tipo, controllare l'indirizzo IP del sistema operativo nell'immagine; è possibile che disponga di un indirizzo IP non aggiornato della rete precedente. Aggiornarlo per ottenere un indirizzo IP dalla nuova rete e verificare se il problema si risolve.
Per evitare questi tipi di problemi in futuro, una possibile soluzione consiste nel configurare il server DNS sul sistema guest in modo che non supporti l'integrazione con Active Directory e nell'installare DNS sia sull'host che sul sistema guest. Configurare il sistema guest per l'inoltro all'host di record sconosciuti e, analogamente, configurare l'host per l'inoltro al server DNS appropriato di record sconosciuti. Quando l'immagine si avvia e tenta di aggiornare i record DNS, sarà meno soggetta a errori.

D Sembra che il processo di installazione di Exchange 2007 sia differente dall'installazione nelle versioni precedenti di Exchange. Come funziona il nuovo processo di installazione?

R Sì, in realtà il processo di installazione di Exchange 2007 prevede diverse fasi. Di seguito viene riportata una panoramica generale della modalità di funzionamento dell'intero processo.

Quando si esegue setup.exe per la prima volta, si avvia un processo che fornisce i collegamenti per la maggior parte dei prerequisiti che è necessario installare prima di avviare l'installazione dei ruoli del server effettivi. Una volta installati tutti i prerequisiti, è possibile fare clic sul collegamento per l'installazione di Microsoft Exchange (vedere la Figura 1).
Figura 1 Collegamento di installazione disponibile dopo che sono stati soddisfatti i prerequisiti generali
Figura 1 Collegamento di installazione disponibile dopo che sono stati soddisfatti i prerequisiti generali
Se si è eseguito setup.exe dalla rete e si è fatto clic sul collegamento di installazione, i file di installazione principali verranno copiati nella cartella %TEMP%\ExchangeServerSetup\ sul computer locale. Verrà quindi avviata l'Installazione guidata.
L'Installazione guidata mostrerà le diverse opzioni disponibili, come il contratto di licenza, la segnalazione errori e il tipo di installazione (che prevede la selezione dei ruoli del server che si desidera installare). Le pagine della procedura guidata variano in base alla presenza e allo stato dell'organizzazione di Exchange corrente (se disponibile).
Una volta completato il processo di installazione, verrà eseguito un controllo di conformità, in effetti una versione modificata di Microsoft Exchange Server Best Practices Analyzer (BPA), che, per impostazione predefinita, si connetterà a Internet per scaricare il file XML dei prerequisiti più recente. In tal modo sarà possibile aggiornare i prerequisiti periodicamente o risolvere eventuali problemi con cui il team di Exchange ha acquisito familiarità sin dal rilascio del prodotto. Una volta completato il controllo dei prerequisiti, sarà possibile verificare i risultati e procedere; in caso contrario, verranno visualizzati tutti i problemi che potrebbe essere necessario risolvere prima di continuare con l'installazione. Se il server non supera il controllo sei prerequisiti, la procedura guidata consentirà nella maggior parte dei casi di riprovare a eseguire il controllo.
Una volta superato il controllo dei prerequisiti, verrà reso disponibili il pulsante Installa che consentirà di avviare l'installazione di tutti i ruoli scelti in precedenza. Verranno copiati e installati solo i file per i ruoli selezionati.
Al termine del processo di installazione, sarà possibile avviare Exchange Management Console e applicare tutti gli aggiornamenti di Exchange 2007 eventualmente disponibili.

KC Lemson è User Experience Manager per Exchange Server. Il suo conto bancario online è stato temporaneamente sospeso.
Nino Bilic è Supportability Program Manager per Exchange Server. Ha aggiunto di recente un indirizzo di posta elettronica secondario alla sua carta di credito.


 Controllo della protezione: Strumenti per la gestione degli ACL
Controllo della protezione
Strumenti per la gestione degli ACL
Jesper M. Johansson

In Windows, gli elenchi di controllo di accesso (ACL) forniscono un controllo estremamente fine sulla capacità degli utenti e dei processi di utilizzare le risorse, come file e cartelle. La gestione degli ACL può rivelarsi una delle attività più complesse correlate alla protezione dei sistemi degli utenti. Fortunatamente, sono disponibili diverse utilità molto efficaci
che consentono di automatizzare e semplificare le attività associate alle autorizzazioni e agli ACL.
La maggior parte degli utenti avrà familiarità con il vecchio strumento cacls.exe che è stato incluso in ogni versione di Windows NT® sin dalla prima volta in cui questo sistema operativo è stato rilasciato. Se si esegue cacls.exe in Windows Vista™, verrà visualizzato il seguente messaggio di benvenuto:
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
Oltre ad aggiornare gli ACL in Windows Vista (trattati nel numero di giugno 2007 di TechNet Magazine; visitare il sito Web technetmagazine.com/issues/ 2007/06), Microsoft ha anche aggiornato alcuni strumenti utilizzati per la gestione degli ACL. L'aspetto più interessante è che i più significativi di questi aggiornamenti sono utilità da riga di comando.
Icacls.exe è una nuova utilità di Windows Vista (e uno strumento di livello inferiore in Windows Server® 2003 Service Pack 2). Questo strumento sostituirà in tutta probabilità cacls.exe, che, come si saprà già, non è mai stato completamente aggiornato per il supporto delle autorizzazioni più granulari introdotte con Windows® 2000 e pertanto l'ultimo aggiornamento di questa utilità risale a circa sette anni fa.
L'aspetto sorprendente è che, malgrado sia obsoleto, cacls.exe include alcune nuove funzionalità. Primo, è in grado di riconoscere sia i punti di giunzione che i collegamenti simbolici ed è in grado di attraversarli. Secondo, è in grado di stampare e impostare un ACL utilizzando la stringa SDDL (Security Description Definition Language).
Tuttavia, malgrado gli aggiornamenti a cacls.exe, in realtà gli utenti sono interessati alle funzionalità disponibili in icacls.exe.

Salvataggio e ripristino degli ACL
Un mio desiderio costante negli ultimi 10 anni ha riguardato la possibilità di salvare un ACL in modo da poterlo ripristinare in un momento successivo. Questa risulta una delle operazioni più complesse che è possibile eseguire sugli ACL. Eccetto in alcuni casi particolari, sono poche le probabilità di tornare esattamente all'ultimo punto salvato in caso di danneggiamento degli ACL. Tuttavia, questa funzionalità può essere piuttosto utile.
Prima di illustrare le attività di salvataggio e ripristino degli ACL, è bene esaminare il motivo della complessità insita in tali operazioni. Si supponga di disporre di una gerarchia contenente i dati relativi agli studenti di un istituto universitario locale. L'ACL viene salvato il primo febbraio. Il 17 aprile si scopre che l'ACL è stato danneggiato e si decide di ripristinarlo dalla copia salvata. Quali sono le complicazioni associate a questa operazione?
Primo, il nuovo trimestre è iniziato il 2 aprile. Circa il 15% degli studenti si è laureato e di conseguenza le relative directory non sono più disponibili. Pertanto, nel file di backup sono presenti ACL non validi. Inoltre, un gruppo di nuovi studenti, un altro 15%, ha cominciato a seguire i corsi universitari con l'inizio del nuovo trimestre. A questi nuovi studenti, nel file di backup sono ora associate home directory, non gli ACL. Quali sono gli ACL relativi a questi nuovi studenti? C'è poi da considerare il 70% degli studenti rimanenti che hanno creato nuovi file e cartelle e naturalmente ne hanno eliminati altri. È possibile ignorare i file e le cartelle eliminati, ma come configurare le nuove cartelle che hanno creato? Che cosa succede se uno studente decidesse di condividere una cartella con i suoi amici il 4 marzo? Questa attività di condivisione verrà interrotta una volta ripristinato l'ACL?
Il salvataggio e il ripristino degli ACL non sono affatto operazioni semplici. È necessario muoversi con estrema cautela quando si eseguono queste operazioni. È molto probabile inoltre che l'esecuzione di queste operazioni causi un comportamento non definito. Il ripristino degli ACL viene in genere eseguito come ultima risorsa; maggiore è il tempo trascorso sin dall'ultimo backup dell'ACL, maggiore sarà la probabilità che si verifichi un errore durante il processo di ripristino.
Se si desidera tuttavia provare questa funzionalità, eseguire icacls.exe con l'opzione /save:
icacls <target> /save acls.bin /t
Gli ACL verranno quindi salvati in un file denominato acls.bin. Il file conterrà una riga per ogni oggetto con un ACL seguita da una riga che specifica l'ACL nella stringa SDDL. Utilizzando l'opzione /t, il comando consentirà di operare sull'oggetto specificato e su tutti gli oggetti e i contenitori al di sotto di esso.
La funzionalità di salvataggio è un miglioramento del toolkit che può arrecare molti vantaggi, ma presenta alcuni difetti. Consente di salvare, ad esempio, solo l'elenco di controllo di accesso discrezionale (DACL) e non l'elenco di controllo di accesso di sistema (SACL). Se, infatti, è presente un SACL, questa funzionalità consente di salvare un valore fittizio che indica solo la presenza di questo elenco, ma non salva alcuna parte del SACL.
Inoltre, la modalità in cui l'ACL viene salvato crea un problema interessante. Prima di aprire l'ACL salvato con l'editor di testo desiderato, tenere presente un punto fondamentale:
non modificare l'ACL salvato.
Se si dovesse aprire il file contenente l'ACL salvato in un editor di testo, si rileverà che il file sembra essere un file di testo in formato Unicode (UTF-16). Infatti, è quasi identico a un file di testo Unicode. Questo potrebbe indurre a pensare che sia possibile modificarlo e salvarlo da un editor di testo. Evitare di eseguire questa operazione.
Se si apre il file che contiene gli ACL salvati in un editor di testo e lo si salva, non sarà più possibile ripristinare gli ACL da tale file. questo file dopotutto non è affatto un file di testo Unicode. Tale file deve iniziare con 2 byte il cui valore è 0xfffe. Se si salva il file con un editor di testo, ad esempio il Blocco note, questo flag verrà inserito nei primi 2 byte all'interno del file. Lo strumento icacls.exe, tuttavia, si aspetta che i dati ACL inizino in corrispondenza del byte 0 nel file. Di conseguenza, lo strumento non sarà in grado di analizzare gli ACL nel file in quanto si aspetta che i primi due byte facciano parte della stringa che specifica l'oggetto su cui operare. Il file di backup sarà inutilizzabile.
Microsoft è consapevole di questo problema, ma poiché è stato riportato molto tardi nel ciclo Beta per Windows Vista, questo difetto non è stato corretto prima del rilascio di questo sistema operativo. Attualmente non si sa quando o se questo problema verrà corretto. Pertanto, per ora, il consiglio migliore è di evitare di modificare gli ACL salvati. Se occorre salvarli, salvare il file come file .bin e utilizzare un editor esadecimale, come l'ambiente di sviluppo preferito.
Una volta salvato un ACL utilizzando l'opzione /save, è possibile ripristinarlo mediante lo strumento icacls.exe utilizzando l'opzione /restore. Il comando di ripristino nella sua forma più semplice utilizza la seguente sintassi:
icacls <directory> /restore acls.bin
La procedura di ripristino non opera sui file. Per un esempio pratico, esaminare la sequenza di comandi illustrati nella Figura 1. Come illustrato nella figura, viene creato un file di salvataggio puntando icacls.exe a un file. Viene eseguito quindi un tentativo di ripristino del file sostituendo semplicemente /save con /restore. Si verifica un errore in quanto il comando di ripristino opera solo sulle directory. I file da modificare sono già specificati nel file acls.bin. Per ripristinare l'ACL, occorre puntare l'ACL alla directory anziché al file. Questa operazione viene eseguita utilizzando l'ultimo comando illustrato in cui viene specificato "." come oggetto su cui operare.
Figure 1 Salvataggio e ripristino degli ACL (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Tenere presente inoltre che il comando di ripristino deve essere eseguito con privilegi elevati. È possibile eseguire il comando di salvataggio da un prompt dei comandi come amministratore con privilegi minimi o persino come utente standard, purché si disponga del diritto di lettura dell'ACL. Tuttavia, per ripristinare l'ACL, è necessario disporre di un token amministrativo completo e non sofisticato.

Sostituzione di SID
Un'altra funzionalità molto utile in icacls.exe è la capacità di sostituire le autorizzazioni per un utente con le autorizzazioni per un altro utente. Questa operazione viene eseguita durante il ripristino mediante l'opzione /substitute. In base a quanto riportato nella documentazione relativa all'opzione di sostituzione, questa funzionalità richiede l'utilizzo di un SID; tuttavia, in un altro punto della stessa documentazione viene spiegato che è possibile anche utilizzare un normale nome utente. Pertanto, la sequenza illustrata nella Figura 2 funziona.
Figure 2 Sostituzione dei SID durante il ripristino (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
Come si può osservare, il risultato dell'esecuzione di questa sequenza di comandi è un ACL identico a quello disponibile in precedenza, ma la voce ACE che in precedenza specificava le autorizzazioni per foo ora specifica tali autorizzazioni per bar.

Modifica del proprietario
Lo strumento chown è stato per anni la funzionalità di base dei sistemi UNIX. Windows originariamente non prevedeva alcuna funzionalità integrata per la modifica del proprietario di un oggetto. Successivamente, nel Resource Kit è stato incluso lo strumento setowner. Windows NT 4.0 prevedeva invece lo strumento takeown.exe, ma questa utilità consentiva solo di assumere la proprietà non di concederla ad altri utenti, a meno che non si disponesse delle loro password. Ora icacls.exe fornisce un metodo integrato che consente di impostare il proprietario degli oggetti per i quali si dispone dell'autorizzazione per l'impostazione del proprietario:
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Sfortunatamente, icacls.exe non è in grado di visualizzare il proprietario di un oggetto. Non è disponibile alcun metodo per verificare, dalla riga di comando, chi è il proprietario dell'oggetto. Inoltre, se si salva l'ACL per un oggetto, il proprietario dell'oggetto non verrà salvato.
Tenere presente che in icacls.exe è presente un bug dovuto al fatto che questo strumento non richiama SeTakeOwnershipPrivilege per modificare il proprietario. Se si dispone del diritto per la modifica del proprietario di un oggetto in base all'ACL, icacls.exe dovrebbe funzionare in modo corretto. Tuttavia, se si è amministratore, ma non si dispone dell'autorizzazione per la modifica del proprietario in base all'ACL dell'oggetto, non sarà possibile utilizzare icacls.exe a tale scopo a causa del bug sopra menzionato. In tal caso, è necessario utilizzare lo strumento takeown.exe che richiama SeTakeOwnershipPrivilege, ma consente solo di modificare il proprietario nel proprio account o nel gruppo Administrators, non in un account arbitrario:
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Tenere presente che anche lo strumento subinacl, che è possibile scaricare dall'Area download Microsoft, fornisce l'opzione setowner. Subinacl in effetti funziona in molti casi in modo più intuitivo rispetto a icacls, ma è molto più complicato da utilizzare.

Individuazione di file per uno specifico utente
Icacls ha un'altra funzione utile: consente di individuare i file che dispongono di autorizzazioni per specifici utenti. Ad esempio:
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
Questo potrebbe rivelarsi utile nel caso in cui si tenti di individuare il tipo di accesso consentito a uno specifico utente.

Ripristino e modifica degli ACL
Se un ACL viene danneggiato o eliminato, icacls.exe consente di reimpostarlo in modo da ereditare dal relativo padre. Questa funzionalità sarebbe stata estremamente utile per contrastare le minacce di tipo "zero day" che hanno cominciato a colpire nell'autunno del 2006. Un metodo utilizzato per limitare il problema in un componente di Windows è stato negare l'accesso Everyone all'oggetto. Questo era semplice, ma la rimozione della voce di controllo di accesso (ACE) era quasi impossibile mediante gli strumenti integrati in Windows XP e Windows Server 2003. Tuttavia, in Windows Vista, è sufficiente eseguire il seguente comando:
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
Icacls.exe, ovviamente, consente di eseguire tutte le operazioni standard di concessione/negazione/rimozione. L'unico elemento realmente nuovo in questo elenco è la rimozione. Utilizzando questa opzione, è possibile rimuovere tutte le voci ACE di consenso, tutte le voci ACE di negazione o entrambi i tipi di voce per un determinate utente da uno specifico oggetto o gerarchia. Nella Figura 3 vengono illustrati alcuni esempi di diverse operazioni di concessione, rimozione e negazione.
Figure 3 Operazioni di concessione, negazione e rimozione (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
La capacità di rimuovere solo le voci ACE di negazione può risultare utile se si desidera concedere l'accesso a un oggetto a uno specifico gruppo o utente.

Impostazione dei livelli di integrità
Icacls.exe consente inoltre di visualizzare e impostare i livelli di integrità. Windows Vista supporta l'applicazione di etichette di integrità agli oggetti. Icacls.exe è lo strumento da riga di comando da utilizzare per eseguire questa operazione:
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
Tenere presente che icacls.exe visualizza solo un'etichetta di integrità se per un oggetto ne è stata impostata una in modo esplicito. La maggior parte dei file non prevede l'impostazione esplicita di un'etichetta di integrità e pertanto è raro che si sia in grado di visualizzarne una.
Infine, icacls.exe è in grado di verificare se un oggetto contiene un ACL canonico. Come menzionato in precedenza, gli strumenti di terze parti inseriscono le voci ACE nell'ordine errato negli ACL. Icacls.exe è in grado di verificare e correggere questi tipi di problemi, come illustrato di seguito:
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

Interfaccia utente degli ACL
L'interfaccia utente degli ACL è stata lievemente modificata rispetto a quella disponibile in Windows XP. Nelle figure 4 e 5 viene illustrata la finestra di dialogo dell'interfaccia utente degli ACL disponibile in Windows XP e Windows Vista, rispettivamente.
Figura 4 Finestra di dialogo dell'interfaccia utente degli ACL in Windows XP
Figura 4 Finestra di dialogo dell'interfaccia utente degli ACL in Windows XP
Figura 5 Finestra di dialogo dell'interfaccia utente degli ACL in Windows Vista
Figura 5 Finestra di dialogo dell'interfaccia utente degli ACL in Windows Vista
Come è possibile osservare, sono state apportate alcune modifiche. Primo, nella finestra di dialogo viene visualizzato in modo molto chiaro l'oggetto su cui si sta operando, il che può risultare utile se si utilizzano più oggetti contemporaneamente. Secondo, nella parte inferiore della finestra è presente un collegamento ipertestuale utilizzabile nel caso in cui si desideri ricevere assistenza. Tuttavia, la modifica più significativa sta nella rimozione dei pulsanti Aggiungi e Rimuovi che sono stati sostituiti con un pulsante Modifica che viene ampiamente utilizzato a supporto della funzionalità di controllo dell'account utente in Windows Vista. Come è possibile dedurre dalla presenza dell'icona di uno scudo sul pulsante, l'utente che ha avviato questa finestra di dialogo non dispone dell'autorizzazione per la modifica dell'ACL e pertanto sarà necessaria l'elevazione dei privilegi per poter modificare le autorizzazioni. Tenere presente che questa situazione non si verifica per impostazione predefinita se si crea una cartella nella directory radice dell'unità C: e si verificano immediatamente le proprietà. In quanto proprietario della cartella, si disporrebbe di autorizzazioni implicite per la modifica dell'ACL e l'icona dello scudo non verrebbe visualizzata. Lo scudo indica un moniker COM, un meccanismo utilizzato per avviare una richiesta di elevazione per una parte di un processo in esecuzione. Se si fa clic sul pulsante Modifica, viene visualizzata la nota finestra di dialogo per l'elevazione dei privilegi e se, in questa finestra, si fa clic su Continua verrà visualizzata una finestra di dialogo quasi identica a quella visualizzata in Windows XP facendo clic sul pulsante Aggiungi. L'interfaccia utente degli ACL segue questo modello che prevede la visualizzazione di due finestre di dialogo consecutive; viene visualizzata una finestra di dialogo fino a quando non si ottiene l'elevazione dei privilegi e, successivamente, viene visualizzata la nota finestra di dialogo disponibile nelle versioni precedenti di Windows.
Se si fa clic sul pulsante Avanzate e sulla scheda Controllo, viene sempre visualizzato un pulsante per l'elevazione dei privilegi, come illustrato nella Figura 6. Non è possibile modificare il controllo senza l'elevazione, anche se si dispone del controllo completo sull'oggetto e si è il proprietario dell'oggetto. Questo avviene in quanto la capacità di modificare il SACL di un oggetto è gestita dal privilegio SE_SECURITY_NAME, noto come "Gestione file registro di controllo e di protezione" negli strumenti dell'interfaccia utente grafica (GUI). Per impostazione predefinita, solo gli amministratori dispongono di tale diritto. Tuttavia, il privilegio viene rimosso da un amministratore in modalità Approvazione amministratore (quando il controllo dell'account utente è attivato), in quanto è necessaria l'elevazione anche se si è amministratore.
Figura 6 La modifica delle impostazioni di controllo in Windows Vista richiede sempre l'elevazione
Figura 6 La modifica delle impostazioni di controllo in Windows Vista richiede sempre l'elevazione
Una considerazione finale sui requisiti di elevazione quando si modificano gli ACL: tutte queste istruzioni hanno carattere contingente se non si disattiva il controllo dell'account utente. Se si disattiva il controllo dell'account utente, si ripristineranno tutte le funzionalità disponibili in Windows XP, ad eccezione delle finestre di dialogo che hanno un aspetto differente. Tuttavia, non sarà necessaria alcuna elevazione, a condizione che si esegua l'accesso come amministratore, in quanto nel token ora sarà sempre presente il SID del gruppo Administrators.

Altri Strumenti
Icacls.exe è uno strumento molto utile e rappresenta un significativo miglioramento rispetto a cacls.exe, ma presenta alcuni punti deboli. Forse l'inconveniente più significativo è rappresentato dal fatto che non è in grado di gestire l'accesso a oggetti diversi da file e directory. In Windows Vista le modifiche apportate agli ACL di altri oggetti sono minime rispetto a Windows XP, tuttavia non mancano occasioni in cui si desidera gestire gli ACL in un servizio, in una chiave del Registro di sistema o anche in un oggetto Active Directory®.
Se si è avvezzi alla riga di comando, per eseguire questa operazione è necessario utilizzare lo strumento subinacl.exe. Subinacl.exe è incluso negli strumenti di supporto ed è anche disponibile come download.
È bene tuttavia tenere presente che subinacl.exe non è uno strumento facile da utilizzare. Infatti, in alcune situazioni risulta uno strumento senza dubbio poco intuitivo. Tuttavia, subinad.exe è uno strumento incredibilmente potente per la gestione del controllo dell'accesso. Ogni amministratore avanzato necessita di questo strumento.

ACL del Registro di sistema
Analogamente agli ACL del file system, anche negli ACL del Registro di sistema sono state introdotte alcune modifiche. Le modifiche introdotte tuttavia sono di minore entità rispetto a quelle apportate al file system. La differenza più ovvia rispetto alle versioni precedenti di Windows è rappresentata dalla rimozione di quasi tutte le voci ACE del gruppo Power Users, in quanto tale gruppo è stato dichiarato obsoleto. Gli utenti membri del gruppo Power Users dispongono ora degli stessi privilegi degli altri utenti. questo testimonia esattamente la complessità insita negli ACL, ma anche che non tutte le voci ACE per il gruppo Power Users sono state rimosse. Alcune, sfortunatamente, non vengono più utilizzate.
Esaminando gli ACL nel Registro di sistema, è possibile osservare che in alcuni punti è presente una voce ACE per un SID denominato RESTRIZIONI. Questo SID, sebbene non rappresenti una novità per Windows Vista, è molto interessante e poco conosciuto. Il SID RESTRIZIONI denota qualsiasi processo che presenta un token con restrizioni. Un token con restrizioni viene creato utilizzando una funzionalità speciale dell'API CreateRestrictedToken. Un token di questo tipo contiene uno o più SID con restrizioni, ovvero SID che vengono utilizzati in un controllo di accesso separato. Si supponga che un processo sia in esecuzione con un token con restrizioni. Se tale processo tenta di accedere a un oggetto con una voce ACE per il SID RESTRIZIONI, in Windows verranno eseguiti due controlli di accesso. Il primo è un normale controllo di accesso. Il secondo controllo funziona in modo identico al primo ma viene eseguito solo per i SID con restrizioni all'interno del token. È necessario superare entrambi i controlli di accesso.
Attualmente, diversi ACL utilizzano il SID RESTRIZIONI, in particolare nel Registro di sistema. Una schermata di un ACL di questo tipo viene mostrata nella Figura 7.
Figura 7 Gli ACL del Registro di sistema includono una voce ACE per il SID RESTRIZIONI in diversi punti
Figura 7 Gli ACL del Registro di sistema includono una voce ACE per il SID RESTRIZIONI in diversi punti
Attualmente, pochi processi fanno uso della funzionalità token con restrizioni, in particolare per quanto riguarda i SID con restrizioni. Un esempio di processo che fa uso di questa funzionalità è il processo del servizio che ospita Windows Firewall, Base Filtering Engine e Servizio criteri di diagnostica. Utilizza inoltre un token con restrizioni in scrittura. In base alle mie scoperte, solo nove servizi utilizzano correntemente il SID RESTRIZIONI e i token con restrizioni in scrittura in Windows Vista.
Come con le versioni precedenti di Windows, la procedura consigliata in relazione alle autorizzazioni del Registro di sistema è quella di muoversi con estrema cautela. Modificare le autorizzazioni nel Registro di sistema solo in circostanze eccezionali. Dato il complesso modello di ereditarietà e considerate le operazioni sensibili eseguite nel Registro di sistema, esiste la probabilità piuttosto elevata che si verifichi un errore irreversibile se gli ACL nel Registro di sistema vengono modificati senza prestare particolare attenzione.

Riepilogo
Come con la maggior parte delle versioni di Windows, sono state apportate alcune sottili modifiche al controllo dell'accesso in Windows Vista. Tuttavia, a differenza di alcune delle altre versioni recenti, sono state introdotte molte modifiche di minore entità che determinano un significativo cambiamento del comportamento del sistema. Il controllo dell'account utente, in particolare, ha richiesto diverse modifiche, come le etichette di integrità e la modifica dell'interfaccia utente degli ACL. Inoltre, siamo di fronte al primo più importante processo di pulitura degli ACL della storia registrata.
Sotto molti aspetti, gli ACL predefiniti di Windows sono stati semplificati in Windows Vista, cosa mai accaduta in precedenza. Come con le versioni precedenti, tuttavia, è necessario muoversi con estrema nell'ambito del controllo dell'accesso fino a quando non se ne comprende a fondo il funzionamento. Questo vale in particolar modo per le nuove versioni del sistema operativo. È auspicabile che gli strumenti descritti nel presente articolo consentano di semplificare l'esplorazione dei concetti alla base degli ACL.

Jesper M. Johansson, Principal Security Engineer, si occupa dei problemi di protezione del software e collabora con TechNet Magazine come redattore. Detiene un titolo Ph.D in MIS e ha oltre 20 anni di esperienza in ambito di protezione dei computer. Questo articolo è adattato dal nuovo libro di Roger Grimes e Jesper Johansson, Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley, 2007).


 Desktop file: Microsoft Desktop Optimization Pack
Desktop file
Microsoft Desktop Optimization Pack
Wes Miller
Questo articolo si riferisce a una versione preliminare di Microsoft Desktop Optimization Pack. Le informazioni riportate sono soggette a modifiche.

A partire dal rilascio del programma di licenza Software Assurance (SA) diversi anni fa, Microsoft ha aggiunto continuamente nuove funzionalità a SA in modo da offrire ai clienti un valore commerciale aggiunto nel tempo. Oltre a fornire aggiornamenti per i prodotti Microsoft inclusi nella licenza, l'azienda ha cercato di fornire
i prodotti e le tecnologie (tra i primi dei quali è possibile annoverare ad esempio Windows® PE) volti a rendere più proficuo l'impiego di Windows, Office e altre applicazioni software Microsoft all'interno di un'organizzazione.
L'obiettivo principale della distribuzione della maggior parte di questi strumenti e programmi è stato per Microsoft fornire funzionalità aggiuntive al fine di ridurre il costo totale di proprietà di Windows, Office e altre applicazioni Microsoft incluse nella copertura SA di un'organizzazione.
Microsoft ha acquisito diverse aziende nel 2006, accomunate da interessi simili: ridurre il costo di proprietà e la complessità associata alla gestione e al ripristino di Windows e delle applicazioni basate su Windows. Microsoft ha combinato alcune di queste tecnologie acquisite di recente in una nuova offerta di prodotto, disponibile come valore aggiunto per i clienti che dispongono di SA. Tecnologie rilasciate da Softricity, DesktopStandard, AssetMetrix e Winternals Software saranno disponibili tra qualche anno come componenti di Microsoft® Desktop Optimization Pack (MDOP). Inoltre, MDOP includerà un componente che Microsoft ha creato internamente, denominato Microsoft System Center Desktop Error Monitoring.
Microsoft stima che MDOP può consentire alla propria organizzazione un risparmio annuale sui costi che varia da 100 a 500 dollari per ogni desktop, a seconda delle procedure consigliate implementate durante l'utilizzo di MDOP. Ulteriori informazioni su MDOP sono disponibili in linea all'indirizzo windowsvista.com/optimizeddesktop.

Obiettivi di Microsoft Desktop Optimization Pack
L'obiettivo principale di MDOP è consentire a Microsoft di fornire, in un'ottica a breve termine, nuove tecnologie di gestione sulla base di un modello di pianificazione più flessibile, anziché essere legata al rilascio dei nuovi sistemi operativi. Senza dubbio, Microsoft desidera assicurare che non si verifichi più l'estesa lacuna temporale intercorsa tra il rilascio di Windows XP e Windows Vista™. Tuttavia, fornendo strumenti in un intervallo di tempo prevedibile tra una release e quella successiva, MDOP garantirà una maggiore flessibilità nella gestione da parte di Microsoft delle esigenze dei relativi utenti e questo consentirà ai clienti aziendali di massimizzare il valore dei rispettivi investimenti nel software.
Per garantire alle aziende una maggiore flessibilità, Microsoft ha sviluppato una strategia che può consentire ai clienti di passare a un'infrastruttura più dinamica, intendendo con il termine "dinamica" lo stesso concetto cui Microsoft fa riferimento con l'iniziativa DSI (Dynamic Systems Initiative). Per ulteriori dettagli su DSI, leggere le informazioni disponibili sul sito Web microsoft.com/business/dsi.
A questo punto, avendo illustrato in linea generale la strategia di alto livello, è possibile esaminare ciascuna delle cinque tecnologie incluse in MDOP:
  • SoftGrid Application Virtualization
  • Asset Inventory Service
  • Diagnostics and Recovery Toolset
  • Advanced Group Policy Management
  • System Center Desktop Error Monitoring

SoftGrid Application Virtualization
SoftGrid Application Virtualization, tecnologia acquisita da Softricity, fornisce, come implica lo stesso nome, la virtualizzazione delle applicazioni. Quando ho iniziato ad approfondire la conoscenza di SoftGrid, ho compreso che questa tecnologia rappresenta ciò che la pubblicazione delle applicazioni per Windows 2000 IntelliMirror® ha rappresentato. Perché? Perché le applicazioni non vengono pubblicate sui client, ma vengono completamente virtualizzate. Questo consente di rendere più facilmente disponibili le applicazioni sui sistemi client (o Terminal Server). Un aspetto altrettanto importante è la possibilità di gestire le applicazioni centralmente e di richiamarle o aggiornarle in base alle esigenze. Rispetto al modello tradizionale degli MSI e delle trasformazioni, con il modello SoftGrid la complessità e i rischi associati alla distribuzione delle applicazioni si riducono notevolmente.
La tecnologia SoftGrid potrebbe essere assimilata a un'immagine virtuale. È possibile che si abbia familiarità con il concetto di immagine disco utilizzato per la distribuzione sui sistemi di Windows (e in genere delle applicazioni incluse in questa piattaforma) sui sistemi. SoftGrid, in sostanza, include l'applicazione in un'immagine di applicazione anziché in un'immagine del sistema operativo.
SoftGrid Application Virtualization comprende tre componenti chiave: virtualizzazione delle applicazioni, distribuzione delle applicazioni e console di gestione centralizzata.
La virtualizzazione delle applicazioni comprende rappresentazioni virtuali del file system di Windows, inclusi i file di sistema, Registro di sistema di Windows, tipi di carattere, file .ini, oggetti COM/DCOM, servizi, oggetti del kernel (semafori, mutex), oggetti con nome e spazi dei nomi di tutti i componenti.
È importante non confondere la virtualizzazione SoftGrid con la modalità di reindirizzamento eseguita dal controllo dell'account utente di Windows Vista. Con il controllo dell'account utente, quando un'applicazione tenta di scrivere o modificare aree protette del Registro di sistema o del file system, viene reindirizzata a una visualizzazione del Registro di sistema e del file system specifica dell'utente. SoftGrid, invece, esegue una virtualizzazione effettiva dell'applicazione nel sistema operativo, inclusi tutti i componenti del Registro di sistema e del file system di cui è composto. Tuttavia, l'eleganza di SoftGrid risiede nel fatto che questo componente non è un singolo BLOB che definisce un'applicazione. È costituito invece dagli elementi riportati di seguito.
  • Un file SFT con dimensioni fino a 4 GB. Questo file contiene una o più applicazioni e tutte le relative dipendenze, eccetto le dipendenze Windows, che risiedono nei sistemi di destinazione.
  • Un file OSD di circa 2 KB. Questo file contiene una definizione del modo in cui l'applicazione può essere richiesta ed eseguita. È possibile considerare il file OSD come un file EXE.
  • Un file ICO di circa 24 KB. Questo file è in effetti un collegamento per l'avvio dell'applicazione.
  • Un file SPRJ di circa 13 KB. Questo file viene utilizzato dal sequencer (il componente principale di SoftGrid) per pubblicare, aprire, aggiornare e gestire i pacchetti esistenti.
Un diagramma completo sulla modalità di funzionamento di SoftGrid Application Virtualization è disponibile sul sito Web softricity.com/products/architecture.asp.
Un vantaggio enorme della soluzione SoftGrid è rappresentato dalla possibilità di utilizzare una console di gestione centralizzata (vedere la Figura 1) per determinare quali applicazioni sono disponibili per uno specifico utente o gruppo di utenti di Active Directory®. Queste applicazioni possono essere trasmesse in modo rapido agli utenti su richiesta tramite un protocollo di flusso standard del settore. Una volta installate, le applicazioni si comportano come se fossero installate in modalità locale, rispettano le personalizzazioni degli utenti (anche tramite i profili utente mobili) e funzionano anche in caso di disconnessione dei client dalla rete. Gli amministratori possono persino interrompere la disponibilità delle applicazioni, automaticamente o in modo dinamico, ad esempio dopo un periodo di tempo predefinito.
Figura 1 Console di gestione SoftGrid
Figura 1 Console di gestione SoftGrid
L'aspetto più importante è rappresentato dal fatto che, in virtù della modalità di distribuzione delle applicazioni, non è necessario rendere disponibile un'intera applicazione. Vengono scaricati invece solo i componenti necessari per l'esecuzione dell'applicazione utilizzata dall'utente. Si immagini uno scenario in cui tutte le applicazioni di Microsoft Office vengono rese disponibili come pacchetto. Se un utente esegue solo Microsoft Word, verranno scaricati solo i componenti necessari per eseguire questa applicazione, non i componenti necessari per l'esecuzione, ad esempio, di Excel® o PowerPoint®. Non appena l'utente avvia l'esecuzione di una di queste applicazioni, ad esempio Excel, vengono scaricati solo i relativi componenti associati.
Strumenti inclusi in ERD
  • Prompt dei comandi
  • Explorer
  • Ricerca
  • Blocco note
  • Solution Wizard
  • Strumenti di amministrazione: Autoruns, Disk Management, Event Viewer, Registry Editor, Services and Drivers, System Information
  • Strumenti di rete: File Sharing, Map Network Drive, TCP/IP Configuration
  • Utilità di sistema: Crash Analyzer, Disk Commander, DiskWipe, FileRestore, Hotfix Uninstall, Locksmith, System File Repair, System Restore

Un altro componente di SoftGrid è rappresentato dalla funzionalità di controllo automatico delle licenze. Questa capacità garantisce la conformità alla licenza software in uso senza la necessità di software aggiuntivo.
È possibile eseguire la virtualizzazione di quasi qualsiasi applicazione. Le principali eccezioni sono rappresentate da Internet Explorer® e altri componenti di Windows, inclusi gli aggiornamenti rapidi e i Service Pack, software antivirus e driver di dispositivo. Se si desidera approfondire ulteriormente la modalità di funzionamento di SoftGrid ed esplorarne le funzioni, vedere l'articolo disponibile sul sito Web Softricity.com.

Advanced Group Policy Management
DesktopStandard deve la sua fama grazie allo sviluppo di strumenti che hanno colmato alcune delle lacune di Criteri di gruppo. Distribuendo l'applicazione nota in precedenza come GPOVault in MDOP e ora conosciuta come Advanced Group Policy Management, Microsoft ha fornito ai clienti uno strumento straordinario in grado di trasformare l'oggetto Criteri di gruppo da processo potente (e talvolta pericoloso) in un processo perfezionato e più controllato.
Se si ha familiarità con le nozioni di base del software di controllo del codice sorgente, è possibile paragonare Advanced Group Policy Management al controllo del codice sorgente per i Criteri di gruppo di Active Directory. Per una schermata della console Advanced Group Policy Management, vedere la Figura 2. Gli amministratori possono estrarre le revisioni dei criteri esistenti, apportare modifiche e archiviarle di nuovo, controllando i risultati mediante rapporti analoghi a quelli di Console Gestione Criteri di gruppo. Quando l'amministratore ritiene di aver raggiunto lo stato del criterio desiderato, può eseguire il commit delle modifiche e renderle attive. In quanto software di controllo del codice sorgente efficace, se qualcosa non dovesse andare per il verso giusto, è possibile eseguire rapidamente il rollback delle modifiche in una revisione precedente, eliminando le incognite insite in genere in un processo di questo tipo.
Figura 2 Console Advanced Group Policy Management
Figura 2 Console Advanced Group Policy Management
Un altro aspetto chiave di questo processo è la possibilità di modificare i criteri in modalità non in linea, eliminando la necessità di apportare le modifiche desiderate solo su sistemi in linea attivi. Questo consente di eseguire il testing delle modifiche in un ambiente isolato prima di apportare eventuali modifiche all'interno del dominio o dell'unità organizzativa.
Infine, grazie a un modello basato su ruoli, Advanced Group Policy Management consente di introdurre le modifiche attraverso un processo di flusso di lavoro specificamente progettato. Mediante la creazione di ruoli (come editore, revisore, approvatore), un amministratore può assicurare che venga implementato un processo che consenta di apportare le modifiche in modo controllato. Pertanto, quando il responsabile dell'implementazione ritiene che sia il momento giusto per eseguire il commit della modifica, può usufruire di un efficiente meccanismo di controllo delle modifiche per assicurare che non vengano apportate modifiche incontrollate agli oggetti Criteri di gruppo senza l'appropriata approvazione.

Asset Inventory Service
Il componente Asset Inventory Service, composto dalla tecnologia di cui Microsoft può usufruire grazie all'acquisizione di AssetMetrix, è una soluzione di gestione delle risorse e delle operazioni di inventario molto potente. A differenza degli altri componenti di MDOP, AIS utilizza un modello Web ospitato. AIS prevede l'utilizzo di un agente a larghezza di banda limitata e con footprint ridotto, che può essere eseguito una sola volta o a intervalli periodici, consentendo a un amministratore di eseguire la ricerca di determinate applicazioni all'interno di un database ospitato da Microsoft, incredibilmente esteso e composto da oltre 400.000 applicazioni, per determinare quali applicazioni sono installate nei sistemi client. AIS può estrarre questi dati aggregati e riconciliarli con le licenze acquistate per assicurare la conformità e ridurre gli sprechi dovuti all'acquisto di un numero eccessivo di licenze software.
Alcuni amministratori potrebbero avere inizialmente qualche esitazione sull'opportunità di utilizzare AIS dal momento che è un modello ospitato all'esterno del firewall ed esegue l'inventario dei sistemi interni per il software installato. Tuttavia, è importante comprendere il notevole impegno dedicato da Microsoft per garantire la privacy delle organizzazioni, che si è concretizzato con la riscrittura dei componenti principali dell'applicazione su cui AIS si basa. Non esiste alcun collegamento tra i dati dei singoli computer e i dati dell'organizzazione. Microsoft inoltre certificherà la tecnologia di trasferimento dei dati con un'azienda di terze parti per assicurare che i clienti si trovino a loro agio con il modello utilizzato da AIS.

Diagnostics and Recovery Toolset
Come forse si saprà già (se si è letto la mia biografia negli articoli pubblicati alcuni mesi fa), io ero un membro di Winternals quando è stata acquisita da Microsoft. Nel corso del mio mandato in questa società ho ricoperto il ruolo di Product Manager per la maggior parte dei prodotti di Winternals, compreso Winternals Administrator's Pak, il predecessore di Microsoft Diagnostics and Recovery Toolset (DaRT). Sebbene alcuni degli strumenti precedentemente forniti da Administrator's Pak non siano stati inclusi in DaRT, i componenti chiave del prodotto ERD Commander sono ancora disponibili.
L'obiettivo principale di DaRT è fornire un insieme di strumenti che possono aiutare a diagnosticare i problemi a livello di sistema, anche nel caso in cui un sistema non venga avviato in modo corretto. È possibile inoltre risolvere questi problemi in modalità non in linea.
ERD Commander utilizza Windows PE per avviare un sistema nel caso in cui quest'ultimo non si avvii o si avvii in modo anomalo. Una serie di utili strumenti sono integrati in un'interfaccia utente personalizzata simile a Esplora risorse. Due di questi strumenti, Crash Analyzer e FileRestore, sono disponibili anche per l'utilizzo in modalità in linea. È tuttavia necessario installare questi strumenti in ogni sistema su cui si desidera eseguirli nel caso in cui non si utilizzi ERD Commander per il ripristino o la diagnostica fuori linea.
La versione DaRT di ERD Commander è illustrata nella Figura 3. Nell'intestazione laterale è disponibile un elenco degli strumenti inclusi nel componente ERD Commander. Ad eccezione dello strumento Explorer, i primi cinque strumenti elencati corrispondono alle stesse applicazioni utilizzate in una normale installazione di Windows. Explorer è, analogamente all'applicazione Start Menu da cui viene avviato, una versione specializzata (di minori dimensioni) progettata per l'esecuzione su Windows PE.
Figura 3 ERD Commander
Figura 3 ERD Commander
Autoruns è uno strumento, derivato da uno strumento di Sysinternals con lo stesso nome, che consente di visualizzare tutte le applicazioni configurate per l'avvio all'avvio del sistema o quando un utente esegue l'accesso. Disk Management, Event Viewer, Services and Drivers e System Information sono strumenti integrati in un'interfaccia utente comune che forniscono esperienze comparabili a quelle offerte dagli strumenti con nome simile disponibili in Windows. Services and Drivers è particolarmente utile in quanto può consentire di eseguire l'avvio in caso di errore del sistema dovuto al funzionamento non corretto di un servizio o un driver di dispositivo. Infine, è stato incluso l'editor del Registro di sistema di Windows in modo da consentire la modifica del Registro di sistema di un sistema non in linea.
ERD Commander fornisce inoltre il supporto per la connettività di rete. Sebbene il sistema sia automaticamente configurato tramite DHCP, è possibile impostare un indirizzo IP statico utilizzando l'applet TCP/IP Configuration. Indipendentemente da se si utilizzi DHCP o l'indirizzamento IP statico, è possibile eseguire il mapping di un'unità di rete e copiare i file in o dal sistema inattivo oppure utilizzare File Sharing per convertire il sistema in un file server in modo che sia possibile utilizzare un sistema funzionante in cui copiare i file del sistema su cui si è verificato l'errore.
Infine, è disponibile un insieme di strumenti di vario tipo. Crash Analyzer utilizza gli strumenti di debug per Windows (gratuiti ma aggiornati frequentemente che devono essere scaricati e installati separatamente) per diagnosticare la causa di un arresto anomalo. È possibile eseguirlo in modalità non in linea su ERD Commander nel caso in cui non sia possibile avviare il sistema o copiare un file DMP in un sistema funzionante su cui sia installato DaRT e diagnosticare il problema da tale sistema. Se la causa del problema è un nuovo servizio o driver, è possibile utilizzare lo strumento Services and Drivers per disattivarlo e verificare se il sistema ritorna al normale funzionamento.
Disk Commander consente di ripristinare una partizione accidentalmente eliminata o danneggiata nonché un gruppo di file o una directory che è stata eliminata. DiskWipe, al contrario, consente di completare la cancellazione del contenuto di un volume o un disco compatibile con DoD. FileRestore consente di ripristinare (in modalità in linea o non in linea) un singolo file eliminato accidentalmente. Tenere presente che il tipo di file eliminato e il periodo di tempo trascorso o le attività su disco eseguite dopo l'eliminazione incideranno sulla capacità di ripristino, indipendentemente dallo strumento utilizzato.
Nel caso in cui un aggiornamento rapido o un Service Pack di Windows impedisca il normale avvio del sistema, è possibile utilizzare Hotfix Uninstall per disinstallare in modo selettivo uno o più aggiornamenti rapidi o Service Pack. Il completamento del processo richiede il riavvio del sistema in quanto Windows non supporta la completa rimozione in modalità non in linea delle applicazioni. Tuttavia, è possibile che in molti casi consenta il riavvio.
Locksmith è stato uno degli strumenti più utilizzati inclusi nel set di strumenti di ERD Commander presso Winternals. Consente di reimpostare la password di qualsiasi utente locale. Non funziona sui controller di dominio e non consente di reimpostare le password degli utenti di dominio, ma viene in genere utilizzato per reimpostare la password dell'amministratore locale nel caso in cui venga dimenticata o l'utente abbia lasciato l'organizzazione. System File Repair consente di analizzare tutti i file di sistema protetti per verificare se sono danneggiati ed eventualmente eseguirne la sostituzione, se necessario. System Restore, come implica lo stesso nome, consente di eseguire il rollback o il rollforward in qualsiasi punto di ripristino configurazione di sistema di Windows su un sistema Windows XP (per utilizzare questa funzionalità è necessario Windows XP con punti di ripristino preesistenti). Anch'io sono tra i numerosi utenti che sono stati "salvati" da questa funzionalità unica.
È possibile che si gli strumenti inclusi in ERD Commander e DaRT diano l'impressione di essere casuali, al di fuori di qualsiasi contesto funzionale, ma rappresentano un potente set di utilità che Winternals ha sviluppato nel tempo. Sono sicuro che si avrà modo di appurarne il valore e di verificare la relativa utilità, in particolar modo per le attività di ripristino e risoluzione dei problemi.

System Center Desktop Error Monitoring
System Center Desktop Error Monitoring (DEM) fornisce alle organizzazioni un metodo semplice per la gestione centralizzata e la diagnostica degli arresti anomali di Windows e dei blocchi delle applicazioni. Anziché inviare rapporti sugli arresti anomali e sui blocchi a Microsoft, DEM utilizza Criteri di gruppo e la funzionalità integrata Segnalazione errori Windows per inviare rapporti a un server designato all'interno dell'organizzazione per la diagnosi (senza richiedere un agente software aggiuntivo). Tutti i dati del server DEM vengono memorizzati in un database SQL Server in modo da poter eseguire con facilità query sui dati raccolti per le applicazioni interne e le segnalazioni. Questo consente di diagnosticare i problemi all'interno dell'organizzazione in modo proattivo. Utilizzando queste informazioni, è possibile effettuare la segnalazione di eventuali problemi, identificare le cause più frequenti degli arresti anomali e dei blocchi e assicurare l'assegnazione di priorità alle patch di Windows e delle applicazioni per ridurre al minimo o eliminare i tempi di inattività del sistema.
È inoltre possibile configurare il server DEM per il caricamento dei risultati in Microsoft e per il download automatico dei dati più recenti relativi alla risoluzione dei problemi per le applicazioni Microsoft e di terze parti. È possibile inoltre, in caso di arresto anomalo o di blocco, raccogliere dati aggiuntivi dai client.

Licenze per MDOP
Il primo requisito perché un cliente possa concedere in licenza MDOP è l'esistenza di un contratto Microsoft SA. I costi delle licenze variano dai 7 ai 10 dollari per desktop. Sono disponibili sconti per volume e prezzi accademici.
MDOP non è disponibile all'esterno del contesto di un contratto SA, con un'unica eccezione: ai clienti che desiderano utilizzare le tecnologie SoftGrid con i relativi Terminal Server (visitare il sito Web softricity.com/solutions/sbc.asp) o SMS (visitare il sito Web softricity.com/products/softgrid-sms.asp) questo è consentito e le tecnologie AssetMetrix verranno rese disponibili nelle future versioni di SMS e System Center Configuration Manager.

Disponibilità e aggiornamenti
I componenti iniziali di MDOP sono attualmente disponibili. Di seguito vengono riportate le date della distribuzione di questi componenti :
  • SoftGrid è stato reso disponibile da Microsoft fin dall'inizio del 2007.
  • Microsoft DaRT è stato reso disponibile a partire dal mese di maggio 2007.
  • Le tecnologie GPOVault saranno disponibili nel mese di luglio 2007.
  • Desktop Error Monitoring sarà disponibile in MDOP nel mese di luglio 2007.
  • Le tecnologie AssetMetrix saranno disponibili in versione beta nel mese di luglio 2007, mentre la versione definitiva è prevista per il mese di agosto.
  • Un aggiornamento ai componenti di DaRT è previsto per la fine del 2007 e il principale miglioramento sarà rappresentato dalla compatibilità con Windows Vista.
Si prevede di fornire miglioramenti, aggiornamenti e nuove funzionalità per le versioni future di MDOP due volte all'anno.

Previsioni per MDOP
Come affermato in precedenza, i componenti chiave delle tecnologie di AssetMetrix verranno integrati nelle future versioni di System Center Configuration Manager. In realtà, è possibile prevedere che nel corso del tempo, man mano che le funzionalità di MDOP si evolvono, alcune di esse verranno gradualmente integrate nelle tecnologie di distribuzione, gestione e configurazione di Microsoft di base. Le nuove tecnologie (alcune create da Microsoft, altre acquisite dalle aziende di terze parti), verranno rese disponibili nelle versioni future di MDOP. In sostanza, MDOP sarà un pacchetto in continua evoluzione di tecnologie di gestione e configurazione all'avanguardia.

Wes Miller è Development Manager presso Pluck ad Austin, Texas. In precedenza, ha lavorato per Winternals Software ad Austin e in Microsoft come Program Manager e Product Manager di Windows. È possibile contattarlo all'indirizzo technet@getwired.com.
Desidero esprimere la mia gratitudine a Chad Jones e Gavriella Schuster, Product Manager per Microsoft Desktop Optimization Pack, per l'assistenza che mi hanno fornito per la redazione di questo articolo.


 Windows Confidential: I poteri terapeutici della modalit&#224; provvisoria
Windows Confidential
I poteri terapeutici della modalità provvisoria
Raymond Chen

Quando la modalità provvisoria di Windows (anche nota come modalità "oh no è tutto un disastro per favore correggi") è stata inizialmente sviluppata per Windows® 95, si è andati oltre la semplice disattivazione dei driver prevedendo anche il ripristino di ciò che poteva essere ripristinato automaticamente.
Ad esempio, quando si esegue l'avvio in modalità provvisoria, Esplora risorse controlla le posizioni di tutte le icone sul desktop per verificare che siano tutte visibili, poiché è possibile che un'icona sia stata posizionata fuori dello schermo.
Per rendersi conto di ciò di cui sto parlando, è necessario posizionare due icone sul desktop, una sul lato sinistro e l'altra sul lato destro. Fare clic su di esse tenendo premuto CTRL per selezionarle entrambe, quindi trascinare l'icona di sinistra sul lato destro dello schermo. Così facendo si sposterà anche la seconda icona, mantenendo la stessa posizione relativa rispetto all'icona trascinata. In questo modo la seconda icona risulta spostata all'esterno dello schermo.
La modalità provvisoria consente agli utenti di risolvere i problemi di Windows
La modalità provvisoria consente agli utenti di risolvere i problemi di Windows
Se Esplora risorse non correggesse le posizioni delle icone in modalità provvisoria, le istruzioni per la risoluzione dei problemi potrebbero creare più confusione anziché essere di aiuto:
  1. Avviare il computer in modalità provvisoria (OK).
  2. Fare doppio clic sull'icona Risorse del computer (uhm, non vedo alcuna icona Risorse del computer).
  3. ...
L'icona Risorse del computer è fuori schermo o altrimenti non disponibile e non è neanche possibile procedere al passaggio due della risoluzione dei problemi.
Alcuni si sono lamentati dicendo: "Le icone non dovrebbero essere corrette automaticamente. Se un utente chiama il supporto tecnico per un problema, il tecnico può semplicemente dire all'utente di fare clic con il pulsante destro del mouse sul desktop e di selezionare l'opzione per ripristinare le posizioni delle icone. Missione compiuta e la modalità provvisoria non ha alterato le mie icone".
Innanzitutto, dicendo "se un utente chiama il supporto tecnico per un problema", la partita è già stata persa. Se un utente deve alzare il telefono, è già un fallimento.
Inoltre, questa proposta dimostra di non aver compreso la psicologia della modalità provvisoria. Gli utenti eseguono l'avvio in modalità provvisoria quando qualcosa non funziona correttamente, anche se non necessariamente sanno che cosa faranno dopo averla avviata. Ciò che in effetti fanno è vedere che cosa succederà: "Qualcosa non va, proviamo in modalità provvisoria". In Windows 95, abbiamo sfruttato questa psicologia implementando vari tipi di azioni di correzione automatica in modalità provvisoria e la cosa ha funzionato abbastanza bene.
Inoltre, se gli utenti chiamano e si sentono dire: "Avvia il computer in modalità provvisoria e il problema verrà corretto", penseranno: "Era facile, avrei dovuto pensarci".
Ma se si dà loro una serie più lunga di istruzioni del tipo "Avvia il computer in modalità provvisoria, fai clic qui con il pulsante destro del mouse, scegli questa opzione di menu, quindi seleziona questa casella", gli utenti seguiranno le istruzioni e il problema verrà risolto, ma senza aggiungere nulla per farli sentire più a proprio agio con i computer. Si sentiranno invece incerti e scoraggiati. Anziché uscirne più forti, gli utenti cadono in uno stato di consapevole impotenza: "Non ci sarei mai arrivato da solo. I computer sono così difficili da usare".

Raymond Chen, The Old New Thing, come nel suo libro omonimo (Addison-Wesley, 2007), vengono illustrate la storia di Windows e la programmazione in Win32. Preferisce andarsene prima che si accenda la miccia.