 TechNet Magazine December 2006
TechNet Magazine December 2006
DECEMBER 2006
Exchange Server 2007

È in vista il passaggio a Exchange 2007? Qui è possibile ottenere tutte le informazioni necessarie. Questo mese vengono illustrati i preparativi necessari per l'aggiornamento, la creazione di script per la gestione di Exchange tramite l'Exchange Management Shell e le operazioni da eseguire per ottenere i migliori risultati con l'accesso da postazioni remote e la messaggistica unificata quando si combinano Outlook Web Access ed Exchange 2007.

Inoltre sarà possibile leggere informazioni su tutti i miglioramenti più recenti di Exchange Server 2007 e del client Outlook 2007, apprendere delle metodologie per evitare la ricezione di posta indesiderata con il Sender ID Framework ed esplorare l'inserimento nel journal in Exchange 2007 per migliori controllo e conformità.
FUNZIONALITÀ
Exchange Server 2007 Aggiornamento dell'infrastruttura a Exchange 2007

Per una transizione senza problemi a Exchange Server 2007 in organizzazioni di qualsiasi dimensione, è necessaria un'attenta pianificazione iniziale. Un piano messo a punto in modo corretto consente di evitare interruzioni del servizio. Qui sono presentate le procedure da adottare per eseguire l'aggiornamento.

Kate Follis Prendere il comando con l'Exchange Management Shell

L'Exchange Management Shell rappresenta per gli amministratori una potente interfaccia per la gestione di qualsiasi aspetto di Exchange Server 2007. Questa è una panoramica su creazione di script, integrazione di applicazioni e altre utili attività di gestione eseguite da riga di comando.

David Strome Exchange & Outlook: meglio insieme

Se utilizzati insieme, Exchange Server 2007 e Microsoft Office Outlook 2007 rappresentano un notevole passo avanti negli ambiti di comunicazione e collaborazione. In questo articolo sono descritte le funzionalità di configurazione semplificata, ricerca potenziata, messaggistica unificata e altre ancora.

Michael Khalili Sempre in contatto con Exchange 2007

La comunicazione è diventata più potente che mai. Messaggistica unificata e Outlook Web Access di Exchange Server 2007 consentono di accedere a tutti i propri messaggi da qualsiasi luogo.

Joshua Trupin Inserimento nel journal più efficace con Exchange 2007

Exchange Server 2007 offre funzionalità di inserimento nel journal più flessibili, semplificando il monitoraggio degli account di utenti specifici e garantendo il rispetto dei requisiti di conformità delle grandi organizzazioni.

David Strome Utilizzo dell'ID mittente per combattere posta indesiderata e phishing

L'autenticazione della posta elettronica integrata nel Sender ID Framework (SIDF) è sempre più diffusa e costituisce un punto di svolta nella lotta contro i messaggi di posta indesiderata e phishing. Più di un terzo dell'intero volume della posta elettronica nel mondo è già autenticata e conforme al SIDF. Ecco come funziona.

Craig Spiezle e Alexander Nikolayev
COLONNE
Editoriale

Una comunità sempre più ampia

Joshua Trupin Toolbox

Nuovi prodotti per i professionisti dell'IT

Greg Steen Windows PowerShell

Comandi semplici, amministrazione perfetta

Don Jones Post Mortem

Migrazione da Exchange 5.5

Whitney Roberts 		Domande e risposte su SQL

Come limitare i riavvii, installare più aggiornamenti e altro ancora

A cura di Nancy Michell Hey, Scripting Guy!

Dove sono i supporti per i bicchieri?

Gli Scripting Guy di Microsoft Osservatorio sulla sicurezza

Distribuzione di una PKI attendibile globale

John Morello I desktop file

Un'analisi approfondita del formato Windows Imaging

Wes Miller Windows - Informazioni riservate

Aspettando RunOnce

Raymond Chen


 Exchange Server 2007: Aggiornamento dell'infrastruttura a Exchange 2007
Exchange Server 2007 Kate Follis

Aggiornamento dell'infrastruttura a Exchange 2007
Panoramica:
  • Novità in Exchange 2007
  • Preparazione all'aggiornamento
  • Distribuzione basata sui ruoli
  • Topologia di routing dei messaggi

Ho tenuto corsi sulla migrazione da Exchange Server 5.5 a Exchange 2000 Server. I corsi iniziavano alle 8:30 e terminavano intorno alle 18:00. Lasciavo la classe
esausta e svuotata di ogni energia. Ricordo il lungo e accurato lavoro di preparazione che precedeva il semplice spostamento delle risorse di directory e l'enorme confusione che imperversava sull'utilità NTDSNoMatch e la relazione di trust tra i domini di Windows NT® 4.0. A causa del tempo limitato, ci soffermavamo solo brevemente sull'argomento relativo all'amministrazione di Exchange 2000 Server. Ricordo tuttavia una coppia di studenti appassionati che aveva annunciato l'intenzione di lasciare il corso il venerdì sera e completare il processo di migrazione nel corso del fine settimana. Sebbene li avessi messi in guardia sulla necessità di dedicare maggior tempo alla pianificazione, dubito che abbiano seguito il mio consiglio.
La transizione da Exchange 2000 Server o Exchange Server 2003 a Exchange Server 2007 richiede lo stesso tipo di attenzione: è necessario dedicare un del tempo alla pianificazione. Anche se varia a seconda delle dimensioni dell'organizzazione e della complessità della distribuzione corrente, il processo di transizione effettivo prevede diverse fasi. Un'organizzazione di piccole dimensioni potrebbe gestire queste fasi come un singolo progetto, mentre un'organizzazione di grandi dimensioni potrebbe decidere di introdurre gradualmente i ruoli del server e fornire il supporto per Exchange attraverso lo sviluppo di strategie di coesistenza per uno specifico periodo di tempo. Il processo end-to-end ha lo scopo di mantenere le funzionalità di messaggistica e di non compromettere la stabilità nel corso dell'intero periodo di transizione. In questo articolo l'attenzione verrà posta sui passaggi fondamentali necessari per la gestione del flusso di messaggi all'interno dell'organizzazione durante l'aggiornamento a Exchange Server 2007.

Considerazioni
Il primo requisito da prendere in considerazione è la necessità di distribuire Exchange Server 2007 su hardware a 64 bit e l'assenza di supporto per un aggiornamento diretto da nessuna delle versioni precedenti di Exchange. È necessario utilizzare il metodo di aggiornamento swing per la migrazione dei servizi di messaggistica esistenti a Exchange 2007. Per supportare l'aggiunta dei server di Exchange 2007, è necessario inoltre che l'organizzazione Exchange operi in modalità nativa. Se, pertanto, l'organizzazione utilizza Exchange 5.5, sarà necessario eseguire un aggiornamento provvisorio a Exchange Server 2003 prima di passare a Exchange 2007.
Sono state introdotte alcune importanti modifiche in Exchange 2007 che è necessario prendere in considerazione durante la pianificazione del processo di transizione. Con Exchange 2007 viene ad esempio introdotta la distribuzione basata sui ruoli, che consente di scegliere i servizi di messaggistica desiderati per fornire e distribuire i ruoli del server specifici dei servizi. È possibile distribuire i ruoli del server singolarmente su hardware dedicato o installare più ruoli sullo stesso server fisico, amministrati come entità separate. Per una descrizione di ciascun ruolo, vedere il riquadro "Ruoli del server di Exchange 2007".
Ruoli del server di Exchange Server 2007
Server Cassette postali Il ruolo del server Cassette postali è l'archivio messaggi di un'organizzazione. Exchange 2007 supporta fino a 50 archivi per server. Gli archivi possono essere distribuiti come 50 singoli gruppi di archiviazione oppure è possibile creare fino a 50 archivi in un singolo gruppo di archiviazione. Il ruolo del server Cassette postali è l'unico ruolo che è possibile distribuire come cluster. Se si prevede quindi di utilizzare il clustering, sarà necessario installare il server Cassette postali su hardware dedicato.
Server Accesso client Il ruolo del server Accesso client sostituisce la funzionalità fornita da un server front-end e consente l'accesso alle cassette postali ai client che si connettono a Exchange tramite POP3, IMAP4, Outlook® Web Access (OWA), RPC su HTTPS (ora Outlook Anywhere) ed Exchange ActiveSync®.
Server Trasporto hub Questo ruolo fornisce i servizi di trasporto dei messaggi SMTP e MAPI per l'organizzazione Exchange. Ogni messaggio inviato o ricevuto dagli utenti nell'organizzazione viene elaborato da un server Trasporto hub. Si tratta di una funzionalità straordinaria, poiché garantisce che nessun messaggio possa ignorare le regole basate su server o i criteri di inserimento nel journal che vengono forniti da agenti attivati in diversi punti della pipeline di trasporto.
Server Messaggistica unificata Questo ruolo fornisce l'accesso vocale alle cassette postali e garantisce l'integrazione con il gateway IP/VoIP o IP-PBX per consentire l'accesso tramite telefono ai messaggi e alle voci del calendario, in modo che gli utenti possano trascrivere una risposta. Questo ruolo rappresenta una novità in Exchange e non è in grado di interoperare con nessuna versione precedente di Exchange.
Server Trasporto edge Il server Trasporto edge viene in genere distribuito nella rete perimetrale. Il ruolo consente il trasporto di messaggi SMTP tra l'organizzazione Exchange e Internet nonché l'elaborazione della posta indesiderata e degli antivirus mediante l'uso di agenti di trasporto. Ora è possibile adottare una singola tecnologia per i server della rete perimetrale e dell'organizzazione. Questo modello di interazione trasparente semplifica l'amministrazione e l'integrazione dei server della rete perimetrale.

Analisi della topologia
È necessario definire innanzitutto un punto di partenza: è importante infatti sapere dove si è per decidere dove andare. Valutare attentamente l'ambiente corrente, non solo l'ambiente Exchange ma anche Active Directory®, e documentarne la topologia. Si accoglierà probabilmente con piacere la notizia che Exchange 2007 non fornisce più il supporto per il routing di stato dei collegamenti e la topologia basata su connettori e gruppi di routing. Exchange 2007 sfrutta invece i vantaggi derivanti dagli investimenti che l'organizzazione ha già sostenuto nella progettazione della topologia di Active Directory. Di conseguenza, tutti i dati di configurazione e dei destinatari di Exchange vengono archiviati in Active Directory, la topologia di routing viene derivata dalla configurazione dei siti di Active Directory e tutti i ruoli del server utilizzeranno le informazioni del sito per individuare i servizi in esecuzione su altri ruoli del server.
È necessario prima accertarsi che la topologia dei siti di Active Directory corrente sfrutti la rete fisica sottostante e che a tutti i siti di Active Directory siano associate delle subnet, quindi documentare i siti e i collegamenti al sito IP di Active Directory esistenti. È inoltre necessario documentare la posizione fisica in cui sono ubicati tutti i server di Exchange 2003, nonché la struttura dei gruppi di routing e dei connettori di gruppi di routing.
Questa è la fase più complessa del processo di transizione: il passaggio da un'infrastruttura di routing Exchange basata su gruppi di routing a un'infrastruttura di routing basata sui siti di Active Directory. Per un'organizzazione di piccole dimensioni, si tratta in genere di un processo semplice. Tuttavia, un'organizzazione di grandi dimensioni con numerosi gruppi di routing dovrà pianificare con attenzione una fase provvisoria che preveda la coesistenza di Exchange 2003 ed Exchange 2007. Una situazione assolutamente da evitare è uno scenario che prevede l'invio all'interno della stessa sede aziendale di un messaggio dall'utente di Exchange 2007 alla cassetta postale di Exchange 2003, instradato attraverso un gruppo di routing remoto tramite una connessione con larghezza di banda ridotta.
È possibile iniziare formulando alcune ipotesi sulla topologia corrente:
  • L'organizzazione di Exchange 2003 opera in modalità nativa.
  • Si dispone di più gruppi di routing.
  • Sono disponibili più siti di Active Directory.
Nella Figura 1 viene rappresenta una topologia di Exchange e di Active Directory. È opportuno ricordare che maggiore sarà il numero di dettagli inclusi nella pianificazione preliminare, migliore risulterà la progettazione.
Figura 1 Topologia di Exchange e Active Directory
Figura 1 Topologia di Exchange e Active Directory (Fare clic sull'immagine per ridurla)
Figura 1 Topologia di Exchange e Active Directory
Figura 1 Topologia di Exchange e Active Directory (Fare clic sull'immagine per ingrandirla)

Utilizzo di Active Directory in Exchange 2007
Quando viene avviato, un server di Exchange 2007 viene contrassegnato con un attributo sito che consente ad altri server di Exchange 2007 di individuare i servizi forniti dal server. Solo il server Trasporto hub può utilizzare il protocollo SMTP per trasportare un messaggio all'interno dell'organizzazione. Ciascun sito di Active Directory che contiene un server Cassette postali deve anche contenere un server Trasporto hub e, se gli utenti delle cassette postali accedono alle relative cassette postali utilizzando un metodo non MAPI, ciascun sito dovrà anche contenere un server Accesso client. Ogni volta che un messaggio deve essere elaborato per il recapito, passa attraverso un server Trasporto hub, che stabilirà la modalità di routing del messaggio. Se il messaggio è destinato a un server Cassette postali nello stesso sito di Active Directory del server Trasporto hub, quest'ultimo provvederà al recapito del messaggio alla cassetta postale. Se il messaggio è destinato a un server Cassette postali che si trova in un altro sito, il server Trasporto hub inoltrerà il messaggio direttamente a un server Trasporto hub che risiede nel sito remoto.
Il server Trasporto hub utilizza le informazioni sui costi dei collegamenti al sito IP di Active Directory per calcolare la route con il costo più basso verso il sito di Active Directory in cui si trova la cassetta postale del destinatario. L'algoritmo di selezione della route è molto simile a quello utilizzato in Exchange 2003, ma è basato sui costi dei collegamenti al sito IP anziché sui costi dei connettori di gruppi di routing. La trasmissione del messaggio inoltre non si arresta in corrispondenza di ogni server Trasporto hub lungo il percorso di routing, ma il messaggio passa direttamente dall'origine alla destinazione. Perché quindi calcolare la route con il costo più basso se il trasporto del messaggio si basa sulla rete IP? È importante sottolineare due motivi in particolare. Uno riguarda la necessità di differire la moltiplicazione del messaggio. Potrebbe essere necessario ad esempio recapitare un messaggio inviato a più destinatari a server Cassette postali che si trovano in più siti di Active Directory. Anziché moltiplicare o suddividere il messaggio in corrispondenza del primo server Trasporto hub, Exchange 2007 differisce la suddivisione fino a quando il messaggio non raggiunge una biforcazione nel percorso di routing. Di conseguenza, il messaggio verrà inoltrato direttamente a un server Trasporto hub nel sito di Active Directory che rappresenta il punto di moltiplicazione. Questa funzionalità è nota come fan-out differito.
La route con il costo più basso viene inoltre utilizzata per determinare la posizione in cui accodare il messaggio, nel caso in cui la destinazione non sia raggiungibile. Se un server Trasporto hub nel sito di Active Directory di destinazione non è raggiungibile, il server Trasporto hub di invio tenterà di recapitare il messaggio a un server Trasporto hub nel sito di Active Directory successivo più vicino in base al percorso di routing. Il recapito del messaggio proseguirà lungo la route con il costo più basso, fino a quando non raggiunge un sito di Active Directory in cui sia disponibile un server Trasporto hub. Infine, se lungo la route verso il sito di Active Directory del destinatario non è disponibile alcun server Trasporto hub, il messaggio verrà accodato localmente. Questo metodo consente di accodare il messaggio quanto più vicino possibile al punto di recapito, rendendo più deterministica la diagnosi degli errori di rete. Questo comportamento è noto come "coda nel punto di errore".
Exchange 2003 opera in modo completamente differente, poiché calcola la route dal costo più basso da un gruppo di routing a un altro in base ai costi assegnati ai connettori di gruppi di routing. Un server testa di ponte in ciascun gruppo di routing lungo il percorso di routing riceverà il messaggio e lo inoltrerà. Se il connettore successivo nel percorso non è disponibile, si tenterà di calcolare una route alternativa. All'interno dell'organizzazione di Exchange vengono inoltre trasmessi messaggi relativi agli aggiornamenti dello stato dei collegamenti per informare gli altri server di Exchange che la connessione non è disponibile. I server testa di ponte tenteranno di eseguire il routing ignorando il connettore non disponibile fino a quando non viene ricevuta una notifica sullo stato dei collegamenti che indichi che la connessione è attiva.
La principale difficoltà nel corso della transizione di un'organizzazione di grandi dimensioni consiste nel garantire il flusso costante dei messaggi di posta elettronica durante il periodo di coesistenza. Per garantire la continuità quando Exchange 2007 viene inserito nell'ambiente, tutti i server di Exchange 2007 diventano membri di un singolo gruppo di routing. Ne consegue che, indipendentemente dal sito di Active Directory in cui si trova il server di Exchange 2007, il server verrà considerato da Exchange 2003 come appartenente al gruppo di routing in questione. In tal modo è possibile stabilire un connettore di gruppi di routing tra il gruppo di routing in oggetto e i gruppi di routing di Exchange 2003, in modo che Exchange 2003 sia in grado di determinare il metodo con cui eseguire il routing dei messaggi verso Exchange 2007. Anche in Exchange 2007 verrà utilizzato il connettore dei gruppi di routing per determinare il metodo con cui inviare messaggi a Exchange 2003. Tuttavia, Exchange 2007 preferirà sempre eseguire il routing di un messaggio attraverso un altro server Exchange 2007 e non verrà mai utilizzato come backbone in un gruppo di routing di Exchange 2003 per raggiungere un altro server Exchange 2007.

Introduzione del primo server di Exchange 2007
Durante l'installazione del primo server di Exchange 2007 nell'organizzazione di Exchange 2003, è necessario selezionare un server testa di ponte di Exchange 2003 con cui stabilire il primo connettore dei gruppi di routing.
Nella Figura 2 viene illustrato l'impatto dell'introduzione del primo server di Exchange 2007 sulla topologia dell'organizzazione.
Figura 2 Installazione del primo server di Exchange 2007
Figura 2 Installazione del primo server di Exchange 2007 (Fare clic sull'immagine per ridurla)
Figura 2 Installazione del primo server di Exchange 2007
Figura 2 Installazione del primo server di Exchange 2007 (Fare clic sull'immagine per ingrandirla)
Fin qui tutto bene. È bene sottolineare che il costo predefinito del connettore dei gruppi di routing creato da Exchange 2007 è solo pari a 1. La posta continua a fluire come sempre attraverso i server di Exchange 2003 e, se un messaggio viene inviato a un utente sul server di Exchange 2007 da qualsiasi server di Exchange 2003, tale messaggio passerà attraverso il gruppo di routing di Acapulco. Quando si è creato il connettore dei gruppi di routing, il server testa di ponte di Exchange 2003 selezionato è diventato automaticamente membro del gruppo di protezione universale ExchangeLegacyInterop e gli sono state concesse le autorizzazioni appropriate per la ricezione e l'invio di messaggi di posta elettronica da e verso Exchange 2007. Per creare un connettore di gruppi di routing ogniqualvolta un server di Exchange 2007 viene specificato come server di origine o di destinazione per il connettore, è necessario utilizzare sempre il cmdlet New-RoutingGroupConnector nell'Exchange Management Shell. È inoltre possibile utilizzare il cmdlet Set-RoutingGroupConnector per modificare la configurazione di un connettore di gruppi di routing. Per garantire ridondanza è consigliabile, ad esempio, aggiungere i server di origine e di destinazione al connettore di gruppi di routing iniziale. Per ulteriori informazioni, vedere l'articolo di David Strome sull'Exchange Management Shell in questo numero di TechNet Magazine.

Preparazione per lo spostamento di alcune cassette postali
Il passaggio successivo consiste nello spostamento di alcune cassette postali dai server di Exchange 2003 ai server di Exchange 2007. Per eseguire questa operazione, utilizzare il cmdlet Move-Mailbox. Per rimuovere le autorizzazioni dei server di Exchange 2003, tuttavia, è consigliabile creare connettori di invio e di ricezione sul server di Exchange 2007 che sostituiscano tutti i connettori SMTP definiti sul server di Exchange 2003 per gestire il routing verso spazi degli indirizzi SMTP esterni.
Nel diagramma successivo, le risorse del gruppo di routing di Acapulco sono state spostate in Exchange 2007. È possibile rimuovere le autorizzazioni del gruppo di routing di Acapulco ma, in tal caso, sarà necessario stabilire un connettore di gruppi di routing con un gruppo di routing differente. Nella Figura 3 il connettore dei gruppi di routing è stato configurato su un server testa di ponte nel gruppo di routing di Miami Nord.
Figura 3 Configurazione del connettore dei gruppi di routing
Figura 3 Configurazione del connettore dei gruppi di routing (Fare clic sull'immagine per ridurla)
Figura 3 Configurazione del connettore dei gruppi di routing
Figura 3 Configurazione del connettore dei gruppi di routing (Fare clic sull'immagine per ingrandirla)
A questo punto, è possibile esaminare la transizione dal gruppo di routing LA est a Exchange 2007. Questo è il tipo di situazione in cui la gestione del routing diventa leggermente più complicata. Nella Figura 4 Exchange 2007 è stato installato nel sito di Los Angeles e si è eseguita la rimozione delle autorizzazioni di un secondo gruppo di routing, ma non è stato creato alcun connettore dei gruppi di routing aggiuntivo.
Figura 4 Exchange 2007 installato nel sito di Los Angeles
Figura 4 Exchange 2007 installato nel sito di Los Angeles (Fare clic sull'immagine per ridurla)
Figura 4 Exchange 2007 installato nel sito di Los Angeles
Figura 4 Exchange 2007 installato nel sito di Los Angeles (Fare clic sull'immagine per ingrandirla)
Se un messaggio viene inviato dal server di Exchange 2007 nel sito di Los Angeles al server di Exchange 2003 nel gruppo di routing di LA ovest, tale messaggio verrà inoltrato prima ad Acapulco, successivamente a Miami Nord, quindi a Miami Sud e infine a LA ovest. Se un messaggio viene inviato dal server di Exchange 2003 nel gruppo di routing di LA ovest al server di Exchange 2007 nel sito di Los Angeles, tale messaggio verrà inoltrato prima a Miami Sud, successivamente a Miami Nord, quindi ad Acapulco e infine di nuovo a Los Angeles. Questo è un problema.
Per evitare una situazione del genere, è necessario aggiungere un secondo connettore dei gruppi di routing. Nella Figura 5 viene illustrata l'aggiunta di un connettore dei gruppo di routing da LA ovest al server di Exchange 2007 nel sito di Los Angeles. Nota: per evitare l'aggiunta di un numero eccessivo di connettori dei gruppi di routing, accertarsi che il primo connettore dei gruppi di routing venga configurato in un sito hub di Active Directory ben collegato.
Figura 5 Routing più efficiente
Figura 5 Routing più efficiente (Fare clic sull'immagine per ridurla)
Figura 5 Routing più efficiente
Figura 5 Routing più efficiente (Fare clic sull'immagine per ingrandirla)
Viene così introdotto un problema che potrebbe non essere immediatamente evidente. Ora sono disponibili più percorsi verso e dal gruppo di routing di Exchange 2007. Il gruppo di routing di Exchange 2007 non utilizza lo stato dei collegamenti, creando pertanto una condizione potenziale di loop di routing. Se un connettore non è disponibile, Exchange 2003 potrebbe selezionare una route alternativa, mentre Exchange 2007 selezionerà sempre la route con il costo più basso. Per aggirare questo problema, è necessario eliminare i messaggi relativi agli aggiornamenti secondari dello stato dei collegamenti, il che impedirà la trasmissione di messaggi dello stato dei collegamenti che indicano lo stato di non disponibilità di un connettore ma non impedirà la comunicazione dei messaggi dello stato dei collegamenti che indicano modifiche di configurazione. Questa configurazione è importante se si desidera che i server di Exchange 2003 rilevino i nuovi connettori dei gruppi di routing ma non si desidera che tali server calcolino una route alternativa. Il risultato finale è che i server di Exchange 2003 presentano lo stesso comportamento dei server di Exchange 2007 definito "coda nel punto di errore".
Nella Figura 6 viene illustrata la transizione di più risorse di Exchange 2003 a Exchange 2007. Gli aggiornamenti dello stato dei collegamenti sono stati eliminati ed è stata posta particolare attenzione nello stabilire connettori di gruppi di routing che mantengano un percorso di routing logico.
Figura 6 Spostamento di più risorse di Exchange 2003 in Exchange 2007
Figura 6 Spostamento di più risorse di Exchange 2003 in Exchange 2007 (Fare clic sull'immagine per ridurla)
Figura 6 Spostamento di più risorse di Exchange 2003 in Exchange 2007
Figura 6 Spostamento di più risorse di Exchange 2003 in Exchange 2007 (Fare clic sull'immagine per ingrandirla)
Esiste tuttavia un altro problema. A Redmond e a Vancouver sono state create isole di dati sullo stato dei collegamenti. Lo scambio della posta elettronica avviene in modo corretto, sebbene solo all'interno di Miami, in quanto non è possibile in alcun modo garantire la comunicazione tra Redmond e Miami di messaggi relativi alle modifiche della configurazione dello stato dei collegamenti. Per disporre di una tabella di routing aggiornata, è necessario configurare un altro connettore di gruppi di routing tra Redmond e Vancouver. È possibile modificare il costo di questo connettore dei gruppi di routing in modo che sia sufficientemente alto per impedire che in Exchange 2003 venga eseguito il routing tramite la connessione, consentendo nel contempo la comunicazione delle modifiche della configurazione dello stato dei collegamenti.
Con un'attenta pianificazione, è possibile aggirare i problemi associati alla gestione di due topologie di routing di Exchange separate. I risultati più trasparenti si potranno ottenere eseguendo la transizione di un singolo gruppo di routing per volta fino a quando si eseguono solo server di Exchange 2007.
Finora si è focalizzato l'attenzione sulle modifiche di routing in Exchange 2007 e si è illustrato l'impatto di tali modifiche sul processo di transizione. Occorre tenere presente un altro paio di considerazioni durante la pianificazione della transizione a Exchange 2007.
I server front-end di Exchange 2003 non sono in grado di accedere alle cassette postali di Exchange 2007. Un server Accesso client di Exchange 2007 è tuttavia in grado di connettersi senza problemi alla cassetta postale di Exchange 2003. Quando si utilizza il server Accesso client di Exchange 2007, viene visualizzata la stessa versione di OWA del server Cassette postali in cui è archiviata la propria cassetta postale. Se si esegue la distribuzione di Exchange 2007 su hardware separato, il primo ruolo del server che è consigliabile inserire in un sito di Active Directory è il server Accesso client. Prima di eseguire lo spostamento di eventuali cassette postali in Exchange 2007, è consigliabile che tutti i server front-end di Exchange 2003 che forniscono accesso Internet pubblico alle cassette postali vengano sostituiti con i server Accesso client di Exchange 2007.
In precedenza si è visto che ogni sito che contiene il ruolo del server Cassette postali richiede anche il ruolo del server Accesso client (se si dispone di client non MAPI) e del ruolo del server Trasporto hub. Se pertanto si prevede di utilizzare ruoli del server configurati per la condivisione dell'hardware, accertarsi di includere il server Accesso client nella selezione dei ruoli. Un'installazione tipica non prevede l'inclusione dei ruoli del server Trasporto hub, Accesso client e Cassette postali, ovvero tutti i ruoli necessari a garantire la completa operatività di un ambiente Exchange.
Un altro aspetto da prendere in considerazione nel processo di transizione riguarda il momento in cui aggiornare l'applicazione client (Outlook). Non è possibile infatti sfruttare appieno tutte le funzionalità dei server di Exchange 2007 se non si esegue l'aggiornamento dei client in uso a Outlook 2007. Tra tali funzionalità sono incluse le impostazioni avanzate per i messaggi di fuori sede e le funzioni gestite delle cartelle delle cassette postali.
È necessario inoltre stabilire quando distribuire il ruolo del server Trasporto edge. Dal punto di vista tecnico, è possibile sostituire host di inoltro SMTP e smart host della rete perimetrale con il server Trasporto edge prima o dopo l'introduzione di eventuali altri ruoli del server di Exchange 2007. Se tuttavia si distribuisce prima il server Trasporto edge, le funzionalità globali verranno limitate in quanto Exchange 2003 non prevede alcun metodo per replicare i dati di configurazione e dei destinatari di cui il server Trasporto edge necessita da Active Directory in ADAM (Active Directory Application Mode).
Una volta installato almeno un server Trasporto hub, è possibile distribuire il server Trasporto edge nella rete perimetrale ed eseguire la sottoscrizione del server Trasporto edge al sito di Active Directory in cui risiede il server Trasporto hub. Il servizio EdgeSync sul server Trasporto hub replicherà un sottoinsieme dei dati dei destinatari da Active Directory in ADAM.
Questi dati consentono al server Trasporto edge di eseguire la ricerca dei destinatari e l'aggregazione di elenchi di indirizzi attendibili in modo che sia possibile utilizzare gli agenti di protezione da posta indesiderata in esecuzione sul server Trasporto edge. EdgeSync creerà inoltre i connettori di invio necessari per il flusso della posta end-to-end da e verso l'organizzazione di Exchange e Internet. In tal modo si semplifica il processo di sostituzione dei connettori SMTP di Exchange 2003 che rendono possibile il routing verso spazi di indirizzi esterni.
Una pianificazione meticolosa, dunque, può costituire la differenza tra un processo di transizione a Exchange 2007 senza problemi e uno difficile e tortuoso.

Kate Follis ricopre la posizione di Senior Content Publisher nel team addetto alla redazione dei testi tecnici per Exchange 2007. Il gruppo di cui fa parte è specializzato nei ruoli del server Trasporto edge e Trasporto hub. Prima di iniziare il suo rapporto di lavoro con Microsoft, Kate ha lavorato come Microsoft Certified Trainer per diversi anni, tenendo corsi su Exchange e Active Directory.
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 Exchange Server 2007: Prendere il comando con l'Exchange Management Shell
Exchange Server 2007 David Strome

Prendere il comando con l'Exchange Management Shell
Panoramica:
  • Funzionamento dell'Exchange Management Shell
  • Utilizzo dei cmdlet
  • Differenze tra cmdlet e comandi

Gli amministratori di ambienti Exchange hanno di certo già sentito parlare della nuova interfaccia a riga di comando di Exchange Server 2007, denominata Exchange Management Shell. Derivata dalla tecnologia Microsoft Windows PowerShell, l'Exchange
Management Shell è una potente interfaccia per la gestione di qualsiasi aspetto di Exchange Server 2007 da una riga di comando. Consente infatti di interagire direttamente con l'Exchange Management Shell, scrivere script per l'automazione delle operazioni o integrare le applicazioni già esistenti con il modulo sottostante. Nella Figura 1 è illustrata la shell al lavoro.
Figura 1 L'Exchange Management Shell
Figura 1 L'Exchange Management Shell (Fare clic sull'immagine per ridurla)
Figura 1 L'Exchange Management Shell
Figura 1 L'Exchange Management Shell (Fare clic sull'immagine per ingrandirla)
Con l'Exchange Management Console non si utilizza l'Exchange Management Shell per l'esecuzione delle operazioni, ma nelle procedure guidate vengono mostrati i comandi in esecuzione. È sufficiente copiare i comandi creati dalla procedura guidata e incollarli direttamente nella riga di comando o in uno script. Dopo aver modificato i parametri secondo necessità, è possibile sottoporre a test gli script o i comandi utilizzando il parametro WhatIf, che consente di visualizzare i risultati prima di apportare modifiche all'ambiente.
L'Exchange Management Shell costituisce una piattaforma di scripting solida e flessibile da integrare con le soluzioni di scripting giù in uso e consente di comunicare in modo nativo con origini dati come COM e Strumentazione gestione Windows (WMI). Per l'Exchange Management Shell, basata su .NET Framework, si utilizzano i cmdlet, l'unità di funzionalità più piccola dell'Exchange Management Shell, per accettare e restituire dati strutturati invece di testo semplice. I cmdlet verranno analizzati in maggior dettaglio in seguito.

Snap-in di Windows PowerShell
Il primo passo per la comprensione del funzionamento dell'Exchange Management Shell è l'analisi delle relazioni con Windows PowerShell™, una nuova interfaccia a riga di comando potente e flessibile basata su .NET Framework in cui si combinano le migliori funzionalità di altre shell con molte nuove e utili funzioni. Windows PowerShell è stato progettato in modo da costituire un host per altre applicazioni, come già Microsoft Management Console (MMC) agisce da host per i vari snap-in forniti con le applicazioni. Exchange Management Shell è il primo snap-in di Windows PowerShell realizzato.
Gli snap-in sono raccolte di cmdlet utilizzati per l'amministrazione di un'applicazione o di un componente principale. Non è possibile utilizzarli senza prima caricarli. È, per fortuna, molto facile avviare lo snap-in Exchange Management Shell, ma prima di considerare questo aspetto è necessario spiegare alcuni concetti chiave da comprendere per un corretto utilizzo dell'Exchange Management Shell.
I cmdlet sono simili ai comandi incorporati di altre shell, ad esempio, il comando dir in cmd.exe. Come i comandi già noti di cmd.exe, i cmdlet possono essere chiamati dalla riga di comando nell'Exchange Management Shell ed eseguiti nel contesto della shell e non come processi separati. A differenza dei comandi delle altre shell, i nomi dei cmdlet sono una combinazione descrittiva di verbo-nome. Il verbo descrive l'azione eseguita dal cmdlet, mentre il nome descrive il componente o la funzione su cui agisce.
Non è necessario tirare a indovinare sulla funzione di un cmdlet. Quando si legge Move-Mailbox, si intuisce subito l'operazione che viene eseguita da questo cmdlet.
Per ulteriori informazioni sulle differenze tra cmdlet e comandi normali, leggere il riquadro "Differenze tra cmdlet e comandi", tratto dalla sezione dedicata a .NET Framework 3.0 del SDK di Windows® e consultabile all'indirizzo windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx (in inglese).
Parametro posizionale Identity È possibile utilizzare il parametro Identity in quasi tutti i cmdlet correlati a Exchange. Il parametro consente di accedere agli identificativi univoci che si riferiscono a un particolare oggetto di Exchange Server 2007, in modo che sia possibile eseguire delle azioni su un oggetto Exchange specifico impostando il valore desiderato.
In Identity si raccolgono valori di altri parametri univoci entro l'intero insieme di oggetti. È possibile specificare i valori di questi altri parametri, ad esempio per Name e DistinguishedName, oppure lasciare che vengano generati dal sistema, come per il GUID. Gli eventuali parametri aggiuntivi utilizzati e le modalità di compilazione dipendono dall'oggetto a cui si fa riferimento.
Il parametro Identity viene inoltre considerato un parametro posizionale, ovvero un parametro che consente di specificare il valore senza la necessità di specificare il nome. Un parametro viene considerato posizionale quando l'attributo Parameter Position è un numero intero. Il numero intero indica la posizione nella riga di comando in cui il cmdlet trova il valore del parametro. Poiché Identity è un parametro posizionale che risiede nella posizione 0, ovvero nella prima posizione, gli eventuali valori immessi in questa posizione senza nome del parametro vengono considerati valori del parametro Identity. Il numero di digitazioni necessarie per la scrittura dei comandi viene così drasticamente ridotto. Ad esempio
Get-Mailbox –Identity "Kim Akers"
esegue la medesima azione di:
Get-Mailbox "Kim Akers"
Pipelining Il pipelining nell'Exchange Management Shell avviene quando un cmdlet utilizza l'output di un altro cmdlet per eseguire un'operazione. Il pipelining viene specificato nei comandi con il simbolo pipe "|". L'utilizzo di informazioni ottenute con un altro comando e passate tramite pipe è consentito con tutti i verbi del medesimo insieme nome-cmdlet. Alcuni insiemi di nome-cmdlet consentono inoltre di passare i dati tramite pipeline a un altro insieme nome-cmdlet.
L'utilizzo del pipelining per correlare le azioni di due o più cmdlet consente di assumere piccoli componenti e convertirli in comandi o script più complessi. È possibile, ad esempio, utilizzare un cmdlet per raccogliere dati, passare i dati raccolti a un secondo cmdlet che applica un filtro per selezionarne solo una parte e, infine, passare i dati selezionati a un terzo cmdlet che esegue un'operazione sui dati selezionati.

Avvio dell'Exchange Management Shell
La modalità più semplice di avvio della shell consiste nel fare clic su Start, Programmi, Microsoft Exchange Server 2007 e infine su Exchange Management Shell.
È tuttavia possibile caricare manualmente lo snap-in Exchange Management Shell da una sessione di Windows PowerShell. Fare clic su Start, Programmi e Windows PowerShell. Dopo l'avvio, caricare Exchange Management Shell eseguendo il comando:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Esistono alcune differenze tra il caricamento dello snap-in Exchange Management Shell dal menu Programmi o tramite il cmdlet Add-PSSnapin. Quando si utilizza il menu Programmi, non viene caricato solo lo snap-in Exchange Management Shell, ma anche uno script di Windows PowerShell per l'impostazione di un ambiente di amministrazione di Exchange personalizzato. Per configurare un ambiente di amministrazione simile dopo il caricamento manuale di Exchange Management Shell, è necessario passare alla directory di installazione bin di Exchange, ad esempio C:\Programmi\Microsoft\Exchange Server\Bin, ed eseguire il comando:
.\Exchange.ps1
Per un esempio di personalizzazione dell'ambiente Windows PowerShell, vedere lo script Exchange.ps1. Quando si carica l'Exchange Management Shell, il risultato sarà simile alla Figura 2.
Figura 2 Schermata iniziale di Exchange Management Shell
Figura 2 Schermata iniziale di Exchange Management Shell (Fare clic sull'immagine per ridurla)
Figura 2 Schermata iniziale di Exchange Management Shell
Figura 2 Schermata iniziale di Exchange Management Shell (Fare clic sull'immagine per ingrandirla)

Prime operazioni
Poiché nella shell è disponibile un'ampia gamma di cmdlet, il cmdlet Get-Help e il file della Guida di Exchange Server 2007 sono risorse preziose. Nella sezione Operazioni del file della Guida di Exchange Server 2007 sono disponibili moltissime procedure illustrate per le attività di amministrazione più comuni.
Quando si digita Get-Help, si ottengono informazioni di carattere generale su come accedere alle informazioni della Guida. Per ottenere informazioni su un cmdlet specifico, digitare Get-Help seguito dal cmdlet desiderato. È possibile controllare le informazioni visualizzate utilizzando i parametri Detailed, Full ed Example. È sufficiente aggiungerli alla fine del comando. Con Get-Help nome cmdlet –Full, ad esempio, si ottengono tutte le sezioni della Guida disponibili per il cmdlet.
Per recuperare informazioni su uno o più parametri specifici di un cmdlet, è possibile aggiungere a Get-Help il parametro Parameters. Quando, ad esempio, si desidera visualizzare tutti i parametri e le relative descrizioni per il cmdlet Set-Mailbox che contengano la parola "quota", è possibile utilizzare il comando:
Get-Help Set-Mailbox –Parameter *quota*
È inoltre possibile visualizzare un elenco dei cmdlet che consentono di gestire un ruolo del server o una funzionalità del componente specifica oppure che influiscono sugli oggetti di un determinato ambito o funzionalità. Il cmdlet Get-Help consente di eseguire queste operazioni con tre parametri: Role, Component e Functionality. Quando si utilizza il cmdlet Get-Help con questi parametri, è necessario inserire i valori specificati dai parametri tra caratteri jolly "*". I seguenti sono esempi dell'utilizzo di Get-Help con ciascuno dei tre parametri:
Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*
Per ulteriori informazioni, consultare l'argomento sull'utilizzo della Guida in linea del file della Guida di Exchange Server 2007 dove è possibile trovare un elenco di tutti i valori di ruoli, componenti e funzionalità che è possibile utilizzare.

Formattazione dell'output dei comandi
Per impostazione predefinita, quando l'output viene visualizzato sullo schermo, nell'Exchange Management Shell viene visualizzata solo una parte delle proprietà disponibili per ciascun oggetto. È tuttavia possibile accedere a tutte le proprietà passando tramite pipeline l'output di un comando ai tre seguenti cmdlet di formattazione: Format-List, Format-Table e Format-Wide. Si esamineranno qui Format-List e Format-Table, che sono di utilizzo più frequente.
Quando si passa l'input dalla pipeline al cmdlet Format-List, si ottiene come output un elenco in colonne verticali con tutte le proprietà specificate di ciascun oggetto. È possibile specificare le proprietà che si desidera visualizzare utilizzando il parametro Property (anche il parametro Property, tuttavia, è un parametro posizionale, quindi è sufficiente specificare solo i valori senza il nome del parametro). Se il cmdlet Format-List viene chiamato senza specificare alcun parametro, nell'output saranno visualizzate tutte le proprietà. Nell'output del cmdlet si utilizza il ritorno a capo del testo delle righe, senza troncamenti. Format-List è particolarmente utile quando si desidera sostituire l'output predefinito di un cmdlet per recuperare informazioni aggiuntive o più dettagliate. Ad esempio,
Get-DistributionGroup | Format-List Name, *OnlyFrom,
PrimarySmtpAddress, *Size*
Nella Figura 3 è illustrato l'output di questo comando.
Figura 3 Esempio di output di Format-List
Figura 3 Esempio di output di Format-List (Fare clic sull'immagine per ridurla)
Figura 3 Esempio di output di Format-List
Figura 3 Esempio di output di Format-List (Fare clic sull'immagine per ingrandirla)
Il cmdlet Format-Table consente di visualizzare l'output in una tabella, completa di intestazioni e colonne di dati delle proprietà. Per impostazione predefinita, per molti cmdlet, come Get-Mailbox e Get-JournalRule, è previsto un output in formato tabellare. Tra i parametri del cmdlet Format-Table è opportuno segnalare Properties e GroupBy. Il funzionamento di questi parametri è identico a quello illustrato per il cmdlet Format-List. Per ottenere la visualizzazione completa delle informazioni delle righe più lunghe senza troncamenti, è possibile utilizzare il parametro Wrap nel modo seguente:
Get-Mailbox –Database Research | Format-Table Name,
ProhibitSendQuota, Database –Wrap
L'output è riportato nella Figura 4.
Figura 4 Esempio di output di Format-Table
Figura 4 Esempio di output di Format-Table (Fare clic sull'immagine per ridurla)
Figura 4 Esempio di output di Format-Table
Figura 4 Esempio di output di Format-Table (Fare clic sull'immagine per ingrandirla)
Se si inserisce un carattere jolly, sarà possibile specificare più proprietà senza digitarne singolarmente il nome. Con il comando seguente, ad esempio, si ottengono tutte le proprietà che iniziano per E-mail:
Get-Mailbox | Format-List Email*

Esercitazioni
Ora che si sono apprese le funzionalità di alcuni comandi di base, è possibile esercitarsi con gli esempi riportati di seguito, che dimostrano la potenza e la flessibilità dell'Exchange Management Shell e consentono di fare un po' di pratica.
Con il primo comando si creeranno 10 utenti, con nomi da User1 a User10:
1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD
/Domain; Enable-Mailbox "User$_" -Database "Mailbox
Database" }
Esaminiamo le diverse parti dello script. Con il comando 1.0 si ottiene come output la serie di numeri interi da 1 a 10 che viene quindi passata tramite pipeline al cmdlet ForEach. L'applicazione del cmdlet ForEach a ciascun oggetto ricevuto consente di eseguire i comandi compresi tra parentesi graffe { } per ciascuno degli oggetti. Con il comando Net User si crea un nuovo utente del dominio, mentre con il cmdlet Enable-Mailbox si crea una nuova cassetta postale nel "Mailbox Database" del server locale. Un punto e virgola separa i due comandi, in modo che sia possibile inserirli nella stessa riga. $_ è una variabile speciale che contiene il valore dell'oggetto corrente nella pipeline. Nell'esempio la variabile $_ contiene il numero intero corrente nella pipeline.
Nell'esempio successivo sarà possibile visualizzare le cassette postali residenti sul server MBX e ottenere nome, database delle cassette postali e quota per ciascuna cassetta postale.
Get-Mailbox –Server MBX | Format-Table
Name,Database,*quota*
Con il cmdlet Get-Mailbox si ottiene ciascuna cassetta postale specificata con il parametro Server, quindi gli oggetti cassette postali dell'output vengono passati tramite pipeline al cmdlet Format-Table. Per impostazione predefinita, con il cmdlet Format-Table si visualizzano tutte le proprietà restituite da un cmdlet, a meno che non si specifichino le proprietà da visualizzare. In questo caso sono state richieste solo le proprietà Name e Database, oltre a tutte le proprietà che contengono la stringa "quota". Nella Figura 5 è mostrato il possibile aspetto dell'output.
Figura 5 Output del comando Get-Mailbox
Figura 5 Output del comando Get-Mailbox (Fare clic sull'immagine per ridurla)
Figura 5 Output del comando Get-Mailbox
Figura 5 Output del comando Get-Mailbox (Fare clic sull'immagine per ingrandirla)
Con l'esempio si imposta il limite della quota di invio a 600 MB per tutti gli utenti con la posta elettronica abilitata dell'intera organizzazione con la parola "Manager" compresa nel titolo.
Get-User –Filter { Title –Like "*Manager*"}
–RecipientTypeDetails UserMailbox | Set-Mailbox
–ProhibitSendQuota 600MB
Se eseguito da solo, il cmdlet Get-User restituisce tutti gli oggetti utente in Active Directory, compresi gli utenti con la cassetta postale non abilitata. Per recuperare solo l'insieme di oggetti utente da passare al cmdlet Set-Mailbox, è necessario specificare che con il cmdlet Get-User si intende estrarre solo gli oggetti utente Active Directory che sono utenti di posta abilitati. Il parametro RecipientTypeDetails consente di specificare il tipo di destinatario di Active Directory, in questo caso, UserMailbox. Quindi è necessario recuperare l'insieme di utenti Manager con la posta abilitata. Nell'esempio la proprietà Title di ciascun oggetto utente di Active Directory è compilata. È possibile utilizzare questo valore per determinare quali utenti sono manager impostando il parametro Filter, con cui si richiede al server di restituire solo gli oggetti Active Directory che corrispondono ai criteri specificati. Questa operazione viene definita filtraggio sul lato server. L'insieme di oggetti ottenuto viene quindi passato al cmdlet Set-Mailbox, con cui si imposta a 600 MB la proprietà ProhibitSendQuota per ciascuna cassetta postale.
A questo punto è possibile analizzare il risultato di un comando che consente di eseguire un test di rimozione di tutte le cassette postali membri di un gruppo di distribuzione. Ecco il comando:
Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf
Con il primo cmdlet si recuperano gli oggetti destinatario membri del gruppo di distribuzione Fourth Year Students. Quindi si passano al cmdlet Remove-Mailbox solo gli oggetti destinatario che corrispondono al RecipientType "UserMailbox". Invece di rimuovere direttamente le cassette postali, si utilizza il cmdlet Remove-Mailbox per visualizzare l'azione che verrebbe eseguita e gli oggetti a cui verrebbe applicata l'azione. Con il cmdlet Get-DistributionGroupMember si recupera l'elenco di tutti gli oggetti destinatario membri del gruppo di distribuzione "Fourth Year Students". Poiché, tuttavia, il cmdlet Remove-Mailbox è applicabile solo agli utenti con la posta abilitata, è necessario filtrare ed escludere tutti i tipi di destinatario, tranne "UserMailbox". A differenza di altri cmdlet, il cmdlet Get-DistributionGroupMember non prevede un parametro Filter ed è quindi necessario procedere al filtraggio sul lato server. Per i cmdlet che non consentono di eseguire il filtraggio sul lato server (perché non se ne vedono i vantaggi in termini di prestazioni), è possibile utilizzare a tale scopo il cmdlet Where, che consente di recuperare tutti gli oggetti e applicare il filtro sul computer client locale. Con il cmdlet Where è possibile estrarre solo gli oggetti che corrispondono ai criteri specificati. Al cmdlet Remove-Mailbox vengono passati solo gli oggetti che corrispondono al RecipientType "UserMailbox". Con questo cmdlet si rimuove l'oggetto utente di Active Directory e si contrassegna la cassetta postale per la rimozione. Quando si utilizza il parametro WhatIf, con il cmdlet Remove-Mailbox si ottiene la visualizzazione di testo simile al seguente:
What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark
the mailbox in the database for removal.
Se si ritiene corretto il comportamento del comando, eseguire di nuovo il comando senza WhatIf. Per alcuni cmdlet, ad esempio tutti quelli con il verbo Remove, prima di apportare le modifiche nella shell viene automaticamente richiesta una conferma. È possibile scegliere di applicare una modifica per volta, evitare la visualizzazione di altre richieste di conferma o annullare tutte le elaborazioni seguenti. Per i cmdlet che non prevedono una richiesta di conferma automatica, è possibile forzare la richiesta di conferma con il comando Confirm.

Conclusioni
Ora che si è toccata con mano la potenza dei cmdlet, è possibile continuare a sperimentare per rendersi conto quanto possono essere utili l'Exchange Management Shell e Microsoft Windows PowerShell per le attività di gestione dei sistemi. Per ulteriori informazioni su questi argomenti, è possibile consultare le risorse indicate di seguito. Per l'Exchange Management Shell, vedere il file della Guida di Exchange Server 2007 all'indirizzo go.microsoft.com/fwlink/?LinkId=69434 (in inglese), lo scripting center di Windows Powershell all'indirizzo go.microsoft.com/fwlink/?LinkId=71134 (in inglese) e il blog del team di Exchange all'indirizzo msexchangeteam.com (in inglese).

David Strome è Technical Writer del gruppo Exchange User Education presso Microsoft da oltre un anno. Prima dell'assunzione in Microsoft a Redmond, WA, David ha lavorato per circa 10 anni alla progettazione, implementazione e amministrazione di installazioni di Exchange Server per molte aziende in British Columbia, Canada. È possibile contattare David scrivendo all'indirizzo dstrome@microsoft.com.


 Exchange Server 2007: Exchange &amp; Outlook: meglio insieme
Exchange Server 2007 Michael Khalili

Exchange & Outlook: meglio insieme
Panoramica:
  • Installazione semplificata
  • Integrazione di voce, fax e posta elettronica
  • Cartelle gestite per la conformità

Da molti anni ormai, Microsoft Exchange Server e Outlook costituiscono un sistema di posta elettronica affidabile per milioni di utenti, facilitando la collaborazione, la gestione dei calendari e l'organizzazione dei contatti. Cosa si può chiedere ancora a un'accoppiata così formidabile? Semplice, presto verranno rilasciati Exchange Server 2007
e Microsoft Office Outlook 2007, che utilizzati insieme consentiranno di fare l'ennesimo salto di qualità nei territori di comunicazione e collaborazione.
I miglioramenti apportati a Exchange Server 2007 e Office Outlook® 2007 sono evidenti fin dal primo avvio del client Outlook. Nelle versioni precedenti si presupponeva che l'utente di Outlook già conoscesse il nome del server per cassette postali di Exchange, comportamento che ha messo in difficoltà molti utenti. Ne risultavano chiamate frequenti al supporto tecnico o complessi script di inizializzazione, con un conseguente aumento in entrambi i casi di costi e complessità dell'ambiente di messaggistica. Grazie al nuovo servizio Web di individuazione automatica per Exchange, Outlook consente di configurare in modo automatico l'account quando il client è unito al dominio. Se il client non è unito al dominio, l'utente dovrà solo immettere un nome, un indirizzo di posta elettronica e una password. Outlook ed Exchange imposteranno gli altri parametri in modo automatico (vedere la Figura 1).
Figura 1 Impostazione dell'account
Figura 1 Impostazione dell'account (Fare clic sull'immagine per ridurla)
Figura 1 Impostazione dell'account
Figura 1 Impostazione dell'account (Fare clic sull'immagine per ingrandirla)
Allo stesso modo, fino a qualche tempo fa, gli utenti dovevano non solo impostare Outlook per l'utilizzo iniziale, ma anche riconfigurarlo ogni volta che avveniva uno spostamento su un altro server di posta. Anche nei casi in cui l'imminente migrazione verso un'altra cassetta postale era preceduta da un messaggio di posta elettronica di avviso, gli utenti più occupati non prestavano particolare attenzione all'evento, almeno fino a quando un bel mattino si rendevano conto di non poter più utilizzare Outlook. Situazione che generava, ovviamente, ulteriori chiamate al supporto tecnico. I servizi Web di individuazione automatica per Exchange risolvono anche questo problema. Quando un utente viene spostato da un server a un altro, in Outlook viene immediatamente rilevata l'invalidità della configurazione precedente, viene eseguita una nuova query nel servizio Web di individuazione automatica e viene riconfigurato il client per la nuova cassetta postale. L'intero processo è completamente trasparente per l'utente finale.

Il calendario reinventato
In passato la gran parte della logica del calendario risiedeva in Outlook. L'aggiornamento di ciascuna riunione era trattato come una nuova convocazione di riunione, vale a dire che era possibile accettare le notifiche nell'ordine errato. Quando venivano inviati due aggiornamenti in rapida successione e un destinatario accettava il secondo aggiornamento prima del primo, nel calendario erano visualizzate informazioni non aggiornate. L'accesso ai dati di Outlook da Smartphone o PDA, inoltre, poteva evidenziare differenze nelle informazioni sullo stato di libero/occupato dell'utente, in base al metodo di visualizzazione dei dati.
Una possibile soluzione consisteva nello spostare la logica del calendario dal client Outlook a Exchange Server 2007. Quando il server riceve la convocazione di una riunione, la riunione viene automaticamente inserita in calendario come provvisoria fino a quando l'utente non decide di accettare o rifiutare l'appuntamento. Quando invece il server riceve una modifica dell'ora o del luogo della riunione, questa viene automaticamente aggiornata mentre la convocazione precedente viene contrassegnata come non aggiornata, in modo che gli utenti non possano inavvertitamente accettarla. Questa logica è coerente in tutti i client, Office Outlook, Outlook Web Access, Outlook Mobile o altri client di terze parti e consente di visualizzare solo le riunioni corrette e più aggiornate.
Con un calendario così preciso e affidabile, è possibile offrire una nuova serie di strumenti che consenta agli utenti di raggiungere nuovi livelli di produttività. Prima non era facile pianificare riunioni con più dipendenti occupati. Gli utenti dovevano trovare manualmente le ore libere, consultando le informazioni di intere giornate e individuando un orario accettabile per tutti i partecipanti. Con Regole Pianificazione di Outlook 2007, nella Figura 2, è possibile trovare automaticamente l'ora più adatta per tutti i partecipanti. Dopo aver immesso i partecipanti necessari e facoltativi e le eventuali sale o risorse, con Regole Pianificazione viene visualizzata una schermata con una codifica a colori dei giorni più adatti per una riunione. Dopo la scelta del giorno, viene impiegato il medesimo schema per l'individuazione dell'ora migliore all'interno del giorno indicato.
Figura 2 Regole Pianificazione
Figura 2 Regole Pianificazione (Fare clic sull'immagine per ridurla)
Figura 2 Regole Pianificazione
Figura 2 Regole Pianificazione (Fare clic sull'immagine per ingrandirla)
Per determinare l'ora ottimale per una riunione, in Regole Pianificazione viene attribuita la priorità più alta ai partecipanti necessari, quindi ai partecipanti facoltativi e infine a sale e risorse. In Regole Pianificazione vengono inoltre affrontati e risolti i problemi relativi a orari di lavoro flessibili e fusi orari diversi. Gli utenti possono impostare il proprio orario lavorativo, definendo l'ora di arrivo al mattino e l'ora di uscita alla fine della giornata. Gli eventuali dormiglioni, quindi, che arrivano sul posto di lavoro non prima delle 9 o delle 10 del mattino, possono impostare l'inizio delle giornata lavorativa di conseguenza. Se si presenta la necessità di pianificare una riunione con la partecipazione di uno di questi utenti, tra gli orari consigliati non saranno riportate le 8 del mattino. Se si tenta di pianificare una riunione per due gruppi che lavorano in fusi orari diversi (ad esempio, uno a Londra e uno a Los Angeles), tra gli orari consigliati saranno indicate solo le ore lavorative che si sovrappongono tra i due fusi. Il gruppo di Londra si troverà una riunione pianificata per il tardo pomeriggio, mentre il gruppo di Los Angeles dovrà prepararsi a una riunione all'inizio della giornata lavorativa, ma nessuno si vedrà pianificare una riunione per le 2 di notte.

Come trovare un ago in un pagliaio
Nel corso degli anni il numero di messaggi ricevuti da un utente medio è cresciuto a ritmo vertiginoso. Se qualche tempo fa in una tipica cassetta postale aziendale era possibile trovare solo poche centinaia di messaggi, oggi alcuni singoli utenti ricevono la medesima quantità di messaggi in un solo giorno di lavoro. Sotto questa valanga di messaggi si nasconde un tesoro di informazioni importanti o fondamentali per il corretto funzionamento di qualsiasi azienda. Trovare le informazioni richieste quando necessario può diventare una vera sfida.
Le funzionalità di ricerca di Office Outlook 2007 ed Exchange Server 2007 sono molto migliorate rispetto alle versioni precedenti. Al messaggio vengono applicati gli stessi algoritmi di ricerca, sia che l'utente lavori nella modalità cache oppure in rete. Nella modalità in rete la query di ricerca viene inviata al server Exchange, dove la ricerca viene effettivamente eseguita. Per garantire individuazione e recupero rapidi dei messaggi, viene utilizzato l'indicizzatore del contenuto di Exchange, fino a 35 volte più veloce dell'indicizzatore di Exchange Server 2003. Nella modalità cache di Outlook è possibile utilizzare la funzione Ricerca immediata, basata su Windows® Desktop Search 3.0, che consolida i motori di indicizzazione e riduce il tempo di utilizzo della CPU. È possibile eseguire ricerche nel testo che si trova nel campo oggetto, nel corpo del messaggio, nei campi di mittente e destinatario o addirittura negli allegati, come illustrato nella Figura 3.
Figura 3 Nuove modalità di ricerca per i messaggi di posta elettronica
Figura 3 Nuove modalità di ricerca per i messaggi di posta elettronica (Fare clic sull'immagine per ridurla)
Figura 3 Nuove modalità di ricerca per i messaggi di posta elettronica
Figura 3 Nuove modalità di ricerca per i messaggi di posta elettronica (Fare clic sull'immagine per ingrandirla)

Accesso da qualsiasi luogo con la messaggistica unificata
Messaggistica unificata di Microsoft Exchange, un componente incorporato in Exchange Server 2007, consente di concentrare in una singola cartella Posta in arrivo tutti i tipi di comunicazione aziendale, ovvero messaggi di posta elettronica, messaggi vocali e fax. Nei sistemi tradizionali è possibile accedere ai messaggi vocali con un apparecchio telefonico, ai messaggi di posta elettronica con il computer e ai fax con un apparecchio fax dedicato. Messaggistica unificata di Microsoft Exchange consente agli utenti di scegliere il client più adatto in base alle proprie esigenze in un determinato momento o luogo. I messaggi vocali e fax vengono visualizzati all'interno di Outlook nella cartella Posta in arrivo, insieme i messaggi di posta elettronica. Il messaggio vocale selezionato contiene un riproduttore incorporato che consente di ascoltare il messaggio direttamente dal riquadro di lettura (vedere la Figura 4).
Figura 4 Riproduzione di messaggi vocali in Outlook
Figura 4 Riproduzione di messaggi vocali in Outlook (Fare clic sull'immagine per ridurla)
Figura 4 Riproduzione di messaggi vocali in Outlook
Figura 4 Riproduzione di messaggi vocali in Outlook (Fare clic sull'immagine per ingrandirla)
Outlook inoltre prevede una gestione contestuale dei messaggi. Quando si ascolta un messaggio vocale, in genere si annotano rapidamente i punti essenziali su un foglietto di carta. Queste note non vengono ovviamente associate al messaggio ed è probabile che vadano smarrite. Non sembra certo un efficace modello di comunicazione. Con Messaggistica unificata di Microsoft Exchange è possibile annotare le informazioni salienti direttamente in Outlook. Le note restano associate al messaggio e inserite negli indici del testo da includere nelle ricerche, restando sempre visualizzate nel contesto del messaggio vocale. Diventa quindi facile recuperare le note utilizzando la nuova funzionalità di ricerca di Exchange Server 2007 e Office Outlook 2007.
Con Outlook è inoltre possibile gestire varie opzioni dei messaggi vocali (vedere la Figura 5), con la possibilità da parte degli utenti di modificare il PIN (Personal Identification Number) della casella vocale direttamente dal client. Il ripristino del PIN è infatti una delle principali cause di chiamata al supporto tecnico per i messaggi vocali. Gli utenti possono chiedere dalle opzioni di Outlook la generazione e l'invio tramite posta elettronica di un nuovo PIN. Con il PIN ricevuto tramite posta elettronica, gli utenti possono accedere una sola volta all'interfaccia telefonica di Messaggistica unificata di Microsoft Exchange, ovvero Outlook Voice Access, e modificare il proprio PIN.
Figura 5 Nella funzione di messaggistica unificata è disponibile un'opzione per il ripristino del PIN
Figura 5 Nella funzione di messaggistica unificata è disponibile un'opzione per il ripristino del PIN (Fare clic sull'immagine per ridurla)
Figura 5 Nella funzione di messaggistica unificata è disponibile un'opzione per il ripristino del PIN
Figura 5 Nella funzione di messaggistica unificata è disponibile un'opzione per il ripristino del PIN (Fare clic sull'immagine per ingrandirla)

Protezione
Oggi gli ambienti di messaggistica delle organizzazioni sono esposte a molte minacce. La sinergia di Outlook ed Exchange consente di combattere tali minacce in modo più efficace. La posta indesiderata è solo una delle minacce più comuni e Office Outlook 2007 supporta Timbro posta elettronica Outlook, una nuova arma per combattere la posta indesiderata. In Outlook viene eseguito un piccolo problema di calcolo sulla posta elettronica in uscita e la risposta viene aggiunta in coda ai messaggi. In Exchange i risultati vengono controllati. Questi piccoli problemi di calcolo, se eseguiti uno per volta come accade in genere per la posta autorizzata, occupano una quantità ridotta di tempo di elaborazione della CPU. Nel caso invece del computer di un soggetto che invia contemporaneamente grandi quantità di posta indesiderata, il peso dell'elaborazione necessaria diventerebbe insopportabile. È dunque molto probabile che un messaggio dotato di Timbro posta elettronica Outlook sia posta autorizzata e in Exchange si tiene conto di questo fattore nel determinare la validità di ciascun messaggio di posta elettronica.
Oltre alle minacce già note, come la posta indesiderata, sono in via di definizione nuovi regimi normativi che modificheranno i requisiti dei sistemi di messaggistica. Le norme quali Sarbanes-Oxley, HIPPA e Basel II prescrivono regole molto rigorose per la conservazione e distruzione dei record. Per soddisfare le nuove esigenze che stanno emergendo, con Exchange e Outlook vengono presentate le Cartelle gestite. Tali cartelle vengono impostate da un amministratore per i messaggi di un determinato tipo. Gli utenti finali di Outlook visualizzano le cartelle con una descrizione del tipo di materiale che deve essere archiviato in ciascuna di queste (vedere la Figura 6). È inoltre possibile impostare delle regole di trasporto di Exchange per archiviare in modo automatico i messaggi nelle rispettive cartelle di competenza. I messaggi archiviati in una determinata Cartella gestita rispettano i criteri di archiviazione, conservazione e scadenza impostati per la cartella e vengono trattati, automaticamente, in modo del tutto conforme ai criteri dell'organizzazione.
Figura 6 Regole di conformità della posta elettronica applicate con le Cartelle gestite
Figura 6 Regole di conformità della posta elettronica applicate con le Cartelle gestite (Fare clic sull'immagine per ridurla)
Figura 6 Regole di conformità della posta elettronica applicate con le Cartelle gestite
Figura 6 Regole di conformità della posta elettronica applicate con le Cartelle gestite (Fare clic sull'immagine per ingrandirla)
Nonostante le migliori intenzioni, tuttavia, a volte si verificano delle violazioni delle conformità. In questi casi è assolutamente necessaria una rapida identificazione e risoluzione del problema. La nuova funzionalità di ricerca di Exchange diventa dunque uno strumento fondamentale per il rispetto della conformità, dal momento che consente di trovare rapidamente i messaggi che evidenziano le eventuali violazioni. È possibile eseguire ricerche su più cassette postali per rilevare e correggere le violazioni.

Gestione semplificata
Exchange Server 2007 e Office Outlook 2007, se utilizzati in combinazione, costituiscono un ambiente di messaggistica molto più efficace di qualsiasi precedente versione. Le comunicazioni vitali per l'attività di un'azienda vengono centralizzate e, fin dal primo utilizzo, è più facile trovare le informazioni desiderate, impostare i parametri e garantire protezione e conformità. Una sinergia che consente di raggiungere livelli di collaborazione e comunicazione senza precedenti.

Michael Khalili è Product Manager per Exchange Server, responsabile di accesso del client e messaggistica unificata. È anche responsabile, tra varie altre attività, dell'integrazione tra Outlook ed Exchange.


 Exchange Server 2007: Sempre in contatto con Exchange 2007
Exchange Server 2007 Joshua Trupin

Sempre in contatto con Exchange 2007
Panoramica:
  • Novità in Outlook Web Access
  • Messaggistica unificata in Exchange Server 2007
  • Protezione con ISA Server 2006

Solo alcuni anni fa le opzioni di comunicazione in linea erano poche. Si inviavano messaggi di posta elettronica tramite POP3 e SMTP, tutto molto semplice. Le esigenze cambiano con il passare del tempo e oggi per le organizzazioni è importante garantire ai propri dipendenti
la flessibilità necessaria per lavorare ovunque e in qualsiasi modo, con tutta la protezione del caso. In Microsoft® Exchange Server 2007 sono state integrate alcune funzioni che consentono di soddisfare queste esigenze, tra cui Microsoft Office Outlook® Web Access (OWA) e Messaggistica unificata. Nell'articolo vengono presi in esame questi due componenti chiave di Exchange Server 2007 e si dimostra come le nuove versioni siano molto più efficaci nella creazione di una piattaforma di comunicazione senza compromessi per le aziende di oggi.
OWA fa parte di Exchange fin dalla versione 5.5. A dire il vero, le prime versioni non erano molto funzionali. Rappresentavano una semplice risposta alla necessità di accedere a una cassetta postale Exchange tramite un browser Web, ma senza molte delle funzionalità caratteristiche di Outlook.
Con i miglioramenti della versione fornita con Exchange Server 2003, l'OWA ha iniziato ad apparire più ricco. L'accesso alla cassetta postale con il browser era molto più naturale e somigliava all'utilizzo di un normale programma client. OWA per Exchange Server 2007 rappresenta un ulteriore e decisivo passo avanti, grazie a una completa riscrittura delle versioni precedenti, e consente di sfruttare altre recenti innovazioni tecniche come RPC su HTTP e ASP.NET 2.0.
Basta prendere in considerazione, ad esempio, il nuovo rendering di OWA. Nelle versioni precedenti il rendering veniva eseguito dal server della cassetta postale, durante il processo di archiviazione. Questo ulteriore carico sul server cassette postali era causa potenziale di rallentamenti del sistema. Con Outlook Web Access 2007, invece, il rendering dei dati viene eseguito tramite ASP.NET, sui server Accesso client (CAS). In tal modo l'elaborazione della pagina non è più a carico del server cassette postali, con un conseguente miglioramento delle prestazioni.
Sono state modificate anche le operazioni eseguite sul front end. Nelle versioni precedenti di Exchange, le richieste HTTP di OWA venivano inoltrate come proxy al server postali appropriato. Con Exchange Server 2007 il traffico associato a OWA si riduce, perché i dati vengono recuperati direttamente dal server cassette postali appropriato tramite RPC. È più o meno lo stesso processo che consente di utilizzare Outlook su un client che non si trova su una connessione di rete privata virtuale (VPN) all'interno dell'azienda. Il rendering delle informazioni della cassetta postale viene eseguito da OWA. Con Exchange Server 2007 è inoltre possibile gestire come proxy le richieste di OWA, che in questo caso vengono inoltrate ai server CAS invece di essere inviate direttamente ai server cassette postali.
Nella Figura 1 viene illustrata l'architettura di OWA su Exchange Server 2007.
Figura 1 Accesso alle risorse di Exchange Server da parte di OWA
Figura 1 Accesso alle risorse di Exchange Server da parte di OWA (Fare clic sull'immagine per ridurla)
Figura 1 Accesso alle risorse di Exchange Server da parte di OWA
Figura 1 Accesso alle risorse di Exchange Server da parte di OWA (Fare clic sull'immagine per ingrandirla)

Amministrazione
Nell'architetture tutta nuova di Exchange Server 2007 sono incluse utili opzioni per l'amministrazione di OWA. È possibile utilizzare Exchange Management Console o l'Exchange Management Shell. Le impostazioni di configurazione vengono archiviate in posizioni diverse.
Exchange Management Console consente di accedere alla maggior parte delle impostazioni di configurazione possibili, ad esempio all'attivazione o disattivazione delle funzioni tramite la segmentazione, al blocco degli allegati e all'autenticazione, oltre che a funzioni come il calendario, Elenco attività e la correzione ortografica. Tutte le operazioni che è possibile eseguire con la Exchange Management Console possono essere anche effettuate l'Exchange Management Shell.
L'Exchange Management Shell consente inoltre di creare ed eliminare nuove directory virtuali per OWA. È possibile controllare in modo più dettagliato le impostazioni di segmentazione in base all'utente e modificare, tra l'altro, l'impostazione della lingua predefinita.
I timeout dell'autenticazione basata sui moduli vengono archiviati per impostazione predefinita nel Registro di sistema di Windows (queste impostazioni non sono disponibili con Exchange Management Console o nell'Exchange Management Shell). Tramite Active Directory® è possibile accedere a impostazioni specifiche di OWA, come blocco degli allegati e segmentazione. Nella metabase di IIS sono contenute alcune impostazioni (autenticazione, GZIP) che influiscono sul comportamento di IIS. In web.config sono invece contenute le impostazioni di ASP.NET, come "maxuploadsize" con cui si controlla il caricamento degli allegati di OWA.

Autenticazione
In OWA sono disponibili diverse opzioni di autenticazione al server. Dopo l'installazione, la protezione viene configurata per impostazione predefinita sull'autenticazione basata sui moduli. È tuttavia possibile potenziare in vari modi la protezione, in modo da renderla conforme ai requisiti dell'organizzazione. L'autenticazione viene eseguita da IIS a fronte di Active Directory, per verificare se l'utente in connessione dispone dei diritti di dominio corrispondenti. Per l'accesso alla posta elettronica, è inoltre possibile utilizzare l'autenticazione di base, l'autenticazione del digest, RSA SecurID o addirittura l'accesso tramite smart card.
Il livello di protezione più alto per OWA è l'autenticazione integrata di Windows, che combina l'utilizzo di Kerberos e NTLM. L'autenticazione integrata di Windows è obbligatoria per l'accesso a Web Part Outlook Web Access 2007, oltre che per le connessioni proxy dei server CAS tra siti Active Directory. L'utilizzo di questo tipo di autenticazione comporta un ulteriore vantaggio per gli utenti che accedono a OWA su un'intranet, poiché consente il Single Sign-On con autenticazione del client Windows, in modo che non sia necessario eseguire l'accesso a OWA quando si è già un utente trusted.
Se si utilizza l'autenticazione basata sui moduli, ovvero l'impostazione predefinita, dopo un determinato periodo di inattività si verificherà il timeout di OWA. In base alla scelta eseguita dall'utente al momento dell'accesso di computer pubblico o privato, il timeout può essere di 15 minuti (per i computer pubblici) o di un massimo di 8 ore (per un computer privato). La scelta di un computer pubblico piuttosto che privato è importante per gli utenti, perché è possibile configurare anche le altre impostazioni di protezione in base a tale scelta. È, ad esempio, possibile bloccare gli allegati per i computer pubblici oppure modificare o i timeout per l'autenticazione. l'autenticazione basata sui moduli è essenzialmente un processo in quattro fasi, come illustrato nella Figura 2.
Figura 2 Processo di autenticazione
  1. I client inviano la richiesta al server, non crittografata
  2. I server inviano in risposta un cookie crittografato ai client.
  3. I server continuano a scartare e creare nuove chiavi di crittografia, conservando in memoria solo le tre più recenti.
  4. Ai client che inviano richieste con una chiave di crittografia scaduta ancora presente in memoria viene inviato un nuovo cookie crittografato con la chiave più recente.
    oppure
    I client che inviano richieste con una chiave di crittografia scaduta, già scartata e dopo il periodo di timeout devono rieseguire l'accesso.

msExchQueryBaseDN è il meccanismo utilizzato per limitare alcuni utenti in modo che visualizzino solo una porzione della rubrica in OWA. msExchQueryBaseDN è presente negli oggetti utente di Active Directory e punta verso un Elenco indirizzi (AL) o un'Unità organizzativa (OU). È possibile utilizzare l'AL come Elenco indirizzi globale (GAL) per l'utente, nel qual caso all'utente verrà mostrato un GAL che comprende solo gli account utente di questa OU. È possibile impostare msExchQueryBaseDN utilizzando LDAP.

Compatibilità con le versioni precedenti
Il nucleo di Outlook Web Access in Exchange Server 2007 è il CAS e il modello del CAS è stato costruito in modo da garantire la migliore interoperabilità possibile con i server su cui vengono eseguite versioni precedenti di Exchange. Per verificare l'effettivo funzionamento, è sempre necessario distribuire o aggiornare i server CAS prima di aggiornare i server cassette postali associati.
È possibile utilizzare un server Exchange 2007 con il ruolo CAS per connettersi a cassette postali presenti su server Exchange 2000 ed Exchange 2003. RPC su HTTP ed Exchange ActiveSync® continueranno a funzionare con un aggiornamento parziale del sito. Anche OWA e WebDAV funzioneranno se si esegue l'accesso tramite le directory virtuali /exchange, /public o /exchweb. È inoltre possibile creare su Exchange Server 2007 directory virtuali OWA personalizzate per queste versioni precedenti.

ISA Server 2006: un amico in più
Outlook Web Access ha subito grandi miglioramenti in Exchange Server 2007, ma è possibile potenziarlo ulteriormente con Internet Security and Acceleration (ISA) Server 2006.
ISA Server 2006 è un gateway di protezione integrato che allo stesso tempo aiuta a proteggere il sito dalle minacce che provengono da Internet e offre un accesso remoto protetto ad applicazioni e dati. Si tratta degli stessi obiettivi di OWA, quindi l'accoppiamento dei due produce il più fantasmagorico di tutti i concetti informatici: la sinergia. Per ulteriori informazioni di carattere generale su ISA Server, visitare il sito microsoft.com/isaserver/2006 (in inglese).
ISA Server 2006 apporta una serie di vantaggi a tutti gli amministratori Exchange sempre troppo occupati. La funzione Bilanciamento del carico per pubblicazione sul Web (WPLB) , ad esempio, consente di bilanciare i carichi utilizzando i cookie HTTP. È possibile garantire l'affinità client-server anche quando l'IP del client cambia. ISA Server 2006 prevede inoltre la compressione e decompressione GZIP, consentendo di analizzare il traffico o la ripartizione del carico di lavoro da server Web. Con ISA Server 2004 era necessario scegliere: era possibile utilizzare la compressione HTTP con OWA oppure l'autenticazione basata sui moduli con ISA Server. Per fortuna ISA Server 2006 le supporta entrambe contemporaneamente.
Per di più, è possibile eseguire la conversione del collegamento OWA tramite ISA Server. Se un utente inserisce un collegamento intranet nella posta elettronica OWA, ISA Server è in grado di convertirlo in un collegamento Internet. Questa funzionalità è molto utile, ma è necessario ricordarsi di pubblicare i collegamenti intranet sullo stesso array ISA di OWA.
La caratteristica forse più importante di ISA Server 2006 è l'esecuzione della preautenticazione per migliorare la protezione della rete lungo il perimetro. Lo scopo della preautenticazione consiste nell'evitare che il traffico HTTP anomalo raggiunga i server. Se il traffico diretto verso i CAS è valido, ISA Server lo lascia rapidamente passare dal perimetro al dominio (i server perimetrali sono all'esterno del dominio dell'intranet e bloccano il traffico che non appartiene a tale dominio; i CAS non devono essere dislocati all'interno del dominio del perimetro, ma sul dominio dell'intranet in modo da poter accedere agli account utente di Active Directory).

Risoluzione dei problemi di Outlook Web Access
Outlook Web Access 2007 è dotato di nuovi strumenti per il monitoraggio e la risoluzione dei problemi. Un'attività di monitoraggio viene eseguita automaticamente sul server CAS. La connettività per ciascun server cassette postali e gli accessi a OWA vengono sottoposti a test da questa attività. I messaggi del registro eventi e i contatori delle prestazioni di Exchange Server 2007 sono molto più precisi.
L'Exchange Server Best Practices Analyzer (per ulteriori informazioni, vedere all'indirizzo microsoft.com/technet/technetmag/issues/2006/01/TuneUpExchange (in inglese)) è stato migliorato in modo che gli amministratori ricevano delle notifiche per avvisi ed errori quando OWA non è configurato in modo corretto. È inoltre possibile creare report di utilizzo di OWA dai registri IIS utilizzando lo strumento LogParser (illustrato nel numero di ottobre 2006 microsoft.com/technet/technetmag/issues/2006/10/LogParser (in inglese)).

Messaggistica unificata
Se con OWA si risponde alle esigenze dei lavoratori in continuo movimento, con la messaggistica unificata si consolidano le diverse forme di comunicazione in un'unica posizione centralizzata (da cui l'ovvio nome). In questo momento i messaggi di posta elettronica sono su Exchange Server. La comunicazione vocale invece (telefonate, messaggi vocali) è disponibile su un server di telefonia. I messaggi di posta elettronica arrivano sul desktop, mentre per ascoltare i messaggi vocali di usa il telefono. Senza nemmeno dire dei fax.
La messaggistica unificata di Exchange Server 2007 consente alle organizzazioni di concentrare la ricezione di messaggi di posta elettronica, vocali e fax in un'unica cartella Posta in arrivo, a cui gli utenti possono accedere tramite Outlook e OWA. La messaggistica unificata funziona anche nel senso contrario: gli utenti possono accedere a messaggi vocali, messaggi di posta elettronica, contatti e calendari tramite il telefoni con Outlook Voice Access.
Dal punto di vista di un amministratore di sistema, la messaggistica unificata semplifica le funzioni di messaggistica combinando le infrastrutture Exchange e telefoniche in un'unica soluzione di archiviazione, un'unica directory e un unico trasporto. Il livello di complessità si riduce quando per ciascun utente esiste una sola cassetta postale.
Ma l'aspetto più interessante è la possibilità di implementare questa soluzione con i server esistenti e, se si hanno già nozioni di Exchange Server 2007 e telefonia, la curva di apprendimento è praticamente piatta. Le funzionalità di messaggistica unificata sono integrate con Exchange: si utilizzano gli stessi modelli di protezione e cartelle Posta in arrivo. È inoltre possibile accedere a messaggi vocali e fax con OWA.
Nella Figura 3 è illustrata l'architettura della messaggistica unificata in Exchange Server 2007 con il ruolo del server Messaggistica unificata installato. Osservare con attenzione l'immagine (più avanti potrebbe esserci un quiz) prima di passare ad analizzare nel dettaglio l'architettura della messaggistica unificata.
Figura 3 Con la messaggistica unificata si centralizzano le comunicazioni di posta elettronica, fax e vocali
Figura 3 Con la messaggistica unificata si centralizzano le comunicazioni di posta elettronica, fax e vocali (Fare clic sull'immagine per ridurla)
Figura 3 Con la messaggistica unificata si centralizzano le comunicazioni di posta elettronica, fax e vocali
Figura 3 Con la messaggistica unificata si centralizzano le comunicazioni di posta elettronica, fax e vocali (Fare clic sull'immagine per ingrandirla)
Quando si configura la messaggistica unificata in una grande azienda, è necessario tenere conto di molti elementi. In Exchange Server sono contenuti degli oggetti che rappresentano l'hardware della telefonia. È possibile definire le relazioni tra questi oggetti all'interno dell'ambiente Exchange Server. Gli oggetti di sistema della messaggistica unificata di Exchange Server comprendono Server di messaggistica unificata, Dial plan di messaggistica unificata, Gateway IP di messaggistica unificata e Gruppo di risposta di messaggistica unificata, oltre a Criteri di messaggistica unificata e Operatore automatico di messaggistica unificata. Di seguito è riportata una breve descrizione delle funzionalità di ciascuno di questi oggetti.
L'oggetto Server di messaggistica unificata viene creato in Active Directory quando si installa il ruolo del server Messaggistica unificata e consente a un amministratore di controllare le impostazioni di una distribuzione della messaggistica unificata di Exchange Server 2007. Dial plan di messaggistica unificata è l'unità amministrativa di base all'interno della messaggistica unificata e rappresenta l'utilizzo degli interni. Tutti gli utenti compresi in un dial plan possono raggiungere tutti gli altri utenti selezionando gli interni corrispondenti. Se si collegano più sedi, ciascuna disporrà di un proprio Dial plan.
L'oggetto Gateway IP di messaggistica unificata rappresenta un gateway VoIP (Voice over Internet Protocol) fisico oppure un PBX (Private Brach Exchange) IP con abilitazione SIP (Session Initiation Protocol). Un server di messaggistica unificata può ricevere chiamate da un dispositivo gateway IP/VoIP. Un Gruppo di risposta di messaggistica unificata collega un gateway IP a un dial plan di messaggistica unificata. Dopo la configurazione di un gruppo di risposta sul PBX, in Active Directory viene creato un Gruppo di risposta di messaggistica unificata che lo rappresenta. È possibile configurare il gruppo di risposta in modo da garantire il bilanciamento del carico sui gateway IP. I gateway garantiscono, a propria volta, il bilanciamento del carico associando un singolo Gruppo di risposta di messaggistica unificata a più gateway. I Criteri di messaggistica unificata sono analoghi alle classi di servizio dei messaggi vocali e comprendono un dial plan e delle proprietà che impostano i criteri operativi per utenti e gruppi.
È possibile associare l'Operatore automatico di messaggistica unificata a un singolo dial plan di messaggistica unificata. È possibile applicare delle personalizzazioni per eseguire alcune attività, ad esempio richieste di registrazione e definizione di attività per giorni e orari diversi. È possibile definire l'ambito degli operatori automatici utilizzando gli elenchi di indirizzi.
Nella Figura 4 è illustrata l'interazione tra i sei oggetti di messaggistica unificata.
Figura 4 Interazione tra gli oggetti di telefonia di messaggistica unificata
Figura 4 Interazione tra gli oggetti di telefonia di messaggistica unificata (Fare clic sull'immagine per ridurla)
Figura 4 Interazione tra gli oggetti di telefonia di messaggistica unificata
Figura 4 Interazione tra gli oggetti di telefonia di messaggistica unificata (Fare clic sull'immagine per ingrandirla)

Configurazione
Dopo aver creato una cassetta postale di Exchange Server 2007 per l'utente, l'amministratore deve attivarla per la messaggistica unificata. A tal fine è necessario associare la cassetta postale a un criterio di messaggistica unificata e a un numero di interno, entrambi all'interno del dial plan. È inoltre necessario configurare il PBX in modo che la chiamata alla messaggistica unificata venga instradata verso un RNA (Ring, No Answer, squillo senza risposta). La chiamata viene prima inoltrata dal PBX all'interno dell'utente. In caso di RNA la chiamata viene instradata al gateway VoIP e, infine, al server di messaggistica unificata.
La messaggistica unificata è scalabile. È possibile aggiungere tutti i canali PBX a commutazione di circuito e server di messaggistica unificata necessari per ottenere la capacità desiderata. Quando si utilizzano i gateway VoIP, le chiamate su IP vengono instradate alla messaggistica unificata di Exchange. Poiché questa per molte aziende è una funzionalità del tutto nuova, sarà necessario verificare con un ciclo completo di analisi che sulla rete IP utilizzata la larghezza di banda sia sufficiente a gestire sia voce che dati.
Un server di messaggistica unificata Exchange Server 2007 tipico è in grado di gestire tra 50 e 200 chiamate IP contemporanee e fino a un massimo di 200 chiamate in arrivo tra vocali e fax (anche se l'impostazione predefinita è limitata a 100). È possibile creare ulteriori server di messaggistica unificata quando è necessaria una capacità maggiore oppure per migliorare la tolleranza di errore.

Conclusione
Questo è quanto: In Exchange Server 2007 sono disponibili due funzionalità, Outlook Web Access e messaggistica unificata, che utilizzati in combinazione offrono grandi vantaggi per un'organizzazione. Outlook Web Access consente di accedere in modalità protetta alla posta elettronica da qualsiasi luogo, mentre la messaggistica unificata consente agli utenti di accedere tramite la propria cassetta postale Exchange 2007 a tutti i messaggi di posta elettronica, vocali e fax e agli altri dati della cassetta.

Joshua Trupin è Executive Editor di MSDN Magazine e TechNet Magazine. Ha scritto molti articoli per MSJ, MIND, MSDN Magazine e TechNet Magazine, oltre a un libro, Hoop Stats: The Basketball Abstract (in inglese).


 Exchange Server 2007: Inserimento nel journal pi&#249; efficace con Exchange 2007
Exchange Server 2007 David Strome

Inserimento nel journal più efficace con Exchange 2007
Panoramica:
  • Regole di inserimento nel journal di Exchange Server 2007
  • La nuova procedura guidata di inserimento nel journal
  • Contenuto di un report del journal

In precedenza poteva capitare che, quando si tentava di inserire nel journal i messaggi di posta elettronica inviati a o ricevuti da un utente specifico, venissero inseriti nel journal, oltre ai messaggi richiesti, anche i messaggi delle altre centinaia di cassette postali che
risiedevano nello stesso archivio cassette postali. Grazie a un maggior dettaglio nel controllo, in Microsoft Exchange Server 2007 il problema non si verifica più.
L'inserimento nel journal in base al destinatario, disponibile con le Licenze di accesso client (CAL) aziendali, consente di indicare con precisione l'utente da inserire nel journal. Le regole di inserimento nel journal ora consentono di definire con precisione destinatari e mittenti da inserire nel journal. È possibile concentrare l'attenzione su un'unica cassetta postale oppure ampliare il raggio di azione fino a includere, ad esempio, tutto il personale del reparto vendite. Non è nemmeno necessario che tutte le cassette di posta da monitorare si trovino sul medesimo server, nel medesimo sito di Active Directory® o, addirittura, in un'unica organizzazione Exchange. Grazie alla replica di Active Directory, le modifiche apportate vengono automaticamente applicate a tutti i computer dell'organizzazione su cui è in esecuzione il ruolo del server Trasporto Hub.

Funzionamento dell'inserimento nel journal
In Exchange Server 2003 l'inserimento nel journal veniva implementato su singoli archivi cassette postali di ciascun server fisico. Per inserire nel journal tutte le cassette postali dell'organizzazione, era necessario configurare l'inserimento nel journal in ciascun archivio cassette postali. Se invece era necessario inserire nel journal i messaggi di un solo destinatario, era necessario inserire nel journal tutti gli utenti presenti nello stesso archivio cassette postali oppure creare un nuovo archivio cassette postali solo per l'utente desiderato.
In Exchange Server 2007 si utilizza invece la nuova topologia basata sui ruoli di Exchange. Come illustrato nella Figura 1, tutti i messaggi vengono elaborati dai server Trasporto Hub quando vengono inviati o ricevuti da server Cassette postali e Messaggistica unificata, altri sistemi Exchange, applicazioni di terze parti e Internet. In tutti i server Trasporto Hub è contenuto un agente di trasferimento denominato agente di journaling, che presiede all'applicazione ai messaggi delle regole di inserimento nel journal. Poiché si trova sui server Trasporto Hub, l'agente di journaling intercetta e valuta tutti i messaggi prima che questi raggiungano i rispettivi destinatari. L'agente di journaling agisce sui messaggi dopo la categorizzazione, in modo da garantire l'accesso a tutti gli attributi di destinatario e mittente del messaggio e consentire all'agente di determinare se il messaggio è stato inviato direttamente a un destinatario oppure è stato ricevuto tramite espansione del gruppo di distribuzione. È inoltre possibile determinare se l'indirizzo del destinatario era riportato nel campo A, Cc o Ccn di un messaggio creato all'interno dell'organizzazione in cui si utilizza Exchange Server 2007.
Figura 1 Flusso della posta nel server Trasporto Hub
Figura 1 Flusso della posta nel server Trasporto Hub (Fare clic sull'immagine per ridurla)
Figura 1 Flusso della posta nel server Trasporto Hub
Figura 1 Flusso della posta nel server Trasporto Hub (Fare clic sull'immagine per ingrandirla)
L'agente di journaling consente di applicare le regole di inserimento nel journal configurate dall'amministratore ai messaggi, non appena questi giungono al server Trasporto Hub. Con le regole è possibile definire se l'agente acquisirà informazioni su un messaggio da inoltrare, insieme al messaggio originale, a una cassetta postale del journal. I dati vengono inviati all'interno di un messaggio denominato report del journal.
Nelle precedenti versioni di Exchange era necessario applicare le configurazioni a più server. Quando, invece, si crea una regola di inserimento nel journal in Exchange Server 2007, la modifica viene applicata a tutti i server Trasporto Hub dell'organizzazione tramite Active Directory. Per tutti i server Trasporto Hub, e di conseguenza per tutti gli agenti di journaling, viene letta la medesima configurazione da Active Directory. Questo tipo di copertura garantisce che venga applicata la stessa configurazione di inserimento nel journal da tutti gli agenti di journaling.
Al momento di creare o modificare le regole di inserimento nel journal, è opportuno tenere conto dei tempi di replica di Active Directory, poiché è necessario che una modifica della configurazione venga replicata nell'intera organizzazione e letta dai server Trasporto Hub. Per l'operazione potrebbero essere necessarie alcune ore. Per facilitare il rilevamento dell'avvenuto aggiornamento della configurazione, in Exchange un evento viene registrato nel registro eventi protezione di ciascun server.
In Exchange Server 2007 i report del journal non vanno mai perduti a causa di cassette postali del journal non disponibili, sia perché piene o configurate in modo errato oppure non in linea (funzionalità particolarmente utile quando è necessario garantire la conformità a normative e regolamenti, poiché la perdita dei messaggi potrebbe comportare una non conformità). Quando non è possibile recapitare un report del journal a una cassetta postale del journal, il report resta nella coda del server Trasporto Hub fino a che la cassetta postale del journal non torna disponibile. Poiché questo comportamento può provocare una rapida crescita delle code, è opportuno tenere sotto controllo la disponibilità della cassetta postale del journal per verificare che funzioni in modo corretto. Se una cassetta postale del journal resta indisponibile per un periodo prolungato, è possibile configurare una cassetta postale alternativa in cui ricevere i report fermi in coda.

Elementi da inserire nel journal
Prima di iniziare a creare delle regole di inserimento nel journal, è necessario definire gli utenti da monitorare e il tipo di dati da inserire nel journal. In una regola di inserimento nel journal è possibile indicare utenti specifici. Tali utenti potrebbero, ad esempio, essere soggetti a requisiti normativi particolari oppure essere coinvolti in azioni giudiziarie che richiedono la raccolta di messaggi di posta elettronica o altre comunicazioni come prove.
Oltre a specificare gli utenti da inserire nel journal, è inoltre possibile definire l'ambito dei messaggi da inserire nel journal, con opzioni per i messaggi interni, esterni e globali. Per interni si intendono solo i messaggi scambiati all'interno dell'organizzazione, per esterni i messaggi con il mittente o uno dei destinatari esterni all'organizzazione e per globali sia i messaggi interni che esterni. È bene sottolineare che con l'opzione globale vengono inseriti nel journal tutti i messaggi che passano dal server Trasporto Hub, compresi i messaggi già elaborati da regole che utilizzano un ambito interno o esterno.
Exchange Server 2007 supporta Messaggistica unificata e consente, quindi, di configurare Exchange in modo da raccogliere messaggi di posta elettronica, messaggi vocali e fax di un utente nella cartella Posta in arrivo corrispondente. È inoltre sottintesa la possibilità di inserire nel journal tutti questi dati o decidere di escluderne alcuni.
Se si esegue Exchange Server 2007 con CAL standard, è ancora possibile utilizzare la funzionalità di inserimento nel journal in base all'archivio cassette postali. Per utilizzare le nuove funzionalità di inserimento nel journal in base ai destinatari, è tuttavia necessario dotarsi di CAL aziendali di Exchange Server 2007.

Dislocazione della cassetta postale del journal
Dopo aver deciso gli elementi da inserire nel journal, è necessario specificare la posizione presso cui inviare i report del journal. Se l'organizzazione ha più sedi, è opportuno tenere conto della topologia di rete corrente o pianificata per decidere le posizioni in cui creare le cassette postali per i journal. L'inserimento di informazioni nel journal, infatti, può provocare la creazione di un notevole numero di report ripetitivi in funzione delle dimensioni dell'organizzazione e del numero di cassette postali.
Non è, tuttavia, necessario limitarsi alle cassette postali di Exchange, dal momento che è possibile inviare report del journal a qualsiasi indirizzo SMTP valido. Tale indirizzo può puntare verso i servizi host di Exchange, una soluzione di archiviazione di terze parti oppure una qualsiasi combinazione di questi tramite un gruppo di distribuzione. È necessario tenere conto, in questo caso, delle implicazioni di protezione relative alle posizioni presso cui si inviano i report del journal.
Indipendentemente dalla posizione prescelta per la cassetta postale del journal, è necessario creare un oggetto destinatario corrispondente in Active Directory. L'oggetto può essere una cassetta postale Exchange Server 2007, un contatto con la posta abilitata che reindirizza la posta verso i servizi host di Exchange o una soluzione di archiviazione di terze parti oppure una lista di distribuzione che contiene sia cassette postali che contatti.

Contenuto del report del journal
Quando un messaggio viene inserito nel journal dall'agente di journaling, nel report del journal vengono acquisite le informazioni sul messaggio originale nel massimo dettaglio possibile. Il report viene quindi inviato alla cassetta postale del journal. Le informazioni acquisite sono molto importanti per determinare l'intento, i destinatari e i mittenti del messaggio. Quando, ad esempio, si identificano i destinatari inseriti direttamente nel campo A, nel campo Cc o solo in una lista di distribuzione, è facile determinare il tipo di coinvolgimento del destinatario nella discussione del messaggio. Il messaggio originale viene inoltrato come allegato. Nelle schermate riprodotte nella Figura 2 sono illustrati un report del journal con un messaggio inviato a david@contoso.com e inoltrato a christine@contoso.com e un altro report del journal con un messaggio inviato al gruppo di distribuzione Sales_Group@contoso.com che è stato espanso e il destinatario lukas@contoso.com, membro del gruppo di distribuzione Sales Group, che ha ricevuto il messaggio. In entrambi i report è presente il messaggio originale in allegato, con il mittente originale, che è brian@contoso.com, e l'oggetto "Sales forecast".
Figura 2 Report del journal con il destinatario di un messaggio inoltrato e un destinatario di un gruppo di distribuzione espanso
Figura 2 Report del journal con il destinatario di un messaggio inoltrato e un destinatario di un gruppo di distribuzione espanso (Fare clic sull'immagine per ridurla)
Figura 2 Report del journal con il destinatario di un messaggio inoltrato e un destinatario di un gruppo di distribuzione espanso
Figura 2 Report del journal con il destinatario di un messaggio inoltrato e un destinatario di un gruppo di distribuzione espanso (Fare clic sull'immagine per ingrandirla)
In Exchange vengono classificate solo le informazioni considerate corrette. Le informazioni che non è possibile determinare in modo automatico vengono inserite nei campi corrispondenti del report del journal. Nella Figura 2 sono descritti i campi inseriti nel corpo del report del journal.

Tutto ciò che serve sapere sulla protezione
Per impostazione predefinita, tutte le comunicazioni scambiate tra computer con Exchange Server 2007 all'interno della medesima organizzazione Exchange vengono crittografate, compresi i report del journal. In Exchange Server vengono eseguite alcune operazioni volte a ridurre il rischio di manomissione dei report del journal:
  • Per le comunicazioni tra server Trasporto Hub e server Cassette postali nell'organizzazione Exchange 2007 si utilizzano connessioni protette.
  • I report del journal vengono inviati come "Microsoft Exchange" per conto del mittente del messaggio originale.
  • Le sessioni tra server Trasporto Hub e server Cassette postali sono autenticate.
  • Quando i report del journal vengono trasmessi tra server Trasporto Hub e server Cassette postali all'interno della medesima organizzazione Exchange 2007, vengono accettate solo connessioni autenticate.
Quando si crea una cassetta postale del journal, è necessario proteggerla poiché la cassetta postale contiene i messaggi inviati e ricevuti dagli utenti dell'organizzazione. Alcuni dei messaggi potrebbero entrare a far parte di azioni giudiziarie o essere soggetti a requisiti normativi particolari e, in base alle normative d molte nazioni, è necessario che i messaggi restino al sicuro da eventuali manomissioni prima di essere messi a disposizione dell'autorità giudiziaria. Per aumentare il livello di protezione della cassetta postale del journal, è necessario configurare la cassetta postale in modo che accetti solo messaggi dal mittente Microsoft Exchange e richiedere che tutti i messaggi inviati alla cassetta postale abbiano mittenti autenticati. Nella Figura 3 sono illustrate le restrizioni sul recapito dei messaggi configurate per una cassetta postale del journal. Per configurare le stesse restrizioni sul recapito dei messaggi, è inoltre possibile utilizzare il seguente comando dell'Exchange Management Shell:
Set-Mailbox <Journal Mailbox Name>
-AcceptMessagesOnlyFrom "Microsoft Exchange" -RequireSenderAuthenticationEnabled $True
Figura 3 Restrizioni sul recapito dei messaggi
Figura 3 Restrizioni sul recapito dei messaggi (Fare clic sull'immagine per ridurla)
Figura 3 Restrizioni sul recapito dei messaggi
Figura 3 Restrizioni sul recapito dei messaggi (Fare clic sull'immagine per ingrandirla)
Se si inviano i report del journal a una cassetta postale del journal esterna alla propria organizzazione Exchange Server 2007, sarà necessario crittografare e proteggere manualmente la connessione tra i computer di Exchange Server 2007 e il server di destinazione. È possibile ottenere questo risultato richiedendo l'utilizzo della Transport Layer Security (TLS) tra i due sistemi, richiedendo l'autenticazione sul sistema di destinazione, accettando solo messaggi sul sistema di destinazione provenienti dall'indirizzo SMTP del mittente Microsoft Exchange (l'indirizzo SMTP sarà simile a Exchange_UMUnique GUID@contoso.com) e configurando il contatto di Active Directory utilizzato per l'inoltro dei messaggi in modo che accetti messaggi provenienti unicamente dal mittente Microsoft Exchange.

Implementazione delle regole di inserimento nel journal
A questo punto è bene passare dalle parole ai fatti e provare a implementare delle regole. È possibile configurare le regole di inserimento nel journal sia nell'Exchange Management Shell che nell'Exchange Management Console. Con entrambi i metodi è possibile configurare destinatario, ambito e impostazioni della cassetta postale del journal. Per impostazione predefinita, le regole di inserimento nel journal vengono attivate al momento della creazione. Il valore specificato per l'indirizzo di posta elettronica del journal deve essere un oggetto destinatario esistente nell'organizzazione Exchange Server 2007. L'oggetto destinatario può essere una cassetta postale, un gruppo di distribuzione, un gruppo di distribuzione dinamico o un contatto che invia messaggi a un indirizzo SMTP.
Quando si utilizza l'Exchange Management Console, è possibile sfruttare la creazione guidata di una nuova regola di inserimento nel journal. Nella sezione Configurazione organizzazione, scegliere il ruolo del server Trasporto Hub. Nel riquadro Azioni fare clic su Nuova regola del diario. Qui è necessario indicare i valori per il nome della regola, l'indirizzo di posta elettronica del journal e l'ambito. Se si desidera utilizzare la regola di inserimento nel journal per inserire i messaggi di tutti i destinatari dell'organizzazione, non è invece necessario specificare un valore per il campo del destinatario. È inoltre possibile specificare se si desidera che la regola venga creata come disattivata. Nella Figura 4 è illustrata una configurazione di esempio con cui si inseriscono nel journal tutti i messaggi inviati o ricevuti da brian@contoso.com. I messaggi inseriti nel journal vengono inviati a una cassetta postale del journal denominata Compliance Mailbox.
Figura 4 Creazione guidata di una nuova regola di inserimento nel journal
Figura 4 Creazione guidata di una nuova regola di inserimento nel journal (Fare clic sull'immagine per ridurla)
Figura 4 Creazione guidata di una nuova regola di inserimento nel journal
Figura 4 Creazione guidata di una nuova regola di inserimento nel journal (Fare clic sull'immagine per ingrandirla)
Nell'Exchange Management Shell è possibile utilizzare i seguenti sei cmdlet per amministrare l'agente di journaling:
  • New-JournalRule
  • Set-JournalRule
  • Get-JournalRule
  • Remove-JournalRule
  • Enable-JournalRule
  • Disable-JournalRule
Il cmdlet New-JournalRule consente di creare una nuova regola di inserimento nel journal. I criteri di base per la creazione di una nuova regola di inserimento nel journal restano gli stessi in vigore quando si utilizza la creazione guidata. È necessario specificare i valori per il nome, l'ambito e i parametri di JournalEmailAddress. Anche in questo caso, se si desidera utilizzare la regola di inserimento nel journal per inserire i messaggi di tutti i destinatari dell'organizzazione, non è necessario specificare un valore per il parametro del destinatario. Per creare invece la regola come disattivata, è necessario specificare il valore $False per il parametro Enabled. La creazione di una regola di inserimento nel giornale con una configurazione identica alla regola descritta nella Figura 4 richiede l'esecuzione del comando:
New-JournalRule
-Name "Brian Smith Journal Rule"
-Recipient brian@contoso.com
-JournalEmailAddress "Compliance Mailbox"
-Scope Global
Per visualizzare un elenco di tutte le regole di inserimento nel giornale che si sono create, si utilizza il cmdlet Get-JournalRule. Quando si esegue questo cmdlet da solo, si visualizza un elenco sintetico di tutte le regole di inserimento nel journal configurate nell'organizzazione con le rispettive configurazioni. Per visualizzare tutte le informazioni disponibili su una regola di inserimento nel journal, è possibile passare tramite pipeline il cmdlet Get-JournalRule al cmdlet Format-List. Questo metodo consente di passare l'output di un cmdlet al cmdlet successivo, in modo da elaborare ulteriormente l'output con il secondo cmdlet. Con il cmdlet Format-List, ad esempio, si ottiene la visualizzazione di tutti gli output che il cmdlet ha ricevuto. Per visualizzare tutte le informazioni disponibili sulla regola di inserimento nel journal creata in precedenza, è possibile eseguire il comando:
Get-JournalRule -Identity "Brian Smith Journal Rule" | Format-List
Per attivare o disattivare una regola di inserimento nel journal, si utilizzano i cmdlet Enable-JournalRule e Disable-JournalRule. Quando si utilizzano questi cmdlet, è necessario specificare specify il nome della regola nel parametro Identity. Per disattivare, ad esempio, la regola di inserimento nel journal appena creata, utilizzare il seguente comando:
Disable-JournalRule -Identity "Brian Smith Journal Rule"
Il cmdlet Set-JournalRule consente di modificare una regola di inserimento nel journal esistente. Al parametro Identity viene attribuito come valore il nome della regola di inserimento nel journal, in modo da specificare all'agente di journaling la regola oggetto della modifica. È quindi possibile specificare i valori per i parametri Recipient, JournalEmailAddress, Scope o per una qualsiasi combinazione dei tre insieme al nuovo valore. Per modificare, ad esempio, il valore memorizzato nel parametro JournalEmailAddress per la regola appena creata, è possibile utilizzare il seguente comando:
Set-JournalRule -Identity "Brian Smith Journal Rule" -JournalEmailAddress "Seattle Users Compliance Mailbox"
Il cmdlet Remove-JournalRule, infine, consente di rimuovere una regola di inserimento nel journal esistente. Per specificare il nome della regola da rimuovere, si utilizza il parametro Identity. Per eliminare la regola di inserimento nel journal di esempio, utilizzare il seguente comando:
Remove-JournalRule "Brian Smith Journal Rule"
Verrà richiesta conferma dell'eliminazione della regola di inserimento nel journal. Un ultimo suggerimento: con quasi tutti i cmdlet, è possibile omettere l'etichetta del parametro Identity e specificare soltanto il valore del parametro.

David Strome è Technical Writer del gruppo Exchange User Education presso Microsoft da oltre un anno. Prima dell'assunzione in Microsoft a Redmond, WA, David ha lavorato per circa 10 anni alla progettazione, implementazione e amministrazione di installazioni di Exchange Server per molte aziende in British Columbia, Canada. È possibile contattare David scrivendo all'indirizzo dstrome@microsoft.com.


 Exchange Server 2007: Utilizzo dell'ID mittente per combattere posta indesiderata e phishing
Exchange Server 2007 Craig Spiezle and Alexander Nikolayev

Utilizzo dell'ID mittente per combattere posta indesiderata e phishing
Panoramica:
  • Nozioni di base sull'ID mittente
  • Configurazione dell'ID mittente in Exchange Server
  • Vantaggi dell'autenticazione

La maggior parte delle tecnologie di identificazione e filtro è stata sviluppata in risposta alla crescente minaccia della posta indesiderata. Per garantire elevati livelli di efficienza, tali tecnologie prevedono un meccanismo di verifica basato su domande relative a ciascun messaggio di posta elettronica, ad esempio
domande sull'identità del mittente del messaggio. Purtroppo non è sempre semplice fornire una risposta ad una domanda di fondamentale importanza, come l'identità del mittente del messaggio. La posta elettronica viene in genere trasmessa su Internet senza che venga richiesta l'autenticazione del mittente o dei computer che agiscono per conto del mittente. Inviare un messaggio di posta elettronica facendo finta di essere un'altra persona è piuttosto semplice e non esiste alcun metodo automatico di rilevamento dei messaggi falsificati.
Il protocollo SMTP (Simple Mail Transfer Protocol), utilizzato per l'invio e la ricezione di posta elettronica, non è stato progettato per eseguire la verifica del mittente di un messaggio di posta elettronica. Con questo punto debole tecnologico, è possibile inserire come mittente qualsiasi nome e indirizzo. Per accertare l'effettiva provenienza dei messaggi, il filtro del contenuto o le misure di protezione da posta indesiderata non possono, di conseguenza, basarsi esclusivamente sulle informazioni delle intestazioni.
L'autenticazione della posta elettronica mira a far fronte a questo specifico punto debole. Grazie all'autenticazione, i sistemi di posta elettronica di invio e ricezione sono in grado di accertare che i messaggi abbiano effettivamente origine dai domini da cui dichiarano di provenire. In tal modo si semplifica il filtraggio della posta indesiderata da parte delle organizzazioni e, nel contempo, si garantisce che i messaggi di posta elettronica autorizzati raggiungano i destinatari previsti.
Sono attualmente disponibili due approcci all'autenticazione della posta elettronica non soggetti a royalty: Sender ID Framework (SIDF) e DomainKeys Identified Mail (DKIM). SIDF è una soluzione basata sul protocollo IP creata dalla fusione delle tecnologie Sender Policy Framework (SPF) e Microsoft Caller ID for E-Mail. Nell'aprile del 2006 la Internet Engineering Task Force (IETF) ha pubblicato le specifiche relative all'ID mittente come RFC 4405-4408. Una coalizione di soggetti interessati dei settori industriale e commerciale, tra cui Microsoft, consiglia la distribuzione di SIDF sulla base di determinati fattori, quali valore commerciale e tecnico, stabilità, maturità, semplicità di distribuzione, impatto minimo sulle prestazioni in ingresso e in uscita e interoperabilità con l'ecosistema della posta elettronica per i provider di servizi Internet (ISP) e gli ambienti aziendali.
DKIM rappresenta una fusione delle specifiche IIM (Identified Internet Mail) di Yahoo! DomainKeys e Cisco Systems Inc. Nel gennaio del 2006 la IETF ha approvato la creazione di un gruppo di lavoro DKIM e le specifiche sono attualmente in fase di revisione.
Sebbene non esista una soluzione perfetta per contrastare la posta indesiderata, SIDF rappresenta una significativa iniziativa industriale in grado di far fronte alle problematiche correlate ai domini falsificati. Rappresenta quindi un componente chiave per la riduzione degli attacchi di spamming e phishing e della creazione di un clima di maggiore fiducia e affidabilità per Internet. La tecnologia SIDF registra una sempre più vasta diffusione nelle organizzazioni di tutto il mondo. Attualmente più di 5,5 milioni di società e proprietari di domini hanno pubblicato i record SPF e più di 600 milioni di utenti sono protetti tramite SIDF. Inoltre, oltre un terzo del volume della posta elettronica prodotta ogni giorno a livello mondiale risulta ora autenticata e compatibile con SIDF.
Lo sviluppo e l'adozione in tutto il mondo di SIDF non sarebbero stati possibili senza il contributo e il supporto di molte organizzazioni e società, tra cui AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign e altri ancora.

Descrizione dell'ID mittente
Alcuni sondaggi del settore indicano che il 95% delle attività di phishing proviene da domini falsificati e utilizza indirizzi di posta elettronica di mittenti falsificati. La tecnologia SIDF rappresenta un significativo passo avanti per quanto riguarda l'elaborazione della posta indesiderata. SIDF, di per sé, non è in grado di risolvere il problema della posta indesiderata, ma contribuisce in modo significativo a ridurre al minimo le conseguenze degli attacchi di spamming e phishing. Sebbene non impedisca l'invio di posta indesiderata, questa tecnologia consente tuttavia di semplificare il rilevamento della posta indesiderata. Il framework consente ai mittenti di messaggi di posta elettronica di proteggere i relativi nomi di domini, la reputazione e i rispettivi marchi e svolge un ruolo fondamentale nell'adozione di decisioni di filtro basate sulla reputazione e sul comportamento del mittente.
Con l'ID mittente si tenta di verificare che tutti i messaggi di posta elettronica abbiano origine dal dominio Internet da cui dichiarano di essere stati inviati. A tale scopo si controlla l'indirizzo del server che invia il messaggio, confrontandolo con un elenco registrato di server autorizzati dal proprietario del dominio a inviare posta elettronica. La verifica viene eseguita automaticamente dal provider di servizi Internet (ISP) o dal server di posta del destinatario, prima che il messaggio venga recapitato nella Posta in arrivo dell'utente.
È opportuno ricordare che l'ID mittente, o qualsiasi altro meccanismo di autenticazione, non sostituisce i sistemi di filtro del contenuto e che con nessuna delle due tecnologie, SIDF e DKIM, viene eseguita la scansione del contenuto effettivo dei messaggi. Al contrario, con l'autenticazione si notifica al sistema di posta in arrivo che il messaggio può essere convalidato come proveniente dal mittente dichiarato. Poiché la maggior parte degli attacchi di spamming e phishing non proviene dai domini indicati, questo approccio consente di identificare automaticamente tali messaggi e di separarli dal flusso dei messaggi di posta elettronica in arrivo.
In SIDF il record SPF fornisce un semplice record di testo di tutti i server di posta in uscita associati a un dominio e dei rispettivi indirizzi IP. Un'organizzazione pubblica il record SPF nel relativo file di zona del server DNS, che viene in seguito controllato dai server di posta dei destinatari. L'impostazione di un record SPF è un'operazione semplice, rapida e gratuita. Con la procedura guidata Sender ID Framework SPF Record Wizard si forniscono istruzioni dettagliate per l'analisi dei server di posta di un dominio e la creazione di record personalizzati pronti per la pubblicazione. Ulteriori dettagli relativi alla pubblicazione di un record SPF sono disponibili sul sito Web all'indirizzo microsoft.com/senderid (in inglese). È possibile accedere alla procedura guidata direttamente dal sito microsoft.com/senderid/wizard (in inglese).
Il server di posta SMTP di ricezione esegue il ping del file di zona del dominio in DNS per verificare l'esistenza di un record SPF. Una volta individuato, l'indirizzo IP del server di invio viene controllato in base agli indirizzi IP elencati. Se viene rilevata una corrispondenza, il messaggio verrà convalidato come autentico. Se invece il record SPF nel dominio del mittente non corrisponde all'indirizzo IP da cui proviene il messaggio, verrà generato un errore, che avrà come risultato l'assegnazione di un punteggio negativo e il potenziale posizionamento nella cartella Posta indesiderata. Il processo viene descritto nella Figura 1.
Figura 1 Controllo nei record SPF dei messaggi in arrivo
Figura 1 Controllo nei record SPF dei messaggi in arrivo (Fare clic sull'immagine per ridurla)
Figura 1 Controllo nei record SPF dei messaggi in arrivo
Figura 1 Controllo nei record SPF dei messaggi in arrivo (Fare clic sull'immagine per ingrandirla)
Dopo che il messaggio è stato contrassegnato, SIDF consente al server di posta del destinatario di analizzare il messaggio in base ai comportamenti precedenti, alla reputazione del mittente, al contenuto e ad altri criteri che è possibile definire in base alle proprie esigenze. Questa capacità costituisce un'ulteriore misura di protezione. Gli spammer sono in grado, ad esempio, di registrare record SPF pubblicati e domini identici per trarre in inganno gli utenti e la rete di destinazione, inducendoli a pensare che la posta proviene da un mittente autorizzato. Anche se il messaggio di posta elettronica è in grado di superare il controllo di autenticazione, la reputazione del mittente come spammer è sufficiente perché il messaggio venga bloccato, contrassegnato come posta indesiderata o eliminato.

Opzioni di distribuzione dell'ID mittente
L'autenticazione della posta elettronica in uscita tramite SIDF non richiede modifiche all'infrastruttura o aggiornamenti software e non è specifica per il software client o server. Le organizzazioni che intendono incorporare l'autenticazione in ingresso per proteggere le relative società e i rispettivi dipendenti dovranno, tuttavia, aggiornare i sistemi in ingresso e l'agente di trasferimento messaggi (MTA), nonché distribuire software o apparecchiature che supportino SIDF. La maggior parte dei più importanti fornitori di prodotti per la protezione da posta indesiderata e agenti di trasferimento messaggi commerciali e open source, tra cui Microsoft® Exchange Server e Exchange Hosted Filtering, offre soluzioni integrate.
Microsoft ha integrato SIDF in tutti i prodotti di messaggistica, compresi Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express e i client di collaborazione e messaggistica di Office Outlook.
Persino Microsoft non è tuttavia esente dalla ricezione di posta indesiderata. Il traffico giornaliero medio in ingresso in Microsoft è di circa 15 milioni di messaggi e, durante i recenti attacchi di spamming, si è registrato un numero di messaggi da due a quattro volte superiore. In un ambiente di questo tipo un metodo valido in grado di garantire una corretta protezione dalla posta indesiderata consiste nell'implementazione accurata delle tecnologie disponibili.
Microsoft offre una soluzione di protezione da posta indesiderata interna di Exchange Server basata sul filtro dell'ID mittente in Exchange Server 2003 e sull'agente dell'ID mittente in Exchange Server 2007. In entrambe le versioni di Exchange Server, lo stato dell'ID mittente è basato sulla valutazione del record dell'ID mittente che risiede sui server DNS corrispondenti. Il dominio effettivo viene determinato dall'analisi delle intestazioni dei messaggi RFC 2822 nel seguente ordine di priorità:
  1. Resent-Sender
  2. Resent-From
  3. Sender
  4. From
Il dominio del mittente (o l'entità responsabile dell'inserimento di un messaggio nel flusso di messaggistica, poiché i sistemi di posta elettronica sono autorizzati a inoltrare i messaggi per conto di altri server di posta) viene determinato dall'individuazione della prima definizione delle intestazioni sopra illustrate nell'ordine definito. Se non viene rilevata nessuna di queste intestazioni, SIDF utilizzerà il valore MAIL FROM definito nella specifica RFC 2821 del protocollo SMTP.

Configurazione dell'ID mittente
In Exchange Server 2007 l'agente dell'ID mittente può essere abilitato sui server in cui sia installato il ruolo Trasporto edge. Se l'agente dell'ID mittente viene abilitato, verranno filtrati tutti i messaggi che passano attraverso i connettori di ricezione: tutto il traffico non autenticato in arrivo (da origini esterne) sarà soggetto all'elaborazione dell'ID mittente. In Exchange Server 2003 lo stato dell'ID mittente viene reso permanente da server a server nel blob EXCH50. In Exchange Server 2007 è stato aggiunto anche ai metadati del messaggio. Nella destinazione finale entrambi vengono convertiti in una proprietà MAPI, per consentirne l'utilizzo futuro da parte dei client.
La configurazione del filtro dell'ID mittente in Exchange Server 2003, disponibile nelle proprietà Recapito messaggi, prevede solo l'impostazione della modalità di gestione delle convalide non riuscite in Exchange Server.
Per abilitare l'ID mittente in Exchange Server 2007, è sufficiente aprire l'Exchange Management Console per un server in cui sia configurato il ruolo Trasporto edge, fare clic sulla scheda Anti-spam, quindi selezionare ID mittente e, nel riquadro Azioni, fare clic su Attiva o Disattiva per abilitare/disabilitare l'agente dell'ID mittente, come illustrato nella Figura 2. Per abilitare/disabilitare l'ID mittente è inoltre possibile utilizzare l'Exchange Management Shell, come illustrato nella Figura 3.
Figura 2 Controlli di Exchange Management Console per l'agente dell'ID mittente in Exchange Server 2007
Figura 2 Controlli di Exchange Management Console per l'agente dell'ID mittente in Exchange Server 2007 (Fare clic sull'immagine per ridurla)
Figura 2 Controlli di Exchange Management Console per l'agente dell'ID mittente in Exchange Server 2007
Figura 2 Controlli di Exchange Management Console per l'agente dell'ID mittente in Exchange Server 2007 (Fare clic sull'immagine per ingrandirla)
Figura 3 Abilitazione dell'ID mittente mediante l'Exchange Management Shell
Figura 3 Abilitazione dell'ID mittente mediante l'Exchange Management Shell (Fare clic sull'immagine per ridurla)
Figura 3 Abilitazione dell'ID mittente mediante l'Exchange Management Shell
Figura 3 Abilitazione dell'ID mittente mediante l'Exchange Management Shell (Fare clic sull'immagine per ingrandirla)
Nella finestra di dialogo Proprietà ID mittente sarà indicato lo stato dell'agente, abilitato o disabilitato. Nella scheda Azione sono disponibili opzioni molto simili alle opzioni presenti in Exchange Server 2003 (vedere la Figura 4).
Figura 4 Proprietà delle azioni dell'agente dell'ID mittente in Exhange Server 2007
Figura 4 Proprietà delle azioni dell'agente dell'ID mittente in Exhange Server 2007 (Fare clic sull'immagine per ridurla)
Figura 4 Proprietà delle azioni dell'agente dell'ID mittente in Exhange Server 2007
Figura 4 Proprietà delle azioni dell'agente dell'ID mittente in Exhange Server 2007 (Fare clic sull'immagine per ingrandirla)
Non esiste alcun differenza sostanziale tra Exchange Server 2003 e Exchange Server 2007 in termini di funzionalità e implementazione dell'ID mittente. Per il filtro dell'ID mittente (in Exchange Server 2003) e per l'agente dell'ID mittente (in Exchange Server 2007) si utilizza lo stesso algoritmo sottostante per l'estrazione e la verifica. Anche la gamma delle azioni che è possibile eseguire è identica: Elimina messaggio (eliminazione automatica), Rifiuta messaggio (risposta di protocollo SMTP di livello 500) e Contrassegna messaggio con risultato ID mittente e continua l'elaborazione. Quest'ultima opzione rappresenta l'azione predefinita in entrambe le versioni di Exchange Server.
In Exchange Server 2007 i codici di stato FAIL e TempError possono attivare l'azione Rifiuta messaggio (in Exchange Server 2003 l'azione può essere attivata solo dal codice di stato FAIL). L'agente dell'ID mittente deve essere configurato in modo esplicito per l'attivazione dell'azione Rifiuta messaggio nei messaggi con il codice di stato TempError poiché, per impostazione predefinita, tali messaggi verranno accettati nel sistema, contrassegnati con il risultato dell'ID mittente ed elaborati in seguito.
Questa opzione di configurazione non viene esposta dall'interfaccia utente grafica, per configurare le azioni dell'ID mittente per il codice di stato TempError è necessario utilizzare l'Exchange Management Shell. Per forzare ad esempio l'agente dell'ID mittente a rifiutare messaggi con il codice di stato TempError, utilizzare il cmdlet dell'agente dell'ID mittente seguente:
Set-SenderIDConfig -TempErrorAction Reject
La gamma dei risultati dello stato dell'ID mittente e delle possibili azioni in Exchange Server 2007 è simile ai risultati del filtro dell'ID mittente di Exchange Server 2003, come illustrato nella Figura 5.
Figure 5 Azioni e stato dell'ID mittente in Exchange Server 2007 (Close Figure 5)

Stato dell'ID mittente | Descrizione | Azioni
Neutro | I dati dell'ID mittente pubblicati non hanno prodotto risultati espliciti | StampStatus
Pass | L'indirizzo IP si trova nel set consentito | StampStatus
Fail | L'indirizzo IP non si trova nel set consentito | StampStatus, Elimina o Rifiuta
SoftFail | L'indirizzo IP del PRA potrebbe non trovarsi nel set consentito | StampStatus
Nessuno | Non esistono dati pubblicati | StampStatus
TempError | Si è verificato un errore temporaneo, ad esempio la non disponibilità del server DNS | StampStatus o Reject
PermError | Si è verificato un errore irreversibile, ad esempio un errore nel formato del record | StampStatus
Exchange, se configurato per l'esecuzione di tale operazione, elimina solo i messaggi che non hanno superato il processo di verifica dell'ID mittente. Nessun altro risultato determinerà l'attivazione dell'azione di eliminazione del messaggio. I messaggi in arrivo a cui è stato assegnato lo stato Neutro, Nessuno, SoftFail, TempError o PermError verranno contrassegnati in modo appropriato e trasferiti per consentire ulteriori verifiche della posta indesiderata. In alcuni casi, quando il formato del messaggio non è corretto e manca l'indirizzo IP FROM, non è possibile contrassegnare nel messaggio lo stato dell'ID mittente. In questa situazione il messaggio non viene ignorato né rifiutato, ma viene trasmesso per consentirne un'ulteriore elaborazione senza lo stato dell'ID mittente impostato. Viene inoltre registrato un evento appropriato per informare gli utenti della presenza di un messaggio di questo tipo.
In Exchange Server 2007 la definizione dei domini dei mittenti e dei destinatari di Exchange Server che devono essere esclusi dalla verifica dell'ID mittente è piuttosto semplice. Questa opzione di configurazione è disponibile solo se si utilizza l'Exchange Management Shell. Per escludere, ad esempio, il dominio contoso.com dal filtro dell'ID mittente, eseguire il comando:
Set-SenderIDConfig -BypassedSenderDomains contoso.com
Analogamente, per escludere i messaggi inviati a specifici destinatari di Exchange Server dal filtro dell'ID mittente, eseguire il comando:
Set-SenderIDConfig -BypassedRecipients user@contoso.com
Per ottenere in Exchange Server 2007 i valori di configurazione dell'ID mittente impostati tramite i cmdlet dell'Exchange Management Shell ma non disponibili tramite l'interfaccia utente grafica, è sufficiente eseguire il comando Get-SenderIDConfig nell'Exchange Management Shell, come illustrato nella Figura 6.
Figura 6 Cmdlet di configurazione dell'ID mittente
Figura 6 Cmdlet di configurazione dell'ID mittente (Fare clic sull'immagine per ridurla)
Figura 6 Cmdlet di configurazione dell'ID mittente
Figura 6 Cmdlet di configurazione dell'ID mittente (Fare clic sull'immagine per ingrandirla)
È possibile utilizzare l'Exchange Management Shell per eseguire rapidamente la verifica manuale dell'indirizzo IP e del nome di dominio corrispondente. Per controllare lo stato dell'ID mittente, eseguire il comando:
Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>
Se il dominio non esiste, verrà visualizzato un risultato simile a quello mostrato nella Figura 7.
Figura 7 Verifica dello stato dell'ID mittente di un indirizzo
Figura 7 Verifica dello stato dell'ID mittente di un indirizzo (Fare clic sull'immagine per ridurla)
Figura 7 Verifica dello stato dell'ID mittente di un indirizzo
Figura 7 Verifica dello stato dell'ID mittente di un indirizzo (Fare clic sull'immagine per ingrandirla)

Vantaggi dell'ID mittente
Oltre agli ovvi benefici derivanti dall'autenticazione dei messaggi di posta elettronica e dalla riduzione della quantità di posta indesiderata ricevuta dagli utenti, il protocollo SIDF offre ulteriori vantaggi. Durante il processo di sviluppo del protocollo, Microsoft ha focalizzato l'attenzione su diversi obiettivi chiave, quali prestazioni, costo, distribuzione, scalabilità e interoperabilità.
SIDF esegue prima l'autenticazione del mittente di un messaggio di posta elettronica e successivamente consente di attribuire un punteggio relativo alla reputazione del mittente. Di conseguenza, questa tecnologia è in grado di ridurre in modo significativo il volume di messaggi di posta elettronica indesiderati e falsificati nonché di migliorare il recapito di messaggi autorizzati inviati da mittenti conosciuti e affidabili. La creazione di un record SPF è gratuita e le aziende che lo desiderino possono garantire la conformità con il protocollo SIDF senza alcuna difficoltà. Le organizzazioni che intendono garantire la conformità ai requisiti di un nuovo standard vanno sostenute. Con SIDF, la garanzia della conformità è semplice quanto la pubblicazione di un record SPF.
SIDF è stato sviluppato per operare all'interno del software esistente, ove possibile, e può essere utilizzato con un'ampia gamma di architetture di posta elettronica e di software client e server. Qualsiasi servizio di autenticazione, perché sia efficace, deve essere in grado di soddisfare le esigenze sia dei più piccoli server di posta domestici che degli ISP di grandi dimensioni. SIDF è in grado di supportare i requisiti di un singolo così come di migliaia di server di posta elettronica, oltre che dei server affidati in outsourcing ad altre organizzazioni.
Il 18 e 19 aprile del 2007, Microsoft e un consorzio industriale di oltre 30 organizzazioni e partner ospiteranno l'evento Authentication & Online Identity Summit a Boston, MA. Durante l'evento si esamineranno i case study e si offrirà un'analisi tecnica dell'ID mittente, descrivendo in dettaglio il valore di business dell'autenticazione della posta elettronica. Per ulteriori informazioni, visitare il sito Web all'indirizzo aotalliance.org/summit2007 (in inglese). Per informazioni su strumenti e risorse, è possibile visitare i siti Web microsoft.com/senderid e microsoft.com/exchange (in inglese).

Craig Spiezle è Director of Technology Strategy and Planning for Windows Live Safety presso Microsoft. In qualità di Product Manager per l'autenticazione della posta elettronica, Craig ha svolto un ruolo fondamentale nella promozione dell'ID mittente sul mercato. Craig, che ha iniziato la sua carriera professionale in Microsoft nel 1992, ha occupato diverse posizioni di responsabilità, tra cui marketing internazionale, strategie di supporto dei prodotti, OEM e sviluppo dei mercati emergenti.
Alexander Nikolayev è Program Manager in Microsoft ed è responsabile dei protocolli sul lato server, del modulo principale di trasporto e dei componenti di protezione dalla posta indesiderata per Exchange Server e Windows Server. Ha conseguito un MBA presso l'University of Mary. È possibile leggere le pubblicazioni di Alexander sul blog del team di Exchange all'indirizzo blogs.technet.com/exchange (in inglese).


 Editoriale: Una comunit&#224; sempre pi&#249; ampia
Editoriale
Una comunità sempre più ampia

TECHNET MAGAZINE È MOLTO più della fantastica pubblicazione già sotto i vostri occhi oggi. Il team di redattori e tecnici ha lavorato a ritmi serrati per creare un nuovo sito Web all'avanguardia, che renderà i contenuti accessibili a oltre un miliardo di persone in tutto il mondo. A partire dal numero di novembre, ogni articolo sarà disponibile in linea in sette lingue: inglese, spagnolo, francese, tedesco, russo, cinese semplificato e portoghese brasiliano. L'aggiunta di altre sei lingue (senza contare l'inglese che è la lingua di origine della pubblicazione), consente di ampliare il numero delle persone in grado di accedere ai contenuti nella propria lingua madre a oltre 1,6 miliardi. Un risultato incredibile.
Sono state inoltre aggiunte una serie di funzionalità che rendono il sito molto più semplice da utilizzare. I nuovi feed RSS personalizzabili consentono di scegliere i contenuti in base a data, articolo, autore o argomento. È inoltre possibile combinare e verificare le corrispondenze degli articoli. Per creare un filtro personalizzato, visitare il sito technetmagazine.com/rss.
Sono in fase di pubblicazione anche nuove pagine tematiche. Per ottenere informazioni su tutto ciò che i professionisti dell'IT devono fare per prepararsi all'avvento di Windows Vista, visitare il sito all'indirizzo technetmagazine.com/vista. Se si gestisce un server di posta elettronica, il sito a cui ricorrere per informazioni è technetmagazine.com/exchange. Sono già disponibili 32 argomenti sul sito technetmagazine.com/topics e molti altri arriveranno presto (a novembre gli articoli sulla protezione in attesa di essere sfogliati erano 43).
Non è tutto. Ora è possibile leggere informazioni più dettagliate e aggiornate sulla rivista e sul mondo dell'IT professionale. Joshua Hoffman, Technical and Acquisitions Editor di TechNet Magazine, gestisce il blog della rivista consultabile all'indirizzo blogs.technet.com/tnmag. Io invece mi occupo di un podcast mensile dedicato al sito, disponibile all'indirizzo www.technetmagazine.com/podcasts. In ciascuna puntata ospiterò le persone che scrivono gli articoli pubblicati nella rivista, cercando di andare oltre la parola scritta e approfondire gli argomenti esposti negli articoli. Sarà senza dubbio interessante sentire gli autori più apprezzati parlare dei propri articoli e della propria attività.
Ci sono tutti i presupposti per fare di TechNet Magazine la risorsa più utile del globo per i professionisti dell'IT. Il 2006 è stato un ottimo anno, ma è sempre importante ottenere dai lettori commenti e suggerimenti. Basta inviare poche righe all'indirizzo tnmag@microsoft.com. La cassetta dei suggerimenti è sempre aperta.
£JOSHUA TRUPIN

Un grazie ai seguenti esperti e tecnici di Microsoft: Kevin Allison, Jessica Arnold, Sebastian Bengochea, Naveen Chand, Li Chen, Alpa Dave, Jill Frank, Mihai Jalobeanu, Darcy Jayne, Harry Katz, Kerry Landen, Todd Luttinen, Brett Muzzey, Bruce Payette, Tony Smith, Shawn Thomas, Jim Truher e Scot Vidican.


 Toolbox: Nuovi prodotti per i professionisti dell'IT
Toolbox
Nuovi prodotti per i professionisti dell'IT
Greg Steen

Test di stress delle applicazioni Web
WAPT: strumento per i test di stress delle applicazioni Web
www.loadtestingtool.com (in inglese)
La conoscenza del livello di prestazioni dell'ultima versione dell'applicazione Web creata è di capitale importanza per il corretto dimensionamento dell'infrastruttura, oltre che per evitare momenti di forte pressione quando il CEO chiede i motivi della visualizzazione di un messaggio di indisponibilità del server durante l'accesso al sito. Se si cerca uno strumento per eseguire test di prestazioni e stress delle applicazioni Web di facile utilizzo e relativamente economico, è una buona idea consultare la documentazione dello strumento WAPT 4.0 di SoftLogica LLC.
Sebbene questa applicazione venga eseguita sulla maggior parte delle versioni di Windows®, è consigliabile utilizzare Windows 2000, Windows XP o Windows Server® 2003, poiché le limitazioni relative ai socket delle versioni precedenti impediscono di sfruttarne al massimo le potenzialità. Come la maggior parte delle applicazioni di test delle prestazioni che prevedono l'utilizzo di utenti virtuali, il numero di utenti virtuali che è possibile simulare con WAPT è direttamente proporzionale alla quantità di memoria, alla velocità del processore e al numero di connessioni di rete in uso.
Nella documentazione viene indicato un limite di circa 2.000 utenti virtuali per un processore PIV 2.4 con 512 MB di RAM e un'interfaccia Gigabit Ethernet. Il limite dipende tuttavia dal tipo di applicazione sottoposta a test e dalla modalità di impostazione del profilo di test. Un altro fattore da cui dipende il test è rappresentato dal ritardo tra le richieste, che WAPT consente di impostare nel profilo di un utente virtuale come periodo di riflessione dell'utente.
Una volta impostato il profilo di un utente virtuale (sfruttando magari uno dei tanti scenari per test), è possibile creare il piano di test per il profilo in questione. In WAPT la sequenza di test è suddivisa in tre sezioni: azioni iniziale, principale e finale. Queste separazioni, più logiche che funzionali, suggeriscono di suddividere ad esempio la funzione di accesso o registrazione nella sezione iniziale e l'azione di disconnessione nella sezione finale. WAPT consente di immettere le richieste manualmente o utilizzare il registratore browser integrato per tenere traccia della modalità di esplorazione del sito da parte degli utenti di questo profilo. È possibile inoltre passare alle impostazioni generali per determinare il tipo di carico desiderato per il test da eseguire e specificare se si desidera che tale carico sia fisso o dipendente dal volume in un determinato periodo di tempo. Durante il test, WAPT è in grado di fornire una visualizzazione in tempo reale delle statistiche delle prestazioni per lo scenario di test corrente. Al termine, è possibile salvare i risultati in formato HTML o CSV per riferimento futuro.
Prezzo: $350 per computer.
La conoscenza del livello di prestazioni dell'ultima versione dell'applicazione Web creata è di capitale importanza per il corretto dimensionamento dell'infrastruttura, oltre che per evitare momenti di forte pressione quando il CEO chiede i motivi della visualizzazione di un messaggio di indisponibilità del server durante l'accesso al sito. Se si cerca uno strumento per eseguire test di prestazioni e stress delle applicazioni Web di facile utilizzo e relativamente economico, è una buona idea consultare la documentazione dello strumento WAPT 4.0 di SoftLogica LLC.
Sebbene questa applicazione venga eseguita sulla maggior parte delle versioni di Windows®, è consigliabile utilizzare Windows 2000, Windows XP o Windows Server® 2003, poiché le limitazioni relative ai socket delle versioni precedenti impediscono di sfruttarne al massimo le potenzialità. Come la maggior parte delle applicazioni di test delle prestazioni che prevedono l'utilizzo di utenti virtuali, il numero di utenti virtuali che è possibile simulare con WAPT è direttamente proporzionale alla quantità di memoria, alla velocità del processore e al numero di connessioni di rete in uso.
WAPT: strumento per i test di stress delle applicazioni Web
WAPT: strumento per i test di stress delle applicazioni Web (Fare clic sull'immagine per ridurla)
WAPT: strumento per i test di stress delle applicazioni Web
WAPT: strumento per i test di stress delle applicazioni Web (Fare clic sull'immagine per ingrandirla)
Nella documentazione viene indicato un limite di circa 2.000 utenti virtuali per un processore PIV 2.4 con 512 MB di RAM e un'interfaccia Gigabit Ethernet. Il limite dipende tuttavia dal tipo di applicazione sottoposta a test e dalla modalità di impostazione del profilo di test. Un altro fattore da cui dipende il test è rappresentato dal ritardo tra le richieste, che WAPT consente di impostare nel profilo di un utente virtuale come periodo di riflessione dell'utente.
Una volta impostato il profilo di un utente virtuale (sfruttando magari uno dei tanti scenari per test), è possibile creare il piano di test per il profilo in questione. In WAPT la sequenza di test è suddivisa in tre sezioni: azioni iniziale, principale e finale. Queste separazioni, più logiche che funzionali, suggeriscono di suddividere ad esempio la funzione di accesso o registrazione nella sezione iniziale e l'azione di disconnessione nella sezione finale. WAPT consente di immettere le richieste manualmente o utilizzare il registratore browser integrato per tenere traccia della modalità di esplorazione del sito da parte degli utenti di questo profilo. È possibile inoltre passare alle impostazioni generali per determinare il tipo di carico desiderato per il test da eseguire e specificare se si desidera che tale carico sia fisso o dipendente dal volume in un determinato periodo di tempo. Durante il test, WAPT è in grado di fornire una visualizzazione in tempo reale delle statistiche delle prestazioni per lo scenario di test corrente. Al termine, è possibile salvare i risultati in formato HTML o CSV per riferimento futuro.
Prezzo: $350 per computer.

Recensione del libro
Content Networking Fundamentals
www.ciscopress.com (in inglese)
I contenuti sono di grande interesse e Content Networking Fundamentals (Cisco Press, 2006) di Silvano Da Ros offre la possibilità di migliorare l'infrastruttura di distribuzione dei contenuti. Il libro, come il titolo suggerisce, è "un'introduzione completa alle nozioni teoriche e alle applicazioni pratiche delle soluzioni di content networking per la distribuzione dei contenuti". Sebbene sia orientato naturalmente verso i dispositivi di rete Cisco, il libro fornisce un valido prospetto generale dei diversi componenti del content networking, oltre a indicazioni pratiche per l'implementazione dei principi alla base del content networking che è possibile applicare indipendentemente dai tipi di prodotti di content networking presenti nell'infrastruttura.
Il libro inizia con una panoramica generale dei diversi elementi delle soluzioni di content networking (che sta effettivamente determinando un miglioramento delle prestazioni e del recapito delle comunicazioni ai livelli da 4 a 7 del modello OSI). Vengono quindi illustrati in modo approfondito gli elementi strutturali dei principali formati di presentazione dei contenuti, quali XML, HTML, WAP, e della conversione dei contenuti tramite XSLT all'ingresso nella rete nonché una sezione relativa alla consegna di flussi multimediali. Infine, viene fornita una descrizione dei livelli di scalabilità e disponibilità con considerazioni sul bilanciamento del carico del server (globale e locale), sul bilanciamento del carico del firewall e sull'utilizzo dei dispositivi di memorizzazione nella cache dei contenuti come il Content Services Switch (CSS) di Cisco.
Se nell'infrastruttura si utilizzano i Content Services Switch di Cisco, il capitolo sullo scambio di contenuti protetti risulterà particolarmente interessante. In questo capitolo è illustrata nel dettaglio la configurazione del modulo dei servizi di contenuti per Secure Sockets Layer e la configurazione della riscrittura degli URL e delle intestazioni. In generale il capitolo su QoS risulterà particolarmente utile per i professionisti di rete di qualsiasi tipo, per la comprensione dei diversi meccanismi di accodamento e delle procedure di gestione dei problemi di congestione.
In conclusione, sebbene centrato sulle implementazioni hardware di Cisco (dopo tutto è stato pubblicato da Cisco Press), il libro consente di convertire i termini ormai ampiamente diffusi di "content networking" in metodologie pratiche e applicabili per l'infrastruttura di distribuzione dei contenuti creata.
Prezzo: $55.00.

Monitoraggio dei servizi
WebWatchBot
www.exclamationsoft.com/webwatchbot/default.asp (in inglese)
Una caratteristica che decreta il successo o l'insuccesso di un professionista IT è la capacità di rilevare ed eventualmente correggere i problemi prima che vengano rilevati dagli utenti finali dell'organizzazione. Uno dei più importanti strumenti che un professionista dell'IT può avere a disposizione è un sistema di monitoraggio efficiente in grado di esaminare in profondità i diversi servizi forniti per verificarne il corretto funzionamento. WebWatchBot di ExclamationSoft è stato specificamente progettato a tale scopo.
L'applicazione è in grado di monitorare qualsiasi servizio comune esistente. WebWatchBot, anziché verificare semplicemente se un servizio è in esecuzione, perfeziona ulteriormente questo processo, eseguendo il test dei servizi per verificare che funzionino in modo corretto. La verifica FTP consente ad esempio il caricamento e il download di un file, il monitoraggio DNS consente di eseguire uno dei 40 comandi di query disponibili e di cercare una stringa nella risposta e i test POP3 e SMTP consentono di accedere alla posta elettronica e creare un rapporto sulle relative prestazioni.
WebWatchBot
WebWatchBot (Fare clic sull'immagine per ridurla)
WebWatchBot
WebWatchBot (Fare clic sull'immagine per ingrandirla)
WebWatchBot consente inoltre di concatenare una sequenza di passaggi in una transazione ed è in grado di segnalare eventuali errori o tempi di latenza inaccettabili (in base alla soglia impostata) per l'intera transazione. L'applicazione è in grado inoltre di monitorare gli URL HTTP e HTTPS e di controllare contenuti specifici. È possibile persino impostare il monitoraggio dei database, che prevede l'esecuzione di query e la verifica dei dati in base a una risposta basata su modelli.
Prezzo: $495,95 per licenza individuale.

Greg Steen è un professionista dell'IT, un imprenditore e un appassionato costantemente alla ricerca di nuovi strumenti e metodi che consentano di semplificare le operazioni e il processo di sviluppo per i professionisti dell'IT.


 Windows PowerShell: Comandi semplici, amministrazione perfetta
Windows PowerShell
Comandi semplici, amministrazione perfetta
Don Jones
L'articolo è basato sulla versione preliminare di Windows PowerShell e le informazioni riportate sono soggette a modifiche.

L'attesa è stata lunga, ma Windows PowerShell è quasi pronto per il lancio ed è bene che tutti gli amministratori di Windows inizino a prendere nota. Windows PowerShell rappresenta probabilmente lo strumento più semplice e flessibile per l'automazione di un'ampia gamma di attività di amministrazione, in grado di rendere il lavoro di ogni giorno più efficace ed efficiente.
L'aspetto di rilevanza ancora maggiore è la creazione da parte di Microsoft delle console grafiche di amministrazione di prodotti quali Exchange Server 2007 e System Center 2007, oltre a Windows PowerShell™. Sarà quindi possibile eseguire quasi tutte le attività di amministrazione da Windows PowerShell. In Microsoft si sta pianificando di seguire in futuro la stessa strada per l'amministrazione di altri prodotti. Windows PowerShell è destinato dunque a diventare il primo strumento multiuso per l'amministrazione di qualsiasi prodotto server di Microsoft. Windows PowerShell sarà l'oggetto di questa nuova rubrica periodica, destinata ad aggiornare tutti gli utenti su questa importante novità. Prima di iniziare, è consigliabile scaricare una copia del software.

Potenza e semplicità
Come suggerito dal nome, Windows PowerShell è una shell, non diversa dal prompt dei comandi (Cmd.exe) in uso fin dai tempi di Windows NT® 3.1. Cmd.exe resterà disponibile, ma con l'avvento di Windows PowerShell i motivi per ricorrere alla vecchia shell diventeranno sempre meno numerosi.
L'utilizzo di Windows PowerShell non differisce molto da Cmd.exe, se non per il fatto che Windows PowerShell è molto più potente. Come già in Cmd.exe, in Windows PowerShell è integrato un linguaggio di scripting, molto più flessibile del primitivo linguaggio batch di Cmd.exe. Una flessibilità davvero notevole. Basti pensare che con Windows PowerShell è possibile automatizzare attività estremamente complesse con un linguaggio che comprende non più di sei parole chiave incorporate.
Detto delle funzionalità di scripting, occorre citare la protezione. In Windows PowerShell si concentra l'esperienza accumulata da Microsoft nel campo della protezione in oltre dieci anni. Per impostazione predefinita con Windows PowerShell non si eseguono script, ma solo singoli comandi in modo interattivo. Quando si attiva lo scripting, è possibile impostare Windows PowerShell in modo che esegua esclusivamente script dotati di firma digitale. Tutti questi accorgimenti sono volti a evitare che Windows PowerShell diventi il nuovo VBScript, un ottimo linguaggio che è stato utilizzato spesso per scopi non leciti e per creare script dannosi. Neanche VBScript è destinato alla dismissione, ma Windows PowerShell risulterà di certo di più facile utilizzo in molte attività.
Con Windows PowerShell è possibile eseguire quasi tutte le operazioni che si eseguono di solito con Cmd.exe. È, ad esempio, possibile eseguire ipconfig per ottenere i soliti risultati nel formato già noto. In compenso in Windows PowerShell è disponibile una serie di comandi del tutto nuovi che non sono file eseguibili esterni. I nuovi cmdlet (si pronuncia "command-let") sono già incorporati in Windows PowerShell. Un esempio dei cmdlet più utili per iniziare a utilizzare Windows PowerShell è nel riquadro "I 10 cmdlet da utilizzare subito".
I 10 cmdlet da utilizzare subito
  • Get-Command consente di recuperare un elenco di tutti i cmdlet disponibili.
  • Get-Help consente di visualizzare le informazioni della guida in linea su cmdlet e concetti.
  • Get-WMIObject viene utilizzato per recuperare informazioni di gestione con WMI.
  • Get-EventLog consente di recuperare i registri eventi di Windows.
  • Get-Process consente di recuperare un singolo processo attivo o un elenco di processi attivi.
  • Get-Service viene impiegato per recuperare un servizio Windows.
  • Get-Content consente di leggere un file di testo, le cui righe vengono trattate ciascuna come un oggetto figlio.
  • Add-Content consente di aggiungere del contenuto a un file di testo.
  • Copy-Item consente di copiare file, cartelle e altri oggetti.
  • Get-Acl si utilizza per recuperare gli elenchi di controllo degli accessi (ACL).
Per un elenco completo dei cmdlet disponibili in Windows PowerShell, visitare il sito windowssdk.msdn.microsoft.com/en-us/library/ms714408.aspx (in inglese).
Tutti i cmdlet sono denominati con un formato standard verbo-nome per facilitarne apprendimento e memorizzazione. Con l'esecuzione del cmdlet Get-Command, ad esempio, si ottiene l'elenco di tutti i cmdlet disponibili. Il cmdlet più utile per un amministratore è, probabilmente, Get-WMIObject. Si supponga che sia necessario sapere quale service pack è eseguito da Server2. È sufficiente scrivere:
Get-WMIObject Win32_OperatingSystem –Property ServicePackMajorVersion
 –Computer Server2
Per ottenere le stesse informazioni con VBScript, è necessario scrivere più righe di codice. Altri cmdlet consentono di operare con servizi (Start-Service, Stop-Service e così via), processi (Stop-Process e altri), file (ad esempio, Rename-Item, Copy-Item, Remove-Item, Move-Item) e molto altro ancora. Per molti dei cmdlet sono addirittura previsti nomi abbreviati, detti alias. Nel caso di Get-WMIObject è, ad esempio, possibile scrivere gwmi. Per ottenere un elenco dei nomi abbreviati, si esegue il cmdlet Get-Alias.

Vantaggi dell'orientamento agli oggetti
Windows PowerShell è stato creato sulla base di Microsoft® .NET Framework, quindi è completamente orientato agli oggetti. In genere solo gli sviluppatori di software apprezzano questa caratteristica, ma nel caso di Windows PowerShell l'orientamento agli oggetti rappresenta un notevole risparmio di tempo anche per gli amministratori. Tale risparmio di tempo deriva dalla possibilità di lavorare direttamente con gli oggetti da una shell basata su testo. Ecco un esempio:
Get-Process | Sort-Object pm –desc | Select-Object –first 10
Questa è una singola riga con tre diversi cmdlet separati da pipe (il discorso sulle pipeline sarà approfondito più avanti). Con il primo cmdlet si recuperano tutti i processi in esecuzione che vengono quindi passati, tramite pipeline, come oggetti a Sort-Object. Con il secondo cmdlet si esegue l'ordinamento in base alla proprietà pm (ovvero Physical Memory, memoria fisica) di ciascun oggetto processo in ordine decrescente. La serie ordinata degli oggetti processo viene quindi passata tramite pipeline a Select-Object, con cui vengono scelti e visualizzati i primi 10. Risultato finale: con questa semplice riga è possibile visualizzare i 10 processi in esecuzione sul computer che consumano più memoria fisica, come illustrato nella Figura 1. Si tratta dunque di un metodo molto efficace per ottenere informazioni in modo rapido durante la risoluzione dei problemi di un sistema.
Figura 1 Utilizzo di un semplice cmdlet per la risoluzione dei problemi
Figura 1 Utilizzo di un semplice cmdlet per la risoluzione dei problemi (Fare clic sull'immagine per ridurla)
Figura 1 Utilizzo di un semplice cmdlet per la risoluzione dei problemi
Figura 1 Utilizzo di un semplice cmdlet per la risoluzione dei problemi (Fare clic sull'immagine per ingrandirla)
L'impiego di pipe (il carattere con una linea verticale che nelle tastiere italiane si trova in genere sopra il tasto della barra rovesciata) è una delle chiavi dell'efficienza di Windows PowerShell. Grazie al carattere pipe è possibile passare (tramite pipeline, appunto) degli oggetti da un cmdlet a un altro, consentendo ulteriori perfezionamenti dei risultati, la formattazione per la visualizzazione e così via. Il meccanismo funziona perché ciascun cmdlet restituisce uno o più oggetti, invece di semplice testo, fornendo ai cmdlet successivi un intero oggetto su cui lavorare.
L'impiego degli oggetti in Windows PowerShell è pervasivo fino a comprendere anche le variabili. Nemmeno è necessario dichiarare le variabili; è sufficiente iniziare direttamente a utilizzarle anteponendo un simbolo di dollaro ($) al nome della variabile. Sebbene non sia necessario, è possibile passare a Windows PowerShell informazioni sul tipo di dati da inserire nella variabile. In Windows PowerShell la variabile viene in questo modo associata a uno dei potenti tipi di .NET Framework, rendendo disponibili una serie di altre funzionalità incorporate. Si supponga, ad esempio, di dover richiedere il nome di un computer e recuperare la versione del service pack da tale computer, senza però sapere se la persona che digita il nome del computer utilizzerà o meno le due barre rovesciate (come in \\Server2). Con il cmdlet Get-WMIObject le barre rovesciate non sono necessarie, quindi è possibile salvare il nome del computer in una variabile String e utilizzare il metodo Replace per sostituire le barre rovesciate con stringhe vuote, come di seguito:
[string]$c = Read-Host "Enter computer name"
$c = $c.Replace("\","")
    Get-WMIObject Win32_OperatingSystem
    –Property  ServicePackMajorVersion
    –Computer $c
Il valore del parametro –Computer è stato fornito nella variabile $c. La variabile è stata creata inizialmente come una stringa, in cui è stata quindi raccolta l'intera funzionalità del tipo String di .NET Framework, compreso il metodo Replace. È certo necessario qualche tempo per apprendere tutte le funzioni disponibili, ma attenendosi agli esempi è molto facile imparare a utilizzarle. Anche Windows PowerShell contribuisce a semplificare l'apprendimento. Se, ad esempio, si digita $c = $c. (fare attenzione a digitare anche il punto) e si preme il tasto Tab, in Windows PowerShell verrà visualizzato Clone(), il primo metodo del tipo String. Se si preme ancora Tab, in Windows PowerShell verranno visualizzati di volta in volta tutti i metodi disponibili. In pratica in Windows PowerShell con questa operazione vengono indicati tutti i metodi applicabili al tipo String.
Ora è possibile passare a un'attività più complessa. Leggere un elenco di nomi di computer da un file, con un nome per riga, e visualizzare il numero di versione del service pack di ciascun computer. In VBScript un'attività di questo genere richiede più di una dozzina di righe di codice. In Cmd.exe è necessario creare e utilizzare un complesso file batch. In Windows PowerShell è sufficiente un'unica riga:
Get-Content "c:\computers.txt" | foreach
{ $_; gwmi Win32_OperatingSystem -prop
ServicePackMajorVersion -comp $_ }
Con il cmdlet Get-Content si legge il contenuto di C:\Computers.txt. Ciascuna riga del file diventa un oggetto a sé stante. Questa serie di oggetti, ovvero i nomi di computer, vengono passati tramite pipeline al comando foreach, un alias del cmdlet ForEach-Object. I comandi compresi in parentesi graffe vengono ripetuti una volta per ciascuno degli oggetti passati, nell'esempio una volta per ciascun nome di computer. La variabile speciale $_ conterrà l'oggetto corrente (vale a dire, il nome di computer corrente).
Tra parentesi graffe sono compresi due comandi: Con il primo si visualizza il nome del computer corrente tramite l'output del contenuto di $_. Il secondo è il già noto gwmi. Il risultato finale è un elenco di numeri di versione di service pack per ciascuno dei computer presenti nel file, ottenuto con una sola riga di comandi relativamente semplice.
È opportuno notare come i nomi dei parametri –Property e –Computer siano stati abbreviati. In Windows PowerShell è sufficiente indicare un nome che sia interpretabile in modo univoco.

Leggibilità e riutilizzo
La scrittura di una semplice riga di comandi e parametri, tuttavia, non migliora la leggibilità. In Windows PowerShell è possibile suddividere gli elementi della riga in modo che risultino più leggibili, digitabili direttamente nella shell senza che sia neanche necessario scrivere uno script. Il risultato è il seguente:
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> $name
>> gwmi Win32_OperatingSystem -prop ServicePackMajorVersion -comp $name
>> }
>>
Questa volta il contenuto del file viene archiviato nella variabile $names. Anche in questo esempio si utilizza foreach, ma senza input tramite pipeline. È dunque necessario indicare la serie di oggetti da includere nel ciclo e la variabile in cui archiviare ciascun oggetto, come nella sezione ($name in $names). Tutto il resto corrisponde praticamente all'esempio precedente e, non appena si preme Invio, il codice viene eseguito e il risultato visualizzato.
Per utilizzare più volte questo medesimo codice, è sufficiente derivarne una funzione. Digitare quanto segue direttamente nella shell:
PS C:\> function Get-ServicePacks ($file) {
>> $names = get-content $file
>> foreach ($name in $names) {
>> $name
>> gwmi win32_operatingsystem -prop servicepackmajorversion -comp $name
>> }
>> }
>>
Come si può osservare, non cambia molto. L'esempio precedente è stato semplicemente racchiuso in una funzione denominata Get-ServicePacks (per rispettare la convenzione di denominazione verbo-nome di Windows PowerShell). Per la funzione ora è disponibile un parametro di input denominato $file, che è stato sostituito nel cmdlet Get-Content in modo che sia possibile specificare un altro file all'esecuzione della funzione. Una volta definita la funzione, è sufficiente eseguirla richiamandone il nome, come accade con i cmdlet, e passando il parametro di input:
PS C:\> Get-ServicePacks c:\computers.txt
Nella Figura 2 è illustrato il risultato.
Lo svantaggio in questo caso è rappresentato dal fatto che la funzione esiste solo fino a che è in esecuzione l'istanza di Windows PowerShell. Dopo la chiusura della shell, infatti, la funzione non sarà più disponibile. È possibile copiare la funzione nel proprio profilo di Windows PowerShell, che è una sorta di script automatico che viene eseguito a ogni avvio di Windows PowerShell. In tal modo la funzione sarà disponibile in tutte le finestre di Windows PowerShell che si aprono. In alternativa è possibile trasformare la funzione in uno script autonomo, da eseguire con la semplice digitazione di percorso e nome file dello script.
Figura 2 Risultato dell'esecuzione della funzione Get-ServicePacks
Figura 2 Risultato dell'esecuzione della funzione Get-ServicePacks

Il mondo in un file (o cartella)
Windows PowerShell è molto più di funzioni e cmdlet. Si prendano, ad esempio, in considerazione le funzioni di gestione dei file. È probabile che il lettore sia più che esperto nella navigazione tra unità e cartelle in Cmd.exe: si digita C: per passare all'unità C e si digita cd \test per passare alla cartella C:\Test. Il funzionamento di Windows PowerShell è identico, anche se cd è solo un alias del cmdlet Set-Location.
Provare, ad esempio, a eseguire Get-PSDrive, il cmdlet che consente di visualizzare un elenco di tutte le unità disponibili. Oltre alle solite unità C:, D: e, forse, A: si noterà la presenza di un'unità Cert, di un'altra denominata Env e di altre ancora denominate HKCU e HKLM. In effetti in Windows PowerShell vengono indicati come "unità" molti tipi di risorse di archiviazione diversi, come l'archivio certificati locale, le variabili di ambiente e il registro accessibili tramite un'interfaccia di tipo file/cartella molto familiare.
Passare all'hive del registro di sistema HKEY_LOCAL_MACHINE digitando Set-Location HKLM: (o cd hklm: per abbreviare) e premendo Invio. Eseguire quindi cd software\microsoft per passare alla chiave SOFTWARE\Microsoft. È possibile utilizzare dir, un alias del cmdlet Get-ChildItem, per visualizzare l'elenco delle sottochiavi presenti in questa porzione del registro di sistema. Per rimuovere una chiave, utilizzare il tasto Canc come se la chiave fosse un file o una cartella (prestando la dovuta attenzione, poiché la rimozione di chiavi necessarie o la modifica non corretta delle chiavi può provocare gravi problemi di funzionamento).
Tutta questa flessibilità deriva dai provider, che consentono di mappare le risorse (come registro di sistema e archivio certificati) in un formato di aspetto simile a un file system. In Microsoft si prevede di estendere l'utilizzo di Windows PowerShell ad altri provider, in modo da consentire agli utenti, ad esempio, di visualizzare un archivio di Exchange Server come fosse un file system. L'importanza di questa tecnica risiede nella possibilità di visualizzare secondo uno standard identico i tanti archivi utilizzati da Windows e di utilizzare per la gestione un sistema di comandi e tecniche già noti alla grande maggioranza degli utenti.

Protezione in primo piano
Si è già ricordato come Windows PowerShell sia stato progettato tenendo sempre in primo piano le esigenze di protezione e sicurezza. La prima barriera di protezione di Windows PowerShell sono i criteri di protezione. Questi criteri sono impostati in modo predefinito su Restricted, come è facile verificare eseguendo il cmdlet Get-ExecutionPolicy. In modalità Restricted gli script non vengono semplicemente eseguiti. Trattandosi della modalità predefinita, non è possibile utilizzare Windows PowerShell per eseguire script già pronti.
Con il cmdlet Set-ExecutionPolicy è possibile specificare altre modalità. La modalità probabilmente più efficace è RemoteSigned, che consente di eseguire gli script locali (ma non remoti) privi di firma digitale, facilitando lo sviluppo e la verifica degli script in locale. Nella modalità AllSigned è possibile eseguire esclusivamente script con firma digitale, con l'utilizzo di un certificato emesso da un autore attendibile. Nella modalità Unrestricted, infine, vengono eseguiti tutti gli script. Non è consigliabile adottare questa modalità, poiché apre Windows PowerShell all'esecuzione di script dannosi che potrebbero avere effetti deleteri sul computer. È da sottolineare che è possibile controllare i criteri di esecuzione anche tramite Criteri di gruppo, con cui si sostituiscono tutte le impostazioni locali (se un'impostazione di Criteri di gruppo sostituisce un'impostazione locale, si ottiene un avviso da Set-ExecutionPolicy).
In Windows PowerShell, inoltre, non vengono eseguiti script dalla directory corrente, a meno che non si specifichi l'intero percorso. L'intento è quello di evitare manipolazioni dei comandi dall'esterno. Si supponga, ad esempio, che qualcuno abbia creato uno script denominato IPConfig.ps1 (PS1 è l'estensione dei file di script di Windows PowerShell). Se fosse possibile eseguire i file dalla cartella corrente, esisterebbe il rischio, dopo aver digitato ipconfig, di eseguire questo script creato da un utente invece del programma Ipconfig.exe di Windows, come invece previsto. L'errore non può verificarsi perché in Windows PowerShell non è possibile eseguire script dalla cartella corrente. Se invece si desidera eseguire uno script dalla cartella corrente, è sufficiente specificare il percorso: ad esempio, .\myscript. Il riferimento esplicito alla cartella corrente garantisce della consapevolezza da parte dell'utente di voler eseguire uno script e non un comando della shell.
In Windows PowerShell sono disponibili inoltre funzionalità che rendono meno pericolosi gli esperimenti. Si prenda ad esempio questa inquietante combinazione (senza provare ad eseguirla):
Get-Process | Stop-Process
Con il cmdlet Get-Process si crea una serie di oggetti processo che vengono quindi passati tramite pipeline al cmdlet Stop-Process per bloccarli. Il risultato è un errore di STOP con schermata blu entro circa cinque secondi, dopo il blocco dei processi fondamentali di Windows. Se si aggiunge il comodo parametro –Whatif, è tuttavia possibile provare gli effetti dei cmdlet senza eseguire davvero l'operazione:
Get-process | Stop-Process -Whatif
Il risultato dell'esecuzione in Windows PowerShell è una serie di frasi che descrivono le azioni eseguite dai cmdlet senza che vengano realmente eseguite. Nel sistema di guida in linea di Windows PowerShell (accessibile tramite l'alias help) il parametro –Whatif non è ancora documentato, ma è bene ricordarlo. Si tratta di uno strumento molto utile per sottoporre script e cmdlet a test e verificare i risultati, senza eseguire alcuna operazione potenzialmente dannosa.

Conclusione
Delle altre funzionalità non sono state incluse in questa versione di Windows PowerShell, forse la più importante è il supporto di ADSI (Active Directory® Services Interface). In Windows PowerShell è possibile utilizzare le robuste classi .NET che interagiscono già con Active Directory e altri servizi di directory, ma non è ancora disponibile un cmdlet Get-ADSIObject. Ne consegue una certa difficoltà nella gestione di oggetti directory.
In Windows PowerShell è, inoltre, possibile adottare più modalità diverse per eseguire la medesima attività. Questa è di certo un vantaggio, che può di contro allungare i tempi di apprendimento di Windows PowerShell quando per ciascuna attività vengono diffusi cinque o sei esempi diversi.
Con il passare del tempo verranno sistemati anche questi aspetti e il team di Windows PowerShell continuerà ad aggiungere nuove funzionalità al prodotto. Per restare sempre aggiornati, visitare il blog del team.

Don Jones è il fondatore di ScriptingAnswers.com e il coautore di Windows PowerShell: TFM (SAPIEN Press, 2006). È possibile contattarlo scrivendo all'indirizzo don@scriptinganswers.com.


 Post Mortem: Migrazione da Exchange 5.5
Post Mortem
Migrazione da Exchange 5.5
Whitney Roberts

IL PROGETTO
Il Kentucky Department of Education si è trovato nella necessità di eseguire la migrazione dall'implementazione di Microsoft® Exchange Server 5.5 esistente a Exchange Server 2003. Il sistema supporta circa 600.000 entità tra facoltà, personale e studenti nel corso di un anno scolastico.
GLI ATTORI
Il progetto è stato gestito dall'Office of Education Technology (OET) del Kentucky Department of Education, con l'assistenza dei consulenti di KiZAN Technologies. Lo staff OET era responsabile della supervisione della gestione dell'implementazione esistente di Exchange 5.5. La gestione giornaliera dei server di Exchange spettava al personale locale dei distretti scolastici.
LE SFIDE
Il Department of Education impartisce le direttive tecniche a tutti i 178 distretti scolastici del Commonwealth of Kentucky. I distretti scolastici sono collegati tra loro tramite una WAN, ma ciascuno ospita un proprio server Exchange 5.5 gestito localmente, che era quindi necessario aggiornare singolarmente. L'aggiornamento avrebbe consentito di usufruire di straordinari vantaggi, tra cui il supporto per i client in modalità cache di Outlook® 2003, prestazioni di Outlook Web Access (OWA) migliorate e uno schema di indirizzamento della posta elettronica standardizzato.
Oltre all'implementazione di una nuova infrastruttura client/server della posta elettronica, la maggior parte dei distretti scolastici stava aggiungendo il supporto per la posta elettronica degli studenti. Le normative statali e federali richiedevano la tutela della riservatezza delle informazioni degli studenti e la non visibilità di tali dati all'esterno del rispettivo distretto.
IL PIANO
Nell'impossibilità di utilizzare un Active Directory® Connector (ADC), si è creata una nuova organizzazione Exchange in cui è stata eseguita la migrazione. La standardizzazione degli indirizzi di posta elettronica ha determinato la creazione di nuovi sottodomini di identificazione per ciascun distretto scolastico e oltre 400 nuovi criteri del destinatario. La protezione degli indirizzi degli studenti richiedeva la creazione di un sistema di Elenchi indirizzi globali (GAL) e di elenchi di indirizzi personalizzati per ciascun distretto scolastico.
La migrazione effettiva comportava la gestione temporanea dei nuovi componenti hardware, la creazione e la configurazione delle cassette postali in base all'appartenenza al distretto e al tipo di utente e l'impostazione degli attributi di estensione in base all'appartenenza al distretto e al tipo di utente in modo che gli utenti venissero visualizzati negli elenchi di indirizzi appropriati.
È stata creata un'applicazione basata su Visual Basic® per rilevare e correggere eventuali errori di configurazione di attributi di account o appartenenze ai gruppi e per effettuare in modo corretto il provisioning delle nuove cassette postali, in modo da assicurare il rispetto dei requisiti di visibilità. L'applicazione è stata distribuita in tutti i 178 distretti e viene eseguita a intervalli stabiliti sui server dei distretti scolastici.

Introduzione
In apparenza questo lavoro potrebbe non sembrare complicato o tecnicamente difficoltoso. Tuttavia, questo progetto è un esempio lampante di come i requisiti aziendali abbiano sempre la predominanza assoluta su qualsiasi altra considerazione.
Nel corso degli anni la gestione decentralizzata e un guazzabuglio di standard hanno creato numerosi "silos" di supporto la cui gestione, nella maggior parte dei casi, era responsabilità del personale OET. Il personale OET aveva inoltre la responsabilità di verificare che l'implementazione di Exchange 5.5 soddisfacesse contemporaneamente i requisiti dei distretti scolastici e del Department of Education. Ne conseguiva che, per i distretti che utilizzavano la posta elettronica degli studenti, le informazioni degli studenti venivano protette e non erano visibili all'esterno del rispettivo distretto come stabilito dalle linee guida statali e federali (vedere ed.gov/policy/gen/guid/fpco/ferpa/index.html) (in inglese).
In Exchange 5.5 queste linee guida implicavano l'impossibilità di replicare le informazioni degli studenti all'interno di un distretto negli altri distretti scolastici o in altri enti statali che condividevano i dati degli Elenchi indirizzi globali. In particolare si determinava la necessità di eseguire un processo di esportazione/importazione manuale per ciascuno dei 178 siti di Exchange 5.5: nascondere gli studenti, replicare l'elenco, mostrare gli studenti e infine importare di nuovo l'elenco degli indirizzi. In tal modo gli altri distretti erano in grado di visualizzare solo i dati del personale, mentre il distretto scolastico proprietario era in grado di visualizzare tutti i propri dati, ma solo i dati del personale degli altri distretti scolastici.
Considerati i punti di forza e di debolezza del sistema esistente, l'aggiornamento dell'infrastruttura di messaggistica doveva soddisfare alcuni criteri specifici. Innanzitutto, il Kentucky Department of Education desiderava standardizzare l'intero ambiente aziendale in base a un comune schema di denominazione SMTP facilmente leggibile. Lo schema doveva fornire spazi di indirizzi SMTP separati per facoltà e studenti.
Il nuovo sistema doveva inoltre fornire un servizio gestito centralmente a cui sarebbe stata delegata la responsabilità, fino ad allora del distretto, della gestione della messaggistica e della garanzia della disponibilità, determinando quindi una centralizzazione della gestione della strategia di ripristino di emergenza, del flusso della posta e delle chiamate di supporto tecnico. Il nuovo sistema doveva pertanto fornire un metodo centralizzato per la standardizzazione della configurazione utente in tutti i distretti, indipendentemente dalla posizione geografica o dell'appartenenza al distretto di un determinato utente.
Questo sistema doveva inoltre garantire un accesso tramite dispositivi portatili protetto e basato sul Web alla posta elettronica attraverso uno spazio dei nomi comune e unificato per tutti i distretti.
Considerati questi requisiti, molti dei quali non erano stati ancora implementati nel sistema Exchange 5.5 esistente, l'aggiornamento a Exchange 2003 sembrava un compito piuttosto impegnativo.

Elementi di base della soluzione
Per soddisfare i requisiti aziendali, sono state prese in considerazione diverse opzioni specifiche di Exchange per lo scenario di distribuzione.
Data la mancanza di standardizzazione e l'enorme ampiezza dell'ambiente di Exchange 5.5, si è deciso di non utilizzare un ADC, optando per la creazione di una nuova organizzazione Exchange in cui è stata eseguita la migrazione.
La pulizia e la standardizzazione degli indirizzi di posta elettronica del personale e degli studenti in ciascun distretto ha determinato la creazione di oltre 400 nuovi criteri destinatario. I requisiti richiedevano la creazione di un sottodominio di identificazione univoco per ciascun distretto, inclusa la designazione di un distretto di identificazione per gli studenti. Nel caso, ad esempio, della contea di Shelby, il sottodominio principale sarebbe stato shelby.kyschools.us. Gli studenti in ciascun distretto sarebbero stati identificati con il sottodominio stu. e pertanto gli studenti della contea di Shelby avrebbero dovuto utilizzare gli indirizzi stu.shelby.kyschools.us.
Un altro vincolo era rappresentato dal fatto che gli indirizzi degli studenti dovevano essere visibili solo all'interno del distretto di appartenenza, mentre gli indirizzi del personale dovevano essere visibili in tutti i distretti. Si determinava quindi la creazione di un sistema sofisticato di Elenchi indirizzi globali ed elenchi di indirizzi personalizzati, come illustrato nella Figura 1 e nella Figura 2. Uno dei vantaggi della migrazione a Exchange 2003 era rappresentato dalla possibilità di proteggere gli elenchi degli indirizzi con autorizzazioni e di controllare l'accesso a ogni singolo elenco di indirizzi tramite l'appartenenza al gruppo. Mediante l'uso di questa funzionalità sono stati creati due gruppi di protezione a livello di distretto (uno per il personale e l'altro per gli studenti), quindi si è provveduto alla protezione degli Elenchi indirizzi globali e degli elenchi di indirizzi personalizzati del personale e degli studenti dei distretti corrispondenti in modo da consentire l'accesso a determinati elenchi di indirizzi solo agli account utente all'interno di uno specifico distretto. Dopo aver rimosso l'Elenco indirizzi globale e gli elenchi di indirizzi predefiniti e verificato che i gruppi Everyone e Authenticated Users non fossero presenti nell'elenco di controllo di accesso (ACL) per ciascun elenco di indirizzi, si è potuto preselezionare l'elenco di indirizzi che sarebbe stato visibile a un determinato tipo di utente in uno specifico distretto.
Figura 1 Elenchi di indirizzi personalizzati basati sul ruolo
Figura 1 Elenchi di indirizzi personalizzati basati sul ruolo (Fare clic sull'immagine per ridurla)
Figura 1 Elenchi di indirizzi personalizzati basati sul ruolo
Figura 1 Elenchi di indirizzi personalizzati basati sul ruolo (Fare clic sull'immagine per ingrandirla)
L'utilizzo delle autorizzazioni, tuttavia, consentiva di risolvere il problema della visibilità solo in parte. Si è presentata infatti la necessità di escogitare un metodo per controllare gli utenti visibili in uno specifico elenco di indirizzi. È stata creata pertanto una query LDAP di base che consentisse di eseguire una query sulla visibilità di personale e studenti; la query è stata successivamente personalizzata per ciascun elenco di indirizzi ed Elenco indirizzi globale. La query LDAP per l'Elenco indirizzi globale del personale della contea di Shelby consentiva, ad esempio, di visualizzare solo gli studenti e il personale appropriati di Shelby e tutto il personale (non gli studenti) di ogni altro distretto del paese. L'Elenco indirizzi globale degli studenti di Shelby consentiva di visualizzare solo il personale e gli studenti di Shelby escludendo il personale e gli studenti di qualsiasi altro distretto del paese. La query è stata ripetuta per tutti i distretti dell'organizzazione. Nella Figura 3 vengono illustrati esempi di alcune query LDAP utilizzate in questo complesso processo di migrazione.
Figure 3 Query LDAP nell'Elenco indirizzi (Close Figure 3)

Query LDAP nel GAL del personale
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Query LDAP nell'Elenco indirizzi del distretto
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
Query LDAP nell'Elenco indirizzi degli studenti del distretto
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
Query LDAP nell'Elenco indirizzi non in linea dello staff del distretto
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Figura 2 Elenchi indirizzi globali con separazione di personale e studenti
Figura 2 Elenchi indirizzi globali con separazione di personale e studenti (Fare clic sull'immagine per ridurla)
Figura 2 Elenchi indirizzi globali con separazione di personale e studenti
Figura 2 Elenchi indirizzi globali con separazione di personale e studenti (Fare clic sull'immagine per ingrandirla)
I valori personalizzati delle proprietà degli utenti di Exchange extensionAttribute14 (Attributo personalizzato 14) ed extensionAttribute15 (Attributo personalizzato 15) hanno rappresentato il meccanismo distintivo alla base alle query LDAP. Tutto il personale e tutti lgi studenti nell'intero paese utilizzavano un valore specifico in extensionAttribute14 per indicare il tipo di utente e un valore univoco in extensionAttribute15 per indicare l'appartenenza al distretto. Utilizzando valori univoci per ciascun distretto e valori identici per ciascun tipo di utente, gli elenchi di indirizzi erano in grado di visualizzare esattamente le informazioni necessarie per ciascun tipo di utente in ciascun distretto.
Questi elenchi di indirizzi rappresentavano un valido strumento per gli utenti che accedevano alla posta elettronica tramite Outlook in modalità non cache o tramite OWA (ciascun utente è stato indirizzato all'elenco di indirizzi corretto in OWA mediante l'attributo msExchQueryBaseDN). Gli utenti tuttavia che eseguivano Outlook in modalità cache presentavano un altro problema. Poiché Outlook non prevede l'utilizzo di un Elenco indirizzi globale personalizzato come Rubrica non in linea (OAB) predefinita, è stato necessario creare elenchi di indirizzi aggiuntivi che rappresentavano duplicati degli Elenchi indirizzi globali. Ogni archivio delle cassette postali dei distretti è stato configurato con l'elenco di indirizzi OAB appropriato per i relativi utenti in modalità cache. Questa soluzione ha determinato la creazione di oltre 1.500 elenchi di indirizzi per garantire il supporto completo dei diversi tipi di utenti in tutti i 178 distretti.

Garanzia della compatibilità
Per garantire il corretto funzionamento della struttura che si stava implementando, la conformità ai nuovi standard definiti era di capitale importanza. Il nuovo sistema prevedeva la necessità di eseguire numerose attività di alto livello per ogni utente Exchange all'interno dell'organizzazione. Il motivo va ricercato nel fatto che ogni utente doveva essere individuato correttamente su tutti i server di Exchange dei distretti ed essere visibile negli elenchi di indirizzi appropriati.
L'utente doveva essere membro del gruppo di protezione appropriato all'interno del dominio del distretto in quanto il gruppo di protezione concede le autorizzazioni per l'apertura dell'elenco di indirizzi corretto. L'utente inoltre doveva impostare correttamente l'attributo msExchQuerybaseDN in base all'appartenenza al distretto e all'unità organizzativa. Il tipo di utente era determinato dall'unità organizzativa.
Il passaggio successivo è stato creare la cassetta postale dell'utente nell'archivio corretto sul server appropriato in base all'appartenenza al distretto e al tipo di utente. Questa operazione ha influito sui livelli di servizio, sui limiti delle dimensioni delle cassette postali e sugli elenchi di indirizzi della Rubrica non in linea in modo da consentire il corretto funzionamento della modalità cache di Outlook. Gli attributi di estensione sono stati impostati in base all'appartenenza al distretto e al tipo di utente in modo che l'utente fosse visibile solo negli elenchi di indirizzi appropriati.
Infine, è stato necessario individuare un metodo per correggere automaticamente eventuali appartenenze ai gruppi o attributi dell'account nel caso in cui questi non fossero stati configurati in modo corretto o fossero stati modificati in valori non appropriati. Il passaggio di un utente da un'unità organizzativa a un'altra all'interno del dominio del distretto determina la modifica della classificazione dell'utente e la necessità di aggiornare la posizione della cassetta postale, la selezione dell'Elenco indirizzi globale e la visibilità degli elenchi di indirizzi.
Era necessario un sistema di provisioning che consentisse di eseguire queste attività e garantisse la coerenza e l'accuratezza di Active Directory. È stata creata un'applicazione console basata su Visual Basic che viene eseguita a intervalli stabiliti sui server di Exchange 2003 dei distretti scolastici. L'applicazione, che consente di verificare la conformità agli standard e ai criteri e di gestire la creazione e il provisioning di nuovi oggetti, è stata distribuita in tutti i 178 distretti.
Poiché si riteneva che le attività in questione fossero troppo complesse per consentire di eseguire in modo rapido e affidabile una serie di script, si giunse alla conclusione che l'applicazione basata su Visual Basic fosse la soluzione più appropriata in quanto era efficiente, forniva il supporto per la gestione strutturata di errori ed eccezioni e il relativo codice interno poteva in futuro essere facilmente adattato al codice di estensione MIIS con una riscrittura minima.
La migrazione a una nuova organizzazione determinava tuttavia l'esigenza di sviluppare una strategia di coesistenza, poiché il nuovo ambiente doveva fornire il supporto per più di 178 domini SMTP precedenti (alcuni distretti, a differenza di altri, includevano domini di posta elettronica di studenti preesistenti). Fortunatamente, è stato individuato un metodo per eseguire la migrazione dei distretti uno per volta e importare i messaggi e gli indirizzi preesistenti nel nuovo sistema senza alcun impatto sugli altri distretti. Durante la migrazione di un distretto da Exchange 5.5 a Exchange 2003, era tuttavia necessario garantire la continuità del flusso della posta elettronica e pertanto è stata implementata la sincronizzazione delle directory tra Active Directory di Exchange 2003 e la directory di Exchange 5.5 preesistente. Microsoft aveva concesso al Kentucky Department of Education un utilizzo limitato di MIIS solo per l'intera durata del processo di migrazione, è quindi stato possibile sviluppare un codice di estensione personalizzato che è stato utilizzato per sincronizzare entrambe le organizzazioni di Exchange tramite MIIS prima, durante e dopo la migrazione.
La migrazione a una nuova organizzazione Exchange ha ovviamente effetto sulla configurazione del client MAPI. Il Department of Education si è trovato ad affrontare il problema rappresentato dalla presenza di decine di migliaia di profili MAPI a livello di distretto che avrebbero dovuto essere riconfigurati durante il processo di migrazione. Microsoft ha per fortuna rilasciato Strumento di aggiornamento profilo Exchange (ExProfRe.exe), utilizzato per la migrazione dei profili a livello di distretto. È stato inserito in un pacchetto un programma di installazione in grado di eseguire ExProfRe.exe con valori precaricati in modo consentire l'esecuzione automatica delle migrazioni dei profili a livello di distretto. Il programma veniva richiamato tramite Criteri di gruppo. Questa soluzione ha consentito di eseguire con successo quasi tutte le migrazioni automatiche dei profili tra le due organizzazioni.

Aggiornamenti hardware
Poiché i nuovi server di Exchange 2003 avrebbero sostituito i server di Exchange 5.5 distribuiti geograficamente, il lato hardware di questa soluzione doveva supportare lo stesso numero di utenti della distribuzione di Exchange 5.5, oltre al carico degli account degli studenti aggiuntivi. I server avrebbero dovuto essere ospitati localmente all'interno del distretto in quanto la topologia della rete WAN era stata progettata per consentire il passaggio di tutto il traffico (Internet e interno) tra i distretti attraverso una linea T1 privata (in alcuni distretti, attraverso più linee T1).
A causa dei vincoli di budget, gestione e hosting delle apparecchiature, i server di Exchange non sarebbero stati configurati per l'archiviazione basata sulla rete SAN (Storage Area Network) ma per l'archiviazione diretta o interna. Poiché la maggior parte dei distretti non disponeva di centri dati con sistemi di archiviazione in rack e sistema di raffreddamento centralizzato, i server dovevano essere il più possibile autosufficienti. La maggior parte dei distretti disponeva di meno di 5.000 utenti, quindi è stato possibile eseguire distribuzioni di un singolo server. Per i distretti che disponevano di più utenti, sono stati utilizzati server più potenti (o più server) e dispositivi di archiviazione aggiuntivi, talvolta con server front-end separati per separare ulteriormente il traffico degli studenti e del personale.
Nella maggior parte dei distretti sono stati distribuiti server a doppio processore ben attrezzati che sono stati configurati con il massimo numero di unità Ultra320 SCSI da 15.000 RPM, più controller RAID e 4 GB di RAM. I distretti di maggiori dimensioni sono stati dotati di uno o più server con quattro processori utilizzando, ove necessario, server front-end di minori dimensioni. I test di benchmark e delle prestazioni prima della distribuzione hanno indicato che non erano presenti problemi di utilizzo o di carico. La variazione dei livelli dei criteri d'uso locali, tuttavia, rappresentava il fattore di maggiore impatto sulle prestazioni globali del server.

Test del modello di prova
Sebbene l'ambiente di produzione comprenda una foresta Active Directory con 178 domini, il laboratorio di test del modello di prova (POC) è stato ridotto a 13 domini a livello di distretto e un dominio radice vuoto. In tutti i domini di test sono stati esportati tutti gli elementi dei domini dell'ambiente di produzione. I server di Exchange 5.5 virtuali sono stati creati e configurati con copie di database dei distretti selezionati in modo che fosse possibile eseguire il test del processo di migrazione all'esterno dell'ambiente pianificato. L'intero laboratorio di test POC è stato allestito con computer virtuali in modo da consentire la definizione di una linea di base, il blocco e la ridistribuzione dell'ambiente quando necessario.
Sono state create, codificate, testate e completate diverse combinazioni di script (mediante VBScript), pacchetti del programma di installazione SMS (Systems Management Server) e applicazioni console. Gli script creati erano in grado di eseguire l'installazione e la configurazione iniziali di Exchange 2003, inclusi i criteri destinatario, gli Elenchi indirizzi globali, gli elenchi di indirizzi personalizzati e le autorizzazioni. Gli script erano inoltre in grado di gestire la configurazione dei gruppi amministrativi, la configurazione dei domini dei distretti (creazione di gruppi di protezione e delega delle autorizzazioni) e configurazione post-distribuzione per la migrazione.
La gestione temporanea dei server di Exchange 2003 ha presentato alcune significative difficoltà. È stato necessario installare tutti i server di Exchange in tutti i 178 domini facendo attenzione a non compromettere il resto della migrazione. Exchange 2003 si distingue da Exchange 2000 per il fatto che il gruppo Exchange Domain Servers specifico del dominio non viene aggiunto all'elenco di controllo di accesso dell'organizzazione fino a quando non viene installato il primo server di Exchange 2003 del dominio (in Exchange 2000, il gruppo viene aggiunto durante l'esecuzione del processo DomainPrep). Per verificare che nell'oggetto organizzazione in Active Directory venissero elencati tutti i gruppi di protezione appropriati, è stato necessario eseguire l'installazione in uno specifico dominio, eseguire la replica manuale di Active Directory dal dominio nel sito hub di replica di Active Directory e infine effettuare il pull di tale replica nel successivo distretto da installare. È stato possibile avviare l'installazione del distretto successivo solo dopo aver verificato che nell'elenco di controllo di accesso dell'oggetto organizzazione fosse presente il gruppo Exchange Domain Servers del distretto precedente. Se questo processo non fosse stato completato in modo corretto anche in un solo dominio, sarebbe stato necessario reinstallare almeno tale distretto. In caso contrario, non essendo elencati in modo corretto tutti gli altri distretti nell'elenco di controllo di accesso dell'oggetto organizzazione, i distretti non sarebbero stati in grado di comunicare tra loro.
Gli scenari di distribuzione, configurazione, gestione temporanea dei server e migrazione sono stati testati numerose volte fino a quando non si sono ottenuti risultati soddisfacenti in relazione al corretto funzionamento dell'intero processo all'interno dell'ambiente POC.

Migrazione e problemi specifici
Una volta ricevuta l'approvazione delle procedure e dei risultati del test POC da parte del team del progetto, si era ormai pronti per avviare il processo di migrazione. Tale processo è stato tuttavia eseguito dal personale OET che ha deciso di sperimentarne gli effetti in prima persona. Al momento della migrazione, si era già provveduto alla gestione temporanea di tutti i server e alla verifica dell'ambiente iniziale. Tutti i server dei protocolli front-end e i server delle cassette postali erano pronti per essere implementati nell'ambiente di produzione con gli utenti.
L'esecuzione del piano di migrazione non ha presentato particolari problemi e dopo 21 interminabili ore, necessarie per trasferire il contenuto da un server all'altro, Exchange 2003 era già operativo. Fortunatamente, non si sono verificati problemi significativi nel corso della migrazione dei profili di Outlook da Exchange 5.5 a Exchange 2003. Si è inserito in un pacchetto un file batch che richiamava ExProfRe.exe in diverse configurazioni in base a una logica piuttosto semplice. Il file batch e lo strumento ExProfRe.exe sono stati distribuiti nella condivisione Netlogon di un controller di dominio in ciascun distretto e si è utilizzato Criteri di gruppo per eseguire il file batch per tutti i client al termine di una migrazione. Il corretto funzionamento del processo presso OET aveva lasciato un certo margine di sicurezza in merito al buon andamento della migrazione nelle fasi successive.
A questo punto, il piano di migrazione era stato esaminato e riapprovato in base all'esperienza con la distribuzione OET. Nelle fasi successive della migrazione, sei distretti sono stati configurati come primi siti di produzione. Prima di eseguire la migrazione di ciascun distretto, l'utilizzo di MIIS ha consentito di leggere le informazioni più recenti sulle cassette postali del distretto da Exchange 5.5 e di aggiornare gli utenti corrispondenti nel dominio del distretto. Per trasferire i dati della cassette postali tra le organizzazioni si è utilizzata la Migrazione guidata di Exchange (Mailmig.exe). Durante il trasferimento dei dati delle cassette postali mediante la procedura guidata, tutti gli indirizzi proxy sono stati importati e aggiornati in base ai dati esportati originariamente da MIIS in Active Directory. Durante la migrazione, la posta è stata accodata sui server SMTP front-end e successivamente rilasciata nel distretto dopo il completamento della migrazione, della configurazione dei server post-migrazione e del test degli utenti; il distretto era pronto per eseguire la migrazione client su larga scala tramite ExProfRe.exe.

Il RUS conteso
Per il corretto funzionamento dei client Outlook, era necessario garantire che la soluzione di provisioning fosse la massima autorità per l'impostazione dei valori degli attributi. Era inoltre necessario che il Servizio aggiornamento destinatari (RUS) terminasse le operazioni all'impostazione dell'account, ma il RUS doveva essere eseguito solo dopo la fine del provisioning. A tale scopo le istanze del RUS per i distretti (tutti i 178 distretti) sono state impostate su Mai per le rispettive programmazioni, mentre per la soluzione di provisioning si è utilizzato del codice che avviasse il RUS al termine del provisioning.
Nella maggior parte dei distretti erano presenti meno di 5.000 utenti e molti meno aggiornamenti quotidiani, quindi il RUS terminava in fretta poiché al termine dell'esecuzione giornaliera il sistema di provisioning avviava un aggiornamento invece di una ricostruzione. Esistevano tuttavia alcuni distretti con più di 10.000 utenti. In tali casi l'esecuzione degli aggiornamenti richiedeva quantità di tempo molto maggiori e una ricostruzione del RUS completa in quei domini sarebbe durata più di una settimana. Poiché durante l'esecuzione del RUS vengono valutati tutti i tipi di oggetto, una ricostruzione in ambienti così enormi sarebbe stato sfiancante.
Sebbene non si riuscisse a individuare una strategia di mitigazione (anche cercando una soluzione con i membri del gruppo Exchange), il codice di provisioning è stato migliorato in modo da gestire gran parte delle operazioni di norme gestite dal RUS. Gli utenti ottengono attributi showInAddressBook e proxyAddresses compilati al momento del provisioning iniziale, in modo da accedere immediatamente invece di dover attendere la fine dell'esecuzione del RUS. È stato inoltre creata un'attività manuale che viene eseguita su uno dei server dei protocolli Exchange 2003 front-end e che consente di eseguire un'importazione da LDIFDE temporizzata e cancellare l'indirizzo gatewayProxy del RUS, in modo che se nell'ambiente viene accidentalmente applicato un criterio destinatario, questo non venga inserito nell'elenco delle attività da svolgere di tutti i RUS dell'azienda.

Problemi del classificatore
Un aspetto interessante delle impostazioni per impedire che i dati degli studenti uscissero dal distretto scolastico, era l'implementazione dei controlli per evitare che gli utenti inviassero messaggi di posta elettronica a utenti esterni al distretto di appartenenza o a indirizzi Internet esterni al sistema. Invece di operare con un complesso sistema di connettori ed elementi correlati, si è deciso di implementare una funzionalità poco nota di Exchange 2003 e di utilizzare delle restrizioni dei connettori sul Connettore gruppo di routing esistente dal distretto all'hub centrale in cui risiedono i server dei protocolli front-end. Sono stati creati due gruppi di protezione in ciascun dominio (uno per il personale e uno per gli studenti), che sono quindi stati aggiunti alle restrizioni dei connettori.
Dopo l'attivazione del controllo delle restrizioni dei connettori nel Registro di sistema, si sono verificati problemi di prestazioni molto evidenti. I messaggi si bloccavano nel classificatore e nelle code di recapito locali per ore, compresi i messaggi indirizzati a destinatari sullo stesso server. I problemi si sono aggravati con il passare del tempo, dopo la migrazione di altri distretti. Come soluzione a breve termine, è stato disattivato il controllo delle restrizioni dei connettori ottenendo un immediato miglioramento delle prestazioni. Dopo ulteriori analisi la causa del problema è stata individuata nel comportamento del classificatore, che all'invio del messaggio controllava non solo le appartenenze ai due gruppi presenti nello stesso dominio, ma anche le appartenenze ai medesimi due gruppi degli altri 177 domini. Questa operazione veniva eseguita per tutti i messaggi che entravano o uscivano dal server.
Il caso venne sottoposto all'attenzione di Microsoft che, dopo ulteriori valutazioni, è in procinto di generare un aggiornamento rapido per alleviare gli effetti del problema, consentendo al classificatore di operare in una modalità a complessità di topologia ridotta. Al momento di andare in stampa non sono ancora disponibili informazioni più dettagliate sull'aggiornamento rapido, ma l'obiettivo resta un'impostazione che consenta al classificatore di operare in base a determinati presupposti relativi alla topologia di routing, senza cercare appartenenze ai gruppi su tutti i connettori.

Lezioni dell'esperienza
La lezione appresa più volte nel corso del progetto è che le esigenze dell'azienda determinano tutte le scelte dei consulenti. In molte occasioni è stato necessario valutare la fattibilità delle richieste dell'azienda a fronte della complessità della soluzione. Le decisioni e le scelte descritte in questo articolo sono quelle che si sono ritenute più appropriate dati l'ambiente (compresi altri elementi che non è stato possibile illustrare qui), le risorse e i requisiti aziendali. Per altri amministratori o consulenti le scelte saranno diverse, ma si spera che tutti possano trovare in questo articolo degli utili suggerimenti. Exchange 2003 e Active Directory hanno consentito di sfruttare, per fortuna, una grande flessibilità per rispondere a tutte le esigenze di una migrazione tanto complessa. Una volta superato lo shock provocato dalle dimensioni della distribuzione nel Kentucky Department of Education, la soluzione è in effetti abbastanza semplice e costruita su alcune delle funzionalità meno utilizzate di Active Directory e Exchange 2003.
Una seconda preziosa lezione riguarda l'esigenza di assumere un approccio equilibrato verso la risoluzione dei problemi e la gestione di rischi e problemi. In alcune occasioni è più adeguata una risoluzione locale dei problemi, mentre in altre è assolutamente necessario ricorrere alle risorse avanzate del Servizio supporto tecnico Microsoft.

Per il futuro
L'ambiente del Kentucky Department of Education è di sicuro unico. Nel corso della distribuzione quasi tutte le funzioni di Exchange sono state utilizzate o personalizzate in modo da soddisfare le esigenze di un ambiente così particolare. Ora che distribuzione e migrazione dell'intero ambiente sono terminate, è tutto pronto per l'implementazione di nuove funzionalità. Dal Department of Education sono giunti segnali di interesse per la piattaforma Windows Mobile®, in attesa degli sviluppi legati ai dispositivi portatili.
Il consolidamento dei server costituisce un vantaggio significativo. Al momento presso il Kentucky Department of Education si sta considerando l'idea di virtualizzare alcuni aspetti dell'ambiente Active Directory. Con Exchange 2007 all'orizzonte, sono già iniziate le analisi dei requisiti per un aggiornamento dei sistemi di messaggistica.
Anche le altre offerte nel campo della collaborazione, come Live Communication Server, Live Meeting Server e simili, sono motivo di interesse per il Kentucky Department of Education. Microsoft Operations Manager 2005 è già in fase di distribuzione per la gestione e il monitoraggio dei server Exchange e Active Directory.

I risultati
Tutti i ragazzi inclusi nel sistema di scuole pubbliche del Kentucky trarranno beneficio dalla qualità e diffusione di questa implementazione, compresi i miei figli e i figli delle persone per cui ho lavorato in questo progetto. Con questa implementazione si è posto il Kentucky Department of Education in una posizione privilegiata per cogliere le opportunità offerte dalle nuove tecnologie, in modo standardizzato e protetto, come mai era accaduto in precedenza. Sono orgoglioso di aver lavorato a un progetto tanto importante.

Whitney Roberts è Principal Consultant presso KiZAN Technologies (www.kizan.com) (in inglese) e ha lavorato con Exchange sin dal rilascio di Exchange 4.0.


 Domande e risposte su SQL: Come limitare i riavvii, installare pi&#249; aggiornamenti e altro ancora
Domande e risposte su SQL
Come limitare i riavvii, installare più aggiornamenti e altro ancora
A cura di Nancy Michell

Come limitare i riavvii

D In che modo è possibile limitare il numero di riavvii durante l'applicazione di aggiornamenti rapidi a SQL Server e al sistema operativo del server in generale?

R Innanzitutto, è interessante sapere che la maggior parte dei riavvii eseguiti dopo l'installazione non è specificata a livello di codice nel programma di installazione. I riavvii sono in genere il risultato di file bloccati. Questo significa che il programma di installazione sta tentando di aggiornare i file già utilizzati (bloccati) da un'altra applicazione o dal sistema operativo. Per eliminare la necessità dei riavvii è possibile utilizzare un approccio molto semplice, ovvero garantire che i file in questione non vengano utilizzati da alcun processo. Come si deve procedere in casi del genere?
Il primo passaggio consiste nella determinazione dei file utilizzati e bloccati durante l'installazione. Il metodo più semplice prevede la ricerca dei file nella seguente chiave del Registro di sistema: HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations. Il controllo di questa chiave del Registro di sistema ha due finalità specifiche: verificare che la richiesta di riavvio sia stata effettivamente causata dai file bloccati e indicare all'utente i file che sono stati bloccati. Se si cercano questi file dopo l'installazione, ma prima del riavvio, sarà possibile determinare la causa della richiesta di riavvio e intraprendere le azioni appropriate per eliminare tale problema nel corso delle future installazioni.
È possibile rilevare due tipi di voci. Se un file è stato bloccato in lettura, verrà visualizzata una voce con una riga per file che indica che il file aggiornato è già presente sul disco ma è necessario rimuovere la copia temporanea ancora in uso. Se un file è stato bloccato in scrittura, verrà visualizzata una voce con due righe per file che indica che l'aggiornamento non è stato ancora eseguito e che l'applicazione è in uno stato sconosciuto e pertanto è consigliabile non utilizzarla. È letteralmente come arrestare il sistema nel mezzo del processo di installazione. In questo caso una riga indica il file effettivo, mentre l'altra fa riferimento a un file temporaneo (che diventerà il file effettivo al riavvio).
La fase successiva dipende da numerosi fattori, ma lo scopo principale consiste nell'identificare l'applicazione software che sta utilizzando i file bloccati. Utilizzare, se possibile, strumenti di verifica delle dipendenze o il database DLL HELP in MSDN® (visitare il sito Web all'indirizzo support.microsoft.com/kb/815065) (in inglese).
Se per il software identificato esiste un servizio, arrestare il servizio manualmente e eseguirne di nuovo il test. Se si tratta di una singola applicazione, chiuderla e riprovare. Se un singolo file viene utilizzato da più applicazioni, come talvolta accade, sarà necessario arrestarle tutte.
Il risultato di tali test (nell'ambiente di test) è un elenco di applicazioni e servizi che è necessario arrestare prima dell'installazione nell'ambiente di produzione. L'ambiente di produzione non richiederà alcun riavvio, poiché nessuna applicazione software esegue il blocco di file di cui è in corso l'installazione. Al termine del processo di installazione, occorre naturalmente riavviare tutte le applicazioni arrestate.
L'aspetto interessante di questa procedura è il fatto che i blocchi in genere non subiscono variazioni significative. Se quindi si applica una sola volta questo modello sui sistemi utilizzati, è probabile che si eviteranno numerosi riavvii durante l'intero arco di utilizzo del sistema.
Esiste un altro utile metodo che vale la pena menzionare. Si supponga di disporre di più versioni di SQL Server™ o di un altro prodotto installato in modalità parallela e che si siano installate persino versioni diverse. È consigliabile aggiornare sempre per prima la versione più recente. È probabile che l'aggiornamento sostituisca le versioni dei programmi installati con le versioni più recenti e che tutte le altre istanze ignorino completamente i blocchi. Se, ad esempio, si dispone di tre istanze di SQL Server 2000 SP3, l'aggiornamento a SP4 di una di queste istanze determinerà l'aggiornamento del file MSXML3.dll e richiederà un riavvio. Si supponga di eseguire il riavvio. In tal caso sarà possibile aggiornare le altre due istanze a SP4 senza dover eseguire il riavvio, poiché il file MSXML3.dll aggiornato è già presente nel sistema. Lo stesso concetto è applicabile in uno scenario in cui l'aggiornamento per le istanze di SQL Server 2005 venga eseguito prima che per le istanze di SQL Server 2000 e che queste vengano aggiornate prima delle istanze di SQL Server 7.0. Si tratta di una strategia molto efficace per la riduzione al minimo dei riavvii.
Considerando la situazione da un punto di vista generale, i team di sviluppo Microsoft hanno profuso un notevole impegno nel tentativo di eliminare o limitare il numero di riavvii in molti scenari. Poiché questo articolo è incentrato su domande e risposte relative a SQL, si prenda come esempio SQL Server.
In SQL Server 2005 il team per SQL Server ha suddiviso il codice Microsoft® Data Access Components (MDAC) necessario per SQL Server in SQLNCLI (nuovi file) anziché aggiornare il componente MDAC e ha riportato nuovamente MDAC in banda con il sistema operativo. Qual è l'utilità di questo approccio? Il sistema operativo Windows® utilizza MDAC e mantiene bloccati questi file. Per questo motivo la maggior parte dei service pack di SQL Server e altri pacchetti determinavano dei riavvii. Ora, poiché SQL Server è in grado di aggiornare la versione di MDAC senza utilizzare i file MDAC in uso del sistema operativo, non è più necessario eseguire il riavvio.
Nel programma di installazione di SQL Server 2005 SP1 inoltre è incorporato uno strumento di verifica delle dipendenze che consente di identificare i file bloccati, oltre alla causa del blocco, e di arrestare immediatamente tutte le operazioni che determinano il blocco e continuare il processo di installazione senza eseguire alcun riavvio. È quindi possibile utilizzare questo strumento in tempo reale, senza la necessità di eseguirlo in un ambiente di test. È sempre possibile ovviamente continuare il processo di installazione ed eseguire il riavvio se si desidera o se si opera in modalità automatica. La semplicità con cui questo metodo consente di determinare l'origine del blocco è davvero straordinaria.
La tecnologia del programma di installazione Microsoft consente inoltre di gestire in modo più efficiente le chiavi PendingFileRenameOperations (PFR) esistenti. Come si ricorderà, il programma di installazione di SQL Server 2000 si blocca se un file è presente nella chiave del Registro di sistema citata in precedenza. Il programma di installazione di SQL Server 2005 si blocca solo se i file appartengono a SQL Server (quando è possibile che si venga a creare un conflitto) e anche in tali casi è in grado di individuare la chiave PFR e aggiornarla direttamente senza la necessità di un riavvio. Questa tecnologia è inclusa in MSI e in update.exe, i programmi di installazione Microsoft standard utilizzati per l'esecuzione di tutti gli aggiornamenti.
Quali sono alcuni dei problemi noti che causano il riavvio? MSXML3.dll rappresenta uno dei maggiori problemi. Questo file è sempre bloccato dal servizio SVCHost di Windows. Pertanto, qualsiasi sistema operativo che includa questo servizio richiederà l'esecuzione di un riavvio. Il servizio è inoltre presente in molti stack MDAC (mdac_typ.exe). MDAC è per fortuna in modalità "in banda" in Windows Server® 2003 e Windows XP SP2 e versioni successive. Il team di sviluppo di SQL Server ha svolto un lavoro eccezionale nel suddividere il file msxmlsql.dll in modo da impedire che gli aggiornamenti a SQL Server determinino il riavvio del sistema, anche se si prevede che il problema possa presentarsi occasionalmente ancora per qualche tempo. In tal caso non esiste una soluzione efficace: non è possibile arrestare SVCHost e continuare a eseguire gli aggiornamenti.
Inoltre, i pacchetti update.exe si comportano in modo del tutto peculiare durante il processo di disinstallazione. Se si disinstalla un pacchetto, quest'ultimo esegue il blocco (naturalmente all'esterno delle chiavi PFR) dei file temporanei del programma di installazione in modo da impedire l'esecuzione degli altri pacchetti update.exe fino a quando non si esegue il riavvio per rimuovere il blocco. L'unica azione che è possibile intraprendere è pianificare, una volta individuato il blocco, un riavvio dopo tutte le disinstallazioni degli aggiornamenti rapidi eventualmente eseguite.
Un altro problema a cui occorre far fronte è costituito dall'intermittenza. Non tutti i programmi utilizzano un file per il 100% del tempo. Infatti, l'utilizzo delle DLL condivise è nella maggior parte dei casi temporizzato, il che indica che gli altri programmi vi accedono solo quando necessario, in base al relativo carico di lavoro e ai percorsi di codice. Ne consegue che è possibile eseguire 10 test e non individuare alcun file bloccato e che si rilevi un file bloccato durante la distribuzione della produzione. Purtroppo non esiste l'arma in grado di eliminare in modo rapido e definitivo tutti i problemi. È sufficiente creare un ambiente di test quanto più possibile simile all'ambiente di produzione, incluso il carico (comunque un valido obiettivo), ed eseguire un numero di test sufficiente per evidenziare le permutazioni.
I service pack e gli aggiornamenti del sistema operativo richiederanno il riavvio. È opportuno sottolineare che nelle versioni di livello inferiore (Windows 2000, Windows XP e versioni precedenti), l'installazione viene completata solo dopo il riavvio, anche se la chiave del Registro di sistema pendingfilerenameoperations è vuota. Durante il riavvio, è possibile che vengano eseguite operazioni di registrazione dei pacchetti di eccezione per l'installazione del codice. Si tratta di operazioni che non fanno parte dell'installazione dei service pack, ma sono comandi incorporati nel sistema operativo corrente che vengono attivati dagli scenari di aggiornamento per consentire che determinati segmenti di codice in uso non vadano persi con l'aggiornamento.
Infine, la chiave PFR non esegue il controllo delle versioni dei file né applica l'ordinamento tramite la serializzazione. Ne consegue che la chiave avvia le sostituzioni dei file nell'ordine in cui sono elencati. Tuttavia, è stato dimostrato che in base all'ordine in cui vengono applicate al disco rigido tali sostituzioni costituiscono l'ultima operazione completata (non la prima a essere avviata). Un comportamento logico, ma che implica la presenza di due copie dello stesso file nello stesso percorso, ciascuna delle quali fa riferimento a versioni differenti, con un risultato casuale dopo il riavvio. Quando si verifica una situazione di questo tipo, è necessario procedere a una rapida soluzione. Se non si è certi, rieseguire semplicemente entrambi i programmi di installazione dopo il riavvio. Se sono disponibili i file corretti, nessuno dei programmi di installazione eseguirà alcuna operazione. Se sono disponibili i file errati, questi verranno corretti da un qualsiasi pacchetto con i file giusti. Francamente, questo approccio è molto più rapido e sicuro che tentare di stabilire quale sia il risultato desiderato.

Installazioni multiple di service pack

D Se si utilizzano otto istanze in cluster di SQL Server 2000 in un cluster a 4 nodi e si desidera installare SP4 eseguendo un numero minimo di riavvii, è possibile installare SP4 su tutte le 8 istanze una per volta e al termine riavviare tutti i nodi?

R Al termine dell'installazione di una singola istanza di SQL Server SP4, operazione che potrebbe richiedere un riavvio, in uno specifico server Windows (in cluster o meno), non sarà necessario eseguire ulteriori riavvii durante l'installazione di SQL Server SP4 in qualsiasi altra istanza di SQL Server sul computer. Il motivo va ricercato nel fatto che tutti i file condivisi, strumenti, MDAC, MSXML e così via, corrispondono già alla versione corretta e, bloccati o meno, non necessitano di ulteriore aggiornamento. Tutti i file non condivisi vengono utilizzati solo dalla prima istanza, che verrà arrestata in fase di installazione. È chiaro che, se si dispone di istanze multiple di più versioni, è sempre consigliabile aggiornare prima l'istanza più recente di SQL Server.

Esecuzione come account Servizio di rete

D Cos'è con esattezza l'account NT AUTHORITY\NETWORK SERVICE e qual è la funzione principale dell'account? Quali sono inoltre le implicazioni dell'account in termini di protezione, soprattutto quando si concedono i diritti sysadmin (sa)?

R L'account Servizio di rete ha la stessa identità (identità del computer) dell'account di sistema sulla rete, ma dispone di privilegi limitati sul computer locale. Se quindi un servizio richiede l'accesso alle risorse di rete, ad esempio per risolvere i nomi degli account con il controller di dominio, sarà necessario eseguirlo come account di sistema, account di dominio o Servizio di rete. Quest'ultimo account rappresenta in genere la soluzione che garantisce il massimo livello di protezione, poiché viene definito solo in un computer locale e dispone di privilegi limitati.
Se si imposta l'account Servizio di rete come account sysadmin in SQL Server, qualsiasi altro servizio eseguito come Servizio di rete sul computer locale avrà un controllo completo sul server. Questa situazione si verifica, ad esempio, quando l'account di servizio di SQL Server è configurato per l'esecuzione come Servizio di rete. L'impostazione di un account di servizio di SQL Server come membro di sysadmin è necessaria per la funzionalità del server, ad esempio per consentire connessioni in loopback. Sebbene la configurazione dell'account Servizio di rete per l'esecuzione con l'account amministratore su SQL Server non rappresenti una procedura di protezione ottimale, si potrebbe tuttavia rivelare migliore rispetto all'utilizzo di un account di dominio per tale scopo e garantisce un livello di protezione molto più elevato rispetto alla configurazione di SQL Server per l'esecuzione come account LocalSystem.
Se non si intende concedere i privilegi sysadmin all'account Servizio di rete, è consigliabile utilizzare un account di dominio dedicato in modo specifico all'esecuzione di SQL Server in una o più installazioni di Windows NT®.
Per ulteriori informazioni, vedere i seguenti articoli: msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp (in inglese) e microsoft.com/technet/security/topics/serversecurity/serviceaccount (in inglese).

Creazione di più database

D Quando è necessario eseguire il partizionamento dei dati in singoli database, magari fino a 250 database in linea contemporaneamente e si prevede che solo il 20% verrà utilizzato per le query attive in un determinato momento, la creazione di più database è preferibile alla creazione di un numero minore di database?

R Il numero di database all'interno di un'istanza del server del database deve essere commisurato alle esigenze aziendali e ai fattori di amministrazione. L'overhead associato alla creazione di più database all'interno di una singola istanza del server è minimo, ma la creazione di più database implica un maggiore overhead di amministrazione per le attività di manutenzione, come backup e ripristino, mirroring, account utente e ruoli utente. Le complessità di amministrazione possono superare di gran lunga i vantaggi che derivano dalla creazione di più database.
In generale è consigliabile che tutti i dati correlati a un'applicazione vengano conservati in un unico database, in modo da semplificare la procedura di ripristino in caso di errore. Se i dati di un'applicazione sono distribuiti su più database, durante un failover sarà necessario ripristinare tutti i database. Un'operazione che può ritardare il ripristino o persino impedire un ripristino quando non è possibile ripristinare uno dei database.
Considerate le premesse, esistono motivi specifici per segregare i dati in più database:
  • un sottoinsieme di dati presenta requisiti di backup diversi rispetto ad altri tipi di dati.
  • Per alcuni dati è necessario un contesto di protezione separato, ovvero un proprietario di database differente.
  • I dati vengono talvolta creati a scopo cronologico e devono essere conservati in modalità di sola lettura.

Si ringraziano i seguenti professionisti IT di Microsoft per aver contribuito alla redazione di questo articolo con il loro bagaglio di competenze tecniche: Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson e Madhusudhanan Vadlamaani.

A cura di Nancy Michell


 Hey, Scripting Guy!: Dove sono i supporti per i bicchieri?
Hey, Scripting Guy!
Dove sono i supporti per i bicchieri?
Gli Scripting Guy di Microsoft
L'articolo è basato sulla versione preliminare di Windows PowerShell e le informazioni riportate sono soggette a modifiche.

Ogni volta che una nuova tecnologia irrompe sul mercato, occorre del tempo prima che le persone inizino a notare le reali differenze tra le soluzioni adottate in precedenza e la tecnologia appena nata. Si provi, ad esempio, a pensare all'avvento dell'automobile. Esiste una buona ragione per cui nei primi anni i nuovi aggeggi meccanici venivano chiamati "carrozze senza cavalli": è esattamente ciò che erano. Se si tenta di tracciare le differenze tra le prime automobili e le carrozze trainate da cavalli, a parte la diversa trazione animale o meccanica, è in effetti difficile distinguere le une dalle altre.
Oggi sarebbero, ovviamente, poche le persone a confondere un'automobile con una carrozza trainata da cavalli. Il motivo consiste nel fatto che, con il passare del tempo, i produttori di automobili hanno marcato in modo inconfondibile la separazione tra auto e carrozze. Le automobili di oggi, ad esempio, escono dalla catena di montaggio già corredate di lettore di CD, climatizzatore e sistema di navigazione satellitare. Non si ricordano carrozze a trazione animale equipaggiate allo stesso modo. Allo stesso modo, si immagini di essere alla guida di una carrozza trainata da cavalli nel 1880 e di dover appoggiare un attimo il Frappuccino; impossibile. Alcuni SUV invece sono dotati di 17 diversi supporti per tazze e bicchieri e una delle marche più popolari prevede tre supporti per bevande solo per il guidatore. In alcuni dei modelli più recenti i supporti per le bevande sono riscaldati o refrigerati.
Nota Certo oggi sembra impossibile che in passato si potesse sopravvivere senza bere tre diverse bibite durante la guida. Come si può anche solo immaginare di mettersi alla guida con solo due o, addirittura, una sola bibita a disposizione?
Perché una nuova tecnologia abbia successo, è necessario che ai consumatori siano chiari i motivi per cui è necessario preferire il prodotto nuovo e sconosciuto al vecchio e affidabile. Quando sono comparsi sul mercato, i DVD consentivano di guardare i film a casa, esattamente come i registratori di videocassette. Di contro, i DVD erano molto più costosi delle videocassette e non era nemmeno possibile utilizzare un lettore di DVD per registrare le trasmissioni televisive preferite. Inutile dire che i DVD hanno fatto molta fatica a conquistare il mercato. Prima che i DVD iniziassero a soppiantare i vecchi registratori VHS, è stato necessario che i produttori di DVD includessero nei titoli distribuiti alcune sequenze tagliate, le interviste ad attori che non si erano neanche notati nel cast e altri contenuti che non era possibile inserire in una videocassetta. La semplice possibilità di guardare un film a casa non era sufficiente e i produttori di DVD hanno dovuto fornire contenuti e funzionalità che superassero quelle già a disposizione degli utenti di VHS.
Nota Il fatto che esista o meno qualcuno che davvero guarda i contenuti extra di un DVD non è rilevante: la natura umana è fatta così e se una cosa è disponibile scatta immediato il desiderio di possederla. Per inciso, gli Scripting Guy stanno pensando da tempo di lanciare un DVD con tutto il testo eliminato dagli articoli di TechNet Magazine e dei finali alternativi per gli script di amministrazione del sistema.

Utilizzo di Windows PowerShell
Windows PowerShell™, la nuova tecnologia di shell comandi/scripting rilasciata da Microsoft, è un ulteriore esempio di nuovo prodotto sul mercato. Quando si sente parlare per la prima volta di Windows PowerShell, in genere si ascoltano affermazioni del tipo:
  • "Windows PowerShell consente di gestire processi e servizi."
  • "Windows PowerShell consente di recuperare gli eventi dai registri eventi."
  • "Windows PowerShell consente di utilizzare WMI per la gestione dei computer."
Nessuna di queste affermazioni è errata e tutte si riferiscono ad attività utili e importanti. L'unico problema è rappresentato, ovviamente, dal fatto che è già possibile eseguire tutte queste attività con VBScript e Windows Script Host. La compatibilità a ritroso è importante e Windows PowerShell non sarebbe nemmeno un'innovazione se non consentisse di eseguire almeno le stesse operazioni eseguite con VBScript (come un lettore di DVD con cui non si riesca nemmeno a guardare i film, ma non è nemmeno necessario immaginarselo un oggetto tanto inutile: uno degli Scripting Guy ne ha uno in bella mostra a casa).
D'altra parte, se con Windows PowerShell si possono eseguire le stesse operazioni già possibili con VBScript, perché mai ci si dovrebbe occupare di questa "nuova" tecnologia? In effetti VBScript viene fornito senza alcun supporto per i bicchieri, ma neanche Windows PowerShell, a dire il vero, ne ha. Qual è dunque la differenza tra le tecnologie di scripting già disponibili e appena rilasciate?
In tutta onestà si potrebbe dire che non esiste alcuna differenza. Ma è anche vero che, a parte l'assenza di supporti per i bicchieri, Windows PowerShell è dotato di funzionalità che in VBScript non sono disponibili. Se il lavoro quotidiano prevede solo la gestione di processi e servizi, i motivi per passare immediatamente alla nuova tecnologia di Windows PowerShell potrebbero non essere evidenti; non è mai consigliabile cercare di aggiustare una cosa che già funziona bene (se riferita agli Scripting Guy questa massima tende a essere interpretata come "meglio che voi ragazzi non proviate nemmeno ad aggiustare qualcosa che funziona, altrimenti finireste con il romperla"). Windows PowerShell rappresenta una novità interessante quando sussiste la possibilità di utilizzarlo per eseguire operazioni altrimenti impossibili con VBScript, come modificare, ad esempio, l'ora dell'ultima scrittura di un file.

Modifica dell'ora dell'ultima scrittura
Proprio così: modifica dell'ora dell'ultima scrittura di un file. Chi crea script ha sempre sognato, per vari motivi (ad esempio, come forma semplice e rapida di controllo delle versioni), di poter modificare l'ora dell'ultima scrittura (o l'ora di creazione) per un singolo file o una serie di file. Purtroppo questa funzionalità non esiste in WMI (Windows Management Instrumentation) o FileSystemObject, dove le date dei file sono di sola lettura.
In Windows PowerShell, invece, per modificare l'ora dell'ultima scrittura di un file e impostare data e ora correnti è sufficiente eseguire questo comando:
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Prima di illustrare il funzionamento del comando, è opportuno rispondere alla domanda che sorge spontanea: come mai con Windows PowerShell è possibile modificare l'ora dell'ultima scrittura di un file quando con WMI non è possibile? È opportuno rispondere prima di tutto a questa domanda, perché rappresenta un equivoco molto diffuso su Windows PowerShell. Si tende erroneamente a considerare Windows PowerShell solo un nuovo modo per utilizzare WMI. È di certo vero che con Windows PowerShell è possibile accedere ai dati WMI, come è altrettanto vero che, in attesa della creazione di ulteriori cmdlet (comandi di Windows PowerShell nativi), la maggior parte degli script di amministrazione dei sistemi sarà basata soprattutto su WMI. Come impostazione di fondo, tuttavia, Windows PowerShell è basato su .NET Framework e i cmdlet di Windows PowerShell vengono di solito utilizzati con oggetti .NET piuttosto che con oggetti WMI. Questa è una differenza importante, dal momento che le proprietà disponibili in .NET Framework non sono necessariamente le stesse disponibili in WMI.
Quando, ad esempio, si utilizza il cmdlet Get-Item per eseguire l'associazione a un file, non si ottiene un'istanza della classe CIM_Datafile di WMI, ma un oggetto .NET. Un comportamento del genere è senza dubbio conveniente, poiché un oggetto .NET espone dei metodi e una serie di proprietà per la gestione dei file leggermente diversi rispetto a WMI. Come appena illustrato, questa lieve differenza è molto importante, almeno quanto la differenza che esiste tra una proprietà di sola lettura e una proprietà che può essere letta e scritta.
Affiora un'ulteriore domanda: come si fa a sapere che il cmdlet Get-Item restituisce un oggetto .NET? In questo, come in molti altri casi, il metodo migliore per scoprire di che tipo di oggetto si tratta (oltre che il modo più semplice per identificare le proprietà e i metodi disponibili) consiste nell'eseguire l'associazione a un file e passare l'oggetto al cmdlet Get-Member:
Get-Item c:\scripts\test.txt | Get-Member
I risultati del comando sono illustrati nella Figura 1. Si tratta proprio di un oggetto .NET (gli Scripting Guy non sbagliano mai).
Figure 1 Membri dell'oggetto restituito da Get-Item (Close Figure 1)

TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText()
CopyTo                    Method         System.IO.FileInfo CopyTo(String destFileName),
                                         System.IO.FileInfo CopyTo(S...
Create                    Method         System.IO.FileStream Create()
CreateObjRef              Method         System.Runtime.Remoting.ObjRef CreateObjRef(
                                         Type requestedType)
CreateText                Method         System.IO.StreamWriter CreateText()
Con questo semplice comando si evidenziano due delle funzionalità più interessanti e utili di Windows PowerShell: pipelining e metainformazioni. In questo articolo non si analizzano i dettagli tecnici, ma l'idea di fondo che sta dietro il pipelining è la possibilità di utilizzare un cmdlet per recuperare un oggetto e passare, quindi, tale oggetto a un altro cmdlet. Nel comando si è utilizzato il cmdlet Get-Item per ottenere un oggetto che rappresenti il file C:\Scripts\Test.txt che si è passato quindi (come oggetto) tramite pipeline al cmdlet Get-Member (il simbolo | rappresenta la pipeline in un comando di Windows PowerShell).
Con Get-Member viene quindi eseguito il recupero dei metodi e delle proprietà dell'oggetto. Questa è un'altra delle funzioni ingegnose di Windows PowerShell: è molto facile accedere alle metainformazioni, ovvero alle informazioni sulle informazioni. Con l'utilizzo di cmdlet come Get-Member e Get-Command è possibile interrogare Windows PowerShell su tutto ciò che si desidera, così come è possibile scrivere uno script WMI per recuperare informazioni sul classi, proprietà e metodi WMI disponibili.
È tuttavia importante notare come con Get-Member vengano potenziate le funzionalità di WMI. Sebbene, infatti, sia possibile utilizzare WMI per ottenere informazioni su oggetti WMI, non è possibile utilizzare WMI per ottenere informazioni su altri oggetti COM (ad esempio, FileSystemObject). Windows PowerShell si comporta in modo diverso e Get-Member funziona con qualsiasi oggetto sia possibile associare o creare. Non si ricordano più i metodi disponibili quando si utilizza FileSystemObject? Ecco il comando da eseguire:
New-Object -comobject "Scripting.     FileSystemObject" | Get-Member
Una funzionalità davvero molto utile e, a oggi, decisamente sottoutilizzata.
Molto efficace. Se si scorre l'elenco di proprietà e metodi disponibili per l'utente per il file C:\Scripts\Test.txt, sarà possibile notare questa riga:
LastWriteTime             Property       System.DateTime LastWriteTime {get;set;}
Interessante. In apparenza LastWriteTime è una proprietà che supporta sia get (lettura) che set (scrittura). Significa forse che è possibile utilizzare Windows PowerShell per modificare il valore dell'ora di ultima scrittura del file? Hmmm...
Glossario di Windows PowerShell
Alias Un nome personalizzabile che rappresenta un cmdlet esistente. In Windows PowerShell sono disponibili alcuni alias predefiniti che consentono di mappare i comandi di shell più comuni rispetto ai cmdlet equivalenti.
Cmdlet L'unità di funzionalità più piccola in Windows PowerShell, analogo ai comandi incorporati di altre shell.
Comando Un'unità di esecuzione in Windows PowerShell. In un comando possono coesistere più operazioni in pipeline e più righe separate dal carattere ;.
Frappuccino Nota bevanda a base di caffè ghiacciato venduta da Starbucks.
Monad/MSH/Microsoft Command Shell Nomi in codice attribuiti in precedenza a Windows PowerShell.
Oggetto Dati strutturati recuperati dal sistema o da un comando. Windows PowerShell consente di manipolare i dati come oggetti .NET, modificando le proprietà dell'oggetto in base al nome senza che sia necessario analizzare l'output di un comando basato su testo.
Parametro Opzioni impostate su un cmdlet nella riga di comando. In Windows PowerShell si utilizza un trattino iniziale (-) per contrassegnare un parametro.
Pipeline Consente di inviare l'output di un comando all'input di un altro comando. Definita anche pipe, viene rappresentata nei comandi con il carattere |.
Profilo Impostazioni caricate all'avvio di Windows PowerShell che consentono di configurare il funzionamento della shell.
Script Uno o più comandi salvati come file ed eseguiti da un file. I file di script di Windows PowerShell sono contraddistinti dall'estensione .ps1.
Shell Un ambiente a riga di comando in cui è possibile eseguire sia comandi che cmdlet.
Variabile Un oggetto o parametro di cui è possibile impostare, modificare o recuperare il valore durante l'esecuzione di un comando.

Ora è il momento di fare un passo indietro e tornare ad analizzare il comando che consente di impostare come ora dell'ultima scrittura di Test.txt la data e ora correnti. Ecco la sintassi:
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Come si può osservare, lo script è molto breve. All'inizio si dichiara una variabile denominata $a. Quindi si utilizza il cmdlet Get-Item per connettersi al file C:\Scripts\Test.txt. L'oggetto viene a propria volta archiviato nella variabile $a. Dopo il punto e virgola (che consente di eseguire più comandi posizionati su una singola riga), si imposta come valore della proprietà LastWriteTime la data e ora correnti. Questa funzionalità quasi compensa la mancanza di supporti per i bicchieri!

Un po' di fantasia
Le novità non si limitano, ovviamente, alla possibilità di impostare come ora dell'ultima scrittura la data e l'ora correnti. Si prenda, ad esempio, in considerazione il seguente comando:
$b = Get-Date "5/22/2006 8:15 PM";
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = $b
Questa volta sono stati combinati tre comandi. All'inizio si è utilizzato il cmdlet Get-Date per creare un oggetto data/ora uguale a 5/22/2006, 8:15 PM. Perché non si è creato un oggetto data/ora con Get-Date anche nel primo script per impostare come ora dell'ultima scrittura la data e l'ora correnti? È facile: il comando Date consente di ottenere in modo automatico un oggetto data/ora. A titolo di verifica, è sufficiente digitare il seguente comando nella console di Windows PowerShell: Date | Get-Member.
Dopo aver creato un oggetto data/ora con data e ora desiderate, è possibile utilizzare il solito comando Get-Item per ottenere un oggetto che rappresenti il file Test.txt (un oggetto che va archiviato nella variabile $a). Si imposta, infine, la proprietà LastWriteTime in base al valore rappresentato dalla variabile $b:
$a.LastWriteTime = $b
E questo è niente. Basta dare un'occhiata a questo comando, in apparenza tanto innocuo:
$b = Get-Date "5/22/2006 8:15 PM";
Get-ChildItem c:\scripts | ForEach-Object {$_.LastWriteTime = $b}
Cosa c'è di interessante nel comando? È di un'utilità incredibile, come si vedrà di seguito. La prima parte è semplice: si crea ancora una volta un oggetto data/ora equivalente alle 8:15 PM del 5/22/2006. È bene, tuttavia, notare che nella seconda parte non si utilizza il cmdlet Get-Item, ma il comando seguente:
Get-ChildItem c:\scripts
Il vantaggio offerto dal cmdlet Get-ChildItem consiste nel fatto che, ogni volta che viene applicato a una cartella, consente di ottenere un elenco di tutti i file contenuti nella cartella. È quindi possibile recuperare l'elenco di file e passare tramite la pipeline (di nuovo il simbolo |) tutte le voci di tale elenco al cmdlet ForEach-Object.
In che modo verranno utilizzati i file da ForEach-Object? Ma è ovvio, si modificheranno i valori della proprietà LastWriteTime di tutti i file:
ForEach-Object {$_.LastWriteTime = $b}
Nota L'articolo di questo mese non vuole essere una guida per principianti a Windows PowerShell, ma è opportuno sottolineare che $_ è una variabile speciale che rappresenta la voce corrente in un ciclo For Each. È l'equivalente di objItem nel seguente ciclo VBScript:
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next
Al termine dell'esecuzione del comando Windows PowerShell, tutti i file della cartella C:\Scripts riporteranno la stessa ora dell'ultima scrittura. Sarebbe proprio bello vedere come se la caverebbe una delle nuove carrozze senza cavalli con questo!
Le variazioni sul tema per il comando in questione sono infinite. Si potrebbe, ad esempio, modificare l'ora dell'ultima scrittura solo per i file .txt della cartella C:\Scripts. Niente di più facile:
$b = Get-Date "5/22/2006 8:15 PM"; Get-ChildItem c:\scripts\*.txt | ForEach-Object {$_.LastWriteTime = $b}

L'appetito vien mangiando
È tutto molto bello, ma lo scopo dell'articolo non è "vendere" a chi legge Windows PowerShell e neppure incoraggiare gli utenti a disfarsi degli script VBScript convertendoli tutti in Windows PowerShell. Se gli script già creati svolgono ancora egregiamente le operazioni richieste, non esiste alcun motivo per disfarsene. Lo stesso vale per file batch, strumenti da riga di comando, formule magiche e qualsiasi altro strumento si utilizzi per gestire i computer. Come si diceva, mai cercare di aggiustare una cosa che funziona.
La reale forza di Windows PowerShell non risiede tanto nel fatto che consente di eseguire operazioni già possibili altrimenti, quanto piuttosto nel fatto che, grazie all'accesso a .NET Framework, consente di eseguire operazioni che prima non erano possibili. La modifica dell'ora dell'ultimo accesso di un file (o di un gruppo di file) è solo un esempio. L'esistenza o meno di altri esempi dipende dalle operazioni che si desidera eseguire e sono proprio queste potenzialità che rendono Windows PowerShell un degno oggetto di attenzione.
A molti lettori questa presentazione di Windows PowerShell sembrerà strana: invece di iniziare da un esempio più semplice del tipo "Ciao a tutti", si è passati direttamente ad analizzare un comando multipart di Windows PowerShell, snocciolando nel frattempo termini come pipeline e cmdlet come se tutti ne conoscessero già per certo il significato. È stata una scelta ponderata. È chiaro che molti dei lettori non hanno ancora provato Windows PowerShell e sussisteva il timore, fondato, che una presentazione basata sul semplice recupero di un elenco di servizi su un computer non sarebbe riuscita ad attirare alcuna attenzione.
Nota La speranza è di non aver attirato troppo l'attenzione di lettori alla guida di infernali carrozze senza cavalli. Per molti creatori di script è già abbastanza difficile bere da tre bicchieri, guardare un DVD e parlare al cellulare durante la guida, senza dover anche aggiungere la "lettura di TechNet Magazine" a tutto il resto.
Suvvia, si diceva per molti, non per tutti.

Gli Scripting Guy di Microsoft lavorano per, o meglio sono dipendenti di Microsoft. Quando non sono troppo occupati a giocare/allenare/guardare partite di baseball (e in varie altre attività) gestiscono lo Script Center di TechNet. È possibile leggerli all'indirizzo www.scriptingguys.com.


 Osservatorio sulla sicurezza: Distribuzione di una PKI attendibile globale
Osservatorio sulla sicurezza
Distribuzione di una PKI attendibile globale
John Morello
Le informazioni nel presente articolo sono relative a versioni non definitive dei prodotti e sono soggette a modifica.

Un'infrastruttura a chiave pubblica o PKI (Public Key Infrastructure) è un elemento fondamentale nella creazione di una relazione di trust tra più applicazioni, sistemi operativi e aree di autenticazione delle identità. L'infrastruttura si basa su un modello di trust gerarchico, in cui le entità finali considerano attendibile una chiave comune al livello più alto dell'Autorità di certificazione radice e pertanto qualsiasi altra chiave firmata da tale autorità è considerata implicitamente attendibile.
Grazie a questa struttura, un'infrastruttura PKI progettata in modo corretto garantisce elevate caratteristiche di scalabilità verticale, mediante l'aggiunta di ulteriori Autorità di certificazione (CA) senza apportare modifiche alle entità finali.
Le infrastrutture PKI vengono in genere implementate in uno dei due modi illustrati di seguito. L'approccio più comune consiste nell'acquistare i certificati necessari da una delle Autorità di certificazione radice globali implicitamente attendibili, quale Cybertrust o VeriSign. I certificati acquistati vengono in genere utilizzati per garantire la protezione del traffico sui siti Web, ma possono anche essere impiegati per la crittografia di reti private virtuali (VPN), la firma dei messaggi di posta elettronica e l'esecuzione di attività simili. Poiché le Autorità di certificazione radice globali sono incorporate in qualsiasi browser Web e sistema operativo recente, questo metodo consente di estendere con facilità una relazione di trust all'esterno dei confini dell'organizzazione. Tuttavia, dal momento che i certificati vengono acquistati in base alle necessità, l'implementazione su vasta scala di questo approccio all'interno di un'organizzazione di grandi dimensioni può rivelarsi piuttosto costosa.
Il modello PKI interno è l'approccio adottato attualmente nella maggior parte degli ambienti di lavoro. Come suggerisce il nome, un'infrastruttura PKI interna viene considerata attendibile solo all'interno della rete di un'organizzazione. Questo modello costituisce per le organizzazioni un metodo più economico per il provisioning di ogni utente e computer sulla rete mediante l'uso di certificati. Viene in genere utilizzato questo approccio per semplificare tecnologie specifiche, come accesso con smart card, Crittografia file system (EFS) e connessioni di rete wireless protette. Lo svantaggio è rappresentato dal fatto che i certificati non sono considerati globalmente attendibili e non sono adatti ad applicazioni che interagiscono con l'esterno. La maggior parte delle organizzazioni che ha distribuito infrastrutture PKI interne adotta in genere un approccio ibrido che prevede l'acquisto di certificati per applicazioni pubbliche da una delle Autorità di certificazione radice globalmente attendibili.
L'ideale sarebbe poter sfruttare le potenzialità di entrambi gli approcci, con la possibilità per un'organizzazione di eseguire un'infrastruttura PKI personalizzata, realizzando notevoli risparmi sui costi grazie all'emissione di certificati interni, e nello stesso tempo di effettuare il provisioning di certificati pubblicamente attendibili, direttamente dal sistema locale. Una soluzione di questo tipo offrirebbe i vantaggi di un'infrastruttura PKI interna (come l'integrazione in Active Directory®, la registrazione automatica e il supporto IT per i diversi paesi) e nel contempo garantirebbe il vantaggio principale di un'Autorità di certificazione radice globalmente attendibile. La Louisiana State University (LSU) dispone esattamente di un sistema di questo tipo. In questa numero di Osservatorio sulla sicurezza viene esaminata in dettaglio la soluzione implementata presso la LSU e, in particolare, vengono illustrati gli aspetti della progettazione tecnica e delle procedure consigliate da utilizzare durante la distribuzione di un sistema simile. È opportuno tenere sempre presente che la soluzione descritta nell'articolo è in grado di soddisfare esigenze specifiche nel contesto dell'ambiente, delle risorse e dei requisiti aziendali presi in esame. Per determinare il tipo di soluzione più adatto alle proprie esigenze, è consigliabile valutare prima tutti questi aspetti in relazione alla propria azienda.

L'infrastruttura PKI secondo la LSU
La LSU è una importante università di ricerca con un totale di oltre 40.000 entità tra studenti, facoltà e personale e dispone di numerosi siti Web pubblici, molti dei quali richiedono l'utilizzo del servizio TLS (Transport Layer Security), il termine corretto per i certificati SSL (Secure Sockets Layer). La LSU investiva ogni anno migliaia di dollari per l'acquisto di certificati da Autorità di certificazione radice globalmente attendibili.
Nel frattempo, mirava al conseguimento di altri obiettivi in termini di protezione IT, che potessero trarre vantaggio da un'infrastruttura PKI interna progettata in modo corretto. Considerati i requisiti e gli obiettivi della LSU, si immagina l'adozione di un modello ibrido. Si è optato invece per un approccio più innovativo.
È stato avviato un rapporto di collaborazione con una delle Autorità di certificazione radice globalmente attendibile, Cybertrust, per distribuire una CA all'interno della LSU che fosse subordinata a una CA radice Cybertrust (vedere la Figura 1). Cybertrust offre questo servizio nel programma OmniRoot. In questo scenario la LSU crea e utilizza una CA che viene eseguita a livello locale su apparecchiature di proprietà della LSU. Tuttavia, a differenza del modello interno illustrato in precedenza, la CA della LSU non è autofirmata e la rispettiva chiave (insieme a tutte le chiavi che firma) è considerata implicitamente attendibile su quasi tutti i sistemi operativi e browser attuali. Dal punto di vista tecnico, questo modello è un'estensione logica dell'apertura degli standard x.509. Poiché un'infrastruttura PKI è basata su tali standard, è possibile inserire sistemi creati da fornitori diversi nella stessa gerarchia globale. Considerate le premesse, la particolarità più interessante della soluzione OmniRoot sono i termini di utilizzo del servizio.
Figura 1 Certificato radice globale Cybertrust
Figura 1 Certificato radice globale Cybertrust (Fare clic sull'immagine per ridurla)
Figura 1 Certificato radice globale Cybertrust
Figura 1 Certificato radice globale Cybertrust (Fare clic sull'immagine per ingrandirla)
Il servizio OmniRoot è stato progettato in modo specifico per il tipo di distribuzione PKI implementata all'interno della LSU. Nel programma OmniRoot le organizzazioni pagano a Cybertrust una tariffa annuale fissa per la partecipazione al programma e una tariffa per singolo certificato, solo per i certificati creati per l'utilizzo pubblico. In altre parole la LSU può emettere un qualsiasi numero di certificati per l'utilizzo interno, senza problemi di aumento dei costi a causa delle tariffe per singolo certificato. Al contempo, il costo attuale dei certificati pubblici è notevolmente ridotto rispetto alla tariffa pagata quando l'università acquistava i certificati in base alle necessità.
È bene chiarire che dal punto di vista tecnico i certificati interni e i certificati pubblici sono identici, poiché vengono emessi dalla stessa catena di CA, utilizzano lo stesso livello di crittografia e ne viene effettuato il provisioning tramite lo stesso sistema di autorità di registrazione. L'unica differenza tra i due tipi di certificati è rappresentata dai termini del Contratto di licenza.
È stato infine possibile espandere e migliorare la piattaforma di protezione IT della LSU a un costo inferiore. Questo ha consentito di predisporre un eccezionale business case per questo tipo di soluzione PKI presso la LSU. Ora è possibile esaminare i dettagli più tecnici della distribuzione.

Gerarchia PKI
La gerarchia PKI della LSU si basa su una struttura a due livelli, in cui il livello radice è gestito da Cybertrust e una CA emittente in linea risiede presso la LSU (vedere la Figura 2). Il livello radice rappresenta il punto di ancoraggio per la relazione di trust all'interno della gerarchia. In altri termini la relazione di trust di tutti i certificati emessi da una CA nella gerarchia appartiene alla CA radice (vedere la Figura 3). Pertanto, la CA radice costituisce il collegamento comune tra tutte le CA, i certificati e le entità finali all'interno della gerarchia. Poiché l'Autorità di certificazione radice globale Cybertrust è già incorporata in Windows® e in ogni altro sistema di elaborazione attuale, il collegamento comune si estende automaticamente oltre la rete della LSU.
Figure 2 Gerarchia PKI a due livelli (Close Figure 2)

Livello radice (Cybertrust) | Livello di emissione (LSU)
Gestito da Cybertrust | Gestito dalla LSU
Disponibile nel centro dati protetto di Cybertrust | Disponibile nel campus di Baton Rouge della LSU
Incluso nel certificato radice predefinito di quasi tutti i sistemi di elaborazione attuali | Rilascia certificati alle entità finali all'interno delle organizzazioni dei sistemi della LSU
 | I certificati emessi dalla LSU appartengono all'Autorità di certificazione radice Cybertrust e pertanto sono globalmente attendibili
Figura 3 Certificato emesso dalla CA emittente della LSU
Figura 3 Certificato emesso dalla CA emittente della LSU (Fare clic sull'immagine per ridurla)
Figura 3 Certificato emesso dalla CA emittente della LSU
Figura 3 Certificato emesso dalla CA emittente della LSU (Fare clic sull'immagine per ingrandirla)
Cybertrust gestisce la CA radice in una delle proprie strutture di hosting protette. La struttura di hosting prevede l'utilizzo di controlli di protezione fisici, tra cui barriere, blocchi biometrici e un archivio completamente ricoperto da una camicia di rame. Cybertrust rilascia certificati solo alle CA emittenti delle organizzazioni in grado di garantire la conformità ai propri criteri di protezione e certificazione.
La CA emittente della LSU è un sistema che interagisce con le entità finali, responsabile del rilascio di certificati agli utenti e ai computer della LSU. Il certificato dell'emittente è firmato dalla CA Cybertrust, posta al livello superiore della gerarchia, e i certificati emessi creano una catena fino alla CA radice Cybertrust (vedere la Figura 3).

Sistema operativo e hardware di emissione
La LSU utilizza Windows Server® 2003 Enterprise Edition con Service Pack 1 per la CA emittente. Il servizio Autorità di certificazione di Windows Server 2003 offre numerose nuove funzionalità, tra cui archiviazione di chiavi, elenchi di revoche di certificati (CLR) delta e modelli "versione 2". L'istanza di Windows utilizzata come CA emittente viene creata in base ai criteri standard relativi alla creazione di Windows Server della LSU. In tale istanza vengono implementati tutti gli aggiornamenti di protezione pertinenti e l'istanza viene gestita mediante le procedure di gestione delle modifiche della LSU standard e gli strumenti per l'aggiornamento e l'inventario software. In breve, sebbene la gestione del servizio CA sia caratterizzata da alcuni aspetti univoci, l'integrazione del sistema operativo e dell'hardware del server di base nelle operazioni IT esistenti dell'organizzazione risulta piuttosto semplice.
Oltre a seguire le procedure consigliate della LSU standard per l'installazione dei server, si sono sfruttati i vantaggi offerti dalla Configurazione guidata impostazioni di sicurezza (SCW), disponibile in Windows Server 2003 Service Pack 1. Lo strumento SCW utilizza un database con le matrici delle dipendenze dei diversi carichi di lavoro che è possibile eseguire su Windows Server e il tipo di impostazione di protezione richiesto dai carichi di lavoro. Nel database sono inclusi i due ruoli principali forniti dalla CA: lo stesso servizio CA e IIS (per il sito Web self-service PKI).
L'utilizzo della Configurazione guidata impostazioni di sicurezza ha consentito di creare con facilità un modello di protezione, che ha determinato la disattivazione di tutti i servizi non necessari per l'esecuzione dei carichi di lavoro e ha garantito la protezione avanzata dello stack di rete del server. Si è utilizzato quindi il file scwcmd.exe per convertire questo modello in oggetto Criteri di gruppo, in modo da poterlo applicare al server a livello di unità organizzativa. Grazie a questo approccio è stato possibile semplificare la scalabilità verticale e il ripristino di emergenza, poiché la configurazione della protezione basata sui ruoli per una CA della LSU viene ora archiviata in Active Directory, invece di essere specifica del computer.
La CA emittente della LSU è integrata in un server IBM xSeries 346 con doppio processore Intel Xeon da 3,2 GHz, 4 GB di RAM e cinque dischi rigidi SCSI da 146 GB. Considerati gli elevati livelli di prestazioni necessari per il servizio CA e il fatto che la LSU utilizza un modulo di protezione hardware, questa piattaforma dovrebbe garantire una lunga durata e nuove opportunità di espansione.
In conformità con le procedure consigliate standard per la separazione dei database e dei file di registro su unità fisiche distinte, sono stati creati due array RAID 1. Il quinto disco rigido viene gestito come unità di riserva a caldo ed è disponibile per entrambi gli array. Il primo array è stato montato come volume di sistema in cui viene conservato il database della CA. Il secondo array viene utilizzato per i file di registro e altri file di dati, come gli elenchi di revoche dei certificati. Il database della CA si basa sulla stessa tecnologia Jet utilizzata per altri componenti di Windows, come Active Directory, e pertanto sono applicabili le stesse procedure consigliate per la manutenzione e la configurazione dei dischi impiegate per le altre soluzioni di archiviazione basate su Jet.
Un modulo di protezione hardware (HSM) è un dispositivo hardware dedicato, gestito separatamente dal sistema operativo. I moduli HSM vengono in genere forniti come schede PCI, ma sono anche disponibili come apparecchiature in rete. Questi moduli costituiscono un archivio hardware protetto per le chiavi della CA e un processore di crittografia dedicato per rendere più rapide le operazioni di firma e crittografia. In Windows il modulo HSM viene utilizzato tramite le interfacce CryptoAPI: il modulo HSM viene considerato come un dispositivo del provider del servizio di crittografia (CSP). Il programma OmniRoot richiede che ogni CA utilizzi almeno un modulo HSM certificato FIPS 140-2 di livello 3 (i dispositivi di livello 4 sono piuttosto rari) per la generazione e l'archiviazione delle chiavi. Un modulo HSM è un dispositivo unico, con una protezione molto elevata, e richiede investimenti finanziari significativi; i prezzi di listino per i moduli HSM basati su PCI sono in genere compresi nella gamma tra gli 8.000 e i 12.000 Euro.
Nel progetto della LSU viene utilizzato come modulo HSM un modello 500 TPS (500 transazioni al secondo) nCipher nShield con collegamento diretto. Per "collegamento diretto" si intende che il modulo è interno al server e può essere utilizzato solo dal server specifico, al contrario di un modulo HSM in rete che può essere condiviso tra più host. HSM è un dispositivo FIPS 140-2 di livello 3 che garantisce la protezione di K di N dei materiali di definizione chiavi. Il modulo HSM garantisce un elevato livello di protezione contro i tentativi di compromissione delle chiavi private: un intruso, per accedere alla chiave, dovrà possedere sia il dispositivo di archiviazione HSM che un numero definito di token di accesso con i codici PIN corrispondenti.
È importante tenere presente che i moduli HSM sono progettati per impedire la manomissione del contenuto da parte di utenti non autorizzati. Per i moduli HSM viene dunque imposto un limite per i tentativi di accesso consecutivi non riusciti. Nel progetto della LSU il contenuto del dispositivo di archiviazione viene cancellato in modo irreversibile dopo 10 tentativi di accesso consecutivi non riusciti.
La configurazione della LSU prevede una singola CA e, pertanto, il prezzo per un modulo HSM in rete non è giustificato. Se, tuttavia, un'organizzazione prevede di implementare due o più CA, sarà molto meno costoso acquistare un singolo modulo HSM in rete e condividerlo tra le CA. Questo approccio consente inoltre di semplificare la gestione dei token, poiché è possibile proteggere tutti i dispositivi di archiviazione chiavi con lo stesso set di token.

Active Directory e registrazione
Uno dei principali vantaggi di una soluzione PKI basata su Windows è rappresentato dal fatto che il provisioning dei certificati viene effettuato senza installare software aggiuntivo sulle entità che fanno parte dell'infrastruttura PKI. Grazie a una combinazione di registrazione automatica e criteri di gruppo, gran parte del processo di provisioning dei certificati può essere gestito in modo autonomo e invisibile all'utente finale. La LSU utilizza questa tecnologia per la distribuzione automatica dei certificati di computer ai computer membri di Active Directory. Per fornire funzionalità di richiesta di certificati self-service per gli host non Windows, si è utilizzato un sito Web personalizzato.
Come affermato in precedenza, il programma OmniRoot opera una distinzione tra i certificati per uso pubblico e i certificati per uso interno. I certificati sono considerati pubblici se vengono utilizzati da sistemi e utenti che non fanno parte dell'organizzazione LSU, ad esempio quando un potenziale studente invia una domanda di ammissione mediante un sito Web protetto tramite SSL. I certificati utilizzati all'interno dell'organizzazione LSU, ad esempio quelli utilizzati per la crittografia dei dati sui server della LSU, sono considerati interni.
Poiché il costo del programma OmniRoot è basato sul numero di certificati pubblici, è necessario tenere traccia del numero di certificati pubblici emessi e degli utenti a cui vengono rilasciati. Quindi per qualsiasi certificato progettato per uso pubblico, il nome distinto del modello inizia con "PublicCertificate" e il nome visualizzato inizia con "Public Certificate". Il modello di certificato TLS della LSU destinato all'utilizzo pubblico è, ad esempio, basato sul modello del server Web Windows predefinito e viene definito Server Web LSU per certificati pubblici. Per i server Web utilizzati internamente viene impiegato un altro modello definito Server Web LSU per certificati interni. Dal punto di vista tecnico, i due modelli sono identici; le differenze di denominazione hanno il solo scopo di semplificare l'accounting.
Per soddisfare le esigenze di registrazione di massa, come la registrazione di interi reparti per i certificati da utilizzare con IPSec, viene utilizzata la funzionalità di registrazione automatica. Si tratta di uno strumento semplice e molto efficace, integrato in Windows. Dal punto di vista di un amministratore PKI, l'unica azione necessaria consiste nella modifica dell'elenco di controllo di accesso nel modello, con la concessione del diritto a eseguire la registrazione automatica a qualsiasi gruppo di utenti o computer che necessitano di certificati. Queste entità in seguito eseguiranno il controllo automatico di Active Directory, eseguiranno l'enumerazione dei modelli per i quali dispongono dell'autorizzazione alla registrazione automatica, individueranno le CA con tali modelli ed effettueranno la registrazione automatica dei certificati. La funzionalità di registrazione automatica garantisce inoltre che i certificati vengano sostituiti quando un modello viene sostituito e automaticamente rinnovato prima della scadenza.
Per attività diverse dalle operazioni di massa, come il provisioning di certificati per i server Web, si utilizza un sito Web self-service che consente agli utenti di richiedere certificati tramite un browser Web. Il sito è una versione personalizzata delle pagine di registrazione Web fornite con Windows Server 2003 (la directory virtuale /certsrv); l'implementazione comprende la personalizzazione Web standard della LSU e determina la precompilazione delle voci predefinite corrette nella pagina di richiesta. Per inviare automaticamente un avviso tramite posta elettronica al team di amministrazione di PKI quando una richiesta inviata tramite il sito necessita di approvazione, viene utilizzato il modulo di uscita predefinito del servizio CA di Windows.

Modello di revoca
Ciascun certificato prevede un periodo di validità. Accade talvolta che la LSU abbia l'esigenza di invalidare specifici certificati prima della fine del periodo di validità, ad esempio quando viene rilasciato un certificato il cui periodo di validità scade nel maggio 2007 a un dipendente che lascia la LSU nel gennaio del 2007. Questo tipo di revoca viene eseguito tramite gli elenchi di revoche di certificati, ovvero file che contengono un elenco di numeri di serie di certificati firmati da una CA. I numeri di serie contenuti in un elenco di revoche di certificati si riferiscono ai certificati il cui periodo di validità non è scaduto, ma che non vengono più considerati attendibili dalla LSU. I clienti possono quindi scaricare l'elenco di revoche di certificati e determinare la validità dei certificati in base a tale elenco.
Qualsiasi certificato x.509 v3 (eccetto il certificato della CA radice) deve specificare un puntatore a un elenco di revoche di certificati valido. Il puntatore viene definito punto di distribuzione CRL o CDP. Il punto di distribuzione CRL è incluso nel certificato stesso (vedere la Figura 4) e non può essere modificato dopo l'emissione di un certificato. L'elenco di revoche di certificati è un componente fondamentale per la garanzia della validità dei certificati emessi da una CA. Viene quindi verificato che gli elenchi di revoche di certificati della LSU siano fisicamente ridondanti, garantiscano elevata disponibilità e siano accessibili da entità esterne.
Figura 4 Punto di distribuzione CRL di LSU
Figura 4 Punto di distribuzione CRL di LSU (Fare clic sull'immagine per ridurla)
Figura 4 Punto di distribuzione CRL di LSU
Figura 4 Punto di distribuzione CRL di LSU (Fare clic sull'immagine per ingrandirla)
Una CA basata su Windows Server integrata in Active Directory (come la CA della LSU) pubblica automaticamente il relativo elenco di revoche di certificati in Active Directory, rendendolo accessibile tramite il protocollo LDAP. La posizione di pubblicazione predefinita corrisponde al contenitore CDP (vedere la Figura 5) all'interno del contenitore Servizi chiave pubblica della foresta. Questa posizione di pubblicazione rappresenta un'opzione straordinaria, perché offre funzionalità di replica automatica, tolleranza di errore e un percorso per le ricerche CDP.
Figura 5 Contenitore CDP
Figura 5 Contenitore CDP (Fare clic sull'immagine per ridurla)
Figura 5 Contenitore CDP
Figura 5 Contenitore CDP (Fare clic sull'immagine per ingrandirla)
Il progetto della LSU, tuttavia, prevede numerosi computer non Windows e non Active Directory che utilizzano l'infrastruttura PKI. Sebbene la LSU sia un'organizzazione di grandi dimensioni, la maggior parte degli utenti risiede sulla rete dello stesso campus, con un'area backbone da 10 Gbps, riducendo al minimo i vantaggi offerti dalla pubblicazione CDP basata su Active Directory.
L'elenco di revoche di certificati viene quindi pubblicato solo su un percorso HTTP, semplificando la creazione di una piattaforma host ridondante (il sito Web principale è già in mirroring). Si eliminano così le potenziali complessità associate all'attivazione di ricerche LDAP client. L'elenco di revoche di certificati viene pubblicato ogni giorno e gli elenchi di revoche di certificati delta ogni ora.

Sviluppi futuri
Microsoft prevede di apportare miglioramenti alle funzionalità della soluzione di protezione avanzata basata sull'infrastruttura PKI corrente per la comunità delle università. In Windows Vista™ e nella prossima versione di Windows Server (nome in codice "Longhorn") saranno disponibili numerose nuove funzionalità di gestione delle chiavi, che verranno debitamente analizzate. Microsoft è particolarmente interessata alle funzionalità pianificate del risponditore e del client Protocollo di stato del certificato in linea (OCSP), al supporto per gli algoritmi di crittografia a curva ellittica e SHA-256 e a un'interfaccia di registrazione automatica notevolmente migliorata. Si prevede inoltre di includere in Windows XP Service Pack 3 una funzionalità nota come credenziali mobili, che garantirà la protezione del roaming di coppie di chiavi, eliminando il significativo overhead associato ai profili mobili. È prevista infine l'analisi dell'utilizzo del Certificate Lifecycle Manager (attualmente disponibile in versione beta) per migliorare le funzionalità di gestione e reporting.
In conclusione l'infrastruttura PKI della LSU fornisce all'università un servizio di protezione di base utilizzato per la maggior parte delle funzioni IT di importanza critica. L'utilizzo del servizio OmniRoot di Cybertrust consente di eseguire un'infrastruttura PKI perfettamente integrata negli altri sistemi IT della LSU, con un'attendibilità che si estende a livello globale. Inoltre, la creazione della soluzione in base al servizio CA di Windows garantisce funzionalità di gestione e provisioning dei certificati efficienti, nonché una perfetta integrazione con il sistema di gestione delle identità e delle directory esistente. In breve la strategia globale alla base dell'infrastruttura PKI mirata a garantire protezione avanzata e relazioni di trust trasparenti sta già diventando realtà presso la LSU.

John Morello si è laureato con lode presso la Louisiana State University e ha lavorato per sei anni in qualità di Senior Consultant per Microsoft Consulting Services. Con MCS, ha progettato le infrastrutture PKI per clienti strategici come Deloitte, GE e diverse organizzazioni federali. Attualmente svolge la funzione di Deputy CISO presso la LSU.


 I desktop file: Un'analisi approfondita del formato Windows Imaging
I desktop file
Un'analisi approfondita del formato Windows Imaging
Wes Miller
L'articolo è basato sulle versioni preliminari degli strumenti di distribuzione di Windows e le informazioni riportate sono soggette a modifiche.

Con il rilascio di Windows Vista verranno modificate in modo significativo le modalità di installazione e distribuzione di Windows. Per Windows Vista (oltre che per la prossima versione di Windows Server, con nome in codice "Longhorn") sono stati infatti riscritti il modulo di installazione e l'intera suite di strumenti di distribuzione. In alcuni recenti articoli di
TechNet Magazine ho già illustrato queste novità e il lavoro svolto dal team di distribuzione di Windows®. Restano ancora molte cose da spiegare sull'argomento, quindi utilizzerò questo nuovo articolo per illustrare Windows PE, le operazioni di installazione e distribuzione di Windows e altri argomenti relativi alla gestione e protezione di Windows.
Nel primo paragrafo viene descritto il nuovo formato WIM (Windows Imaging). Se non si è già acquisita esperienza nel campo della gestione delle immagini, è possibile leggere una panoramica sull'argomento nel riquadro "Processo tipico di gestione delle immagini". In un prossimo articolo saranno illustrati Windows Automated Installation Kit (una nuova suite di strumenti che comprende ImageX, lo strumento da riga di comando che consente di creare e modificare immagini WIM) e Servizi di distribuzione Windows che sostituisce RIS (Remote Installation Services) e verrà evidenziato come i nuovi strumenti facilitino le operazioni di distribuzione del sistema operativo.

Punto di svolta
Ogni anno al team di distribuzione di Windows giungevano gli stessi commenti da OEM e clienti aziendali, che si aspettavano di ricevere miglior supporto e strumenti Microsoft unificati per la gestione delle immagini. Per questa categoria di utenti, l'onere da sopportare per la scelta e l'apprendimento dei complessi prodotti di altri fornitori è sempre eccessivo. Sia OEM che clienti aziendali si sono, inoltre, spesso lamentati di dover affrontare dei costi per l'acquisto di strumenti di gestione delle immagini da utilizzare per la distribuzione di Windows, strumenti che dovrebbero essere forniti gratuitamente da Microsoft.
Nelle prime fasi dello sviluppo di Windows Vista™, il team di distribuzione di Windows ha accettato la sfida e ha deciso di sostituire l'intero modulo di installazione, che conteneva componenti con oltre dieci anni di onorato servizio. La procedura di installazione è sempre stata un punto di particolare fragilità, con troppe fasi e operazioni. L'obiettivo era ottenere un modulo di installazione di Windows con procedure molto più rapide, senza operazioni non necessarie e perfettamente affidabile. È per questo che si decise di passare da un modulo di installazione sostanzialmente manuale a una procedura di installazione basata sulle immagini.

Progettazione di un nuovo formato per le immagini
All'inizio del processo di riprogettazione dell'installazione, si è cercato di definire il tipo di immagine da utilizzare. L'alternativa che si poneva era tra le immagini basate su settore o su file, vale a dire tra un formato di immagine in cui una copia del volume viene memorizzata come un duplicato settore per settore oppure un'immagine in cui ciascun file viene memorizzato individualmente. I vantaggi dei due approcci sono la velocità (nel caso dei settori) oppure la compressione (nel caso dei file). Al termine si è giunti a quello che è probabilmente il migliore dei compromessi tra i due approcci, con il risultato di ottime prestazioni a fronte di una compressione notevole.
Si sono, prima di tutto, definiti alcuni obiettivi chiave da raggiungere per ottenere immagini in un formato in grado di soddisfare le esigenze di utenti OEM e aziendali. In una prima fase il team era più orientato verso l'architettura basata su file. I vantaggi di questo tipo di approccio erano evidenti ed è stato naturale orientarsi in tal senso. Il primo risultato è stata la nascita dei file WIM (a chi è abbastanza curioso da chiedere per cosa stia la "M" dell'acronimo WIM, è bene chiarire che non ha alcun significato particolare. Il nome WIM si basa sugli eventi del team Windows che si ripetono in prossimità di ogni scadenza e sul fatto che *.WI sembrava un'estensione piuttosto strana). Di seguito sono riportati gli obiettivi che il team si è posto nello sviluppo del nuovo formato di immagini.
Neutro rispetto al formato del file system di Windows Il formato di immagine doveva funzionare con entrambe le architetture di file system supportate da Windows. Se è vero, infatti, che quasi tutti i sistemi vengono eseguiti in NTFS, presso molti OEM e aziende si utilizzano ancora i file system FAT per poter disporre di MS-DOS® nella distribuzione di Windows e si passa a NTFS solo in un secondo momento. Era quindi necessario continuare a supportare questa caratteristica con Windows Vista.
Neutro rispetto alla geometria dei volumi Era il momento di superare lo storico problema dell'applicazione di un volume acquisito di grandi dimensioni a un volume di dimensioni minori. Anche nei casi in cui si riesce a superare questa limitazione con degli artifici nella manipolazione delle partizioni, il volume che ne risulta non è affidabile. In un'architettura basata su file l'immagine occupa la stessa quantità di spazio occupata dai file che la costituiscono. Poiché il file system viene ripristinato in modo indipendente, non esiste alcun vincolo relativo alle dimensioni del volume.
Processo tipico di gestione delle immagini
Per duplicare un grande quantità di sistemi oppure per distribuire Windows su molti computer, OEM e grandi aziende in genere ricorrono a tecnologie di gestione delle immagini. La premessa dell'intero processo è la creazione di un sistema che sia configurato esattamente come necessario e che costituisca l'origine di tutti i sistemi di destinazione. In questo riquadro sono riportate le informazioni di base sulla gestione delle immagini, a beneficio degli utenti non particolarmente esperti.
  1. L'amministratore installa Windows su un sistema e lo configura secondo necessità, aggiungendo e rimuovendo dei componenti, installando le applicazioni di uso più frequente e modificando l'interfaccia utente e altre impostazioni. Questo viene definito come sistema host.
  2. L'amministratore quindi esegue Sysprep (fornito da Microsoft con gli strumenti di distribuzione di Windows), che utilizza per rimuovere tutti gli attributi che rendono unica un'installazione di Windows, ad esempio il nome del computer, l'identificatore di protezione (SID) di Windows e altri elementi di identificazione del sistema. Gli attributi verranno reimpostati durante la seconda parte dell'esecuzione di Sysprep.
  3. L'amministratore quindi spegne il computer e lo riavvia in Windows PE, MS-DOS o un altro sistema operativo che consenta l'esecuzione dell'applicazione di gestione delle immagini.
  4. A questo punto l'amministratore esegue lo strumento di gestione delle immagini e crea un'immagine del sistema di riferimento. L'immagine è un file (o un insieme di file) in cui è contenuta una copia esatta del disco o della partizione di riferimento.
  5. Il sistema viene spento e l'amministratore archivia l'immagine, che è sempre possibile aggiornare aggiungendo applicazioni, aggiornamenti rapidi e service pack.
  6. L'immagine viene copiata su uno o più computer e si porta quindi a termine l'operazione iniziata con Sysprep, eseguendo una versione abbreviata dell'installazione (definita installazione minima o Configurazione e personalizzazione di Windows, a seconda della versione di Windows su cui si esegue Sysprep e della configurazione di Sysprep). Le operazioni eseguite in questa fase si basano su un piccolo file eseguibile in modalità nativa denominato setupcl.exe.

Neutro rispetto all'architettura del sistema L'architettura dell'immagine doveva funzionare con qualsiasi architettura supportata da Windows. In quei giorni questa affermazione presupponeva il supporto di architetture molto diverse, come x86 e IA64 (Intel Itanium). Oggi si è aggiunta anche l'architettura x64 (AMD64 e EM64T).
Acquisizione e applicazione rapide Data la compressione, l'acquisizione dell'immagine doveva essere relativamente rapida e, ancora più importante, l'applicazione dell'immagine doveva risultare più veloce.
Supporto di un'applicazione di gestione immagini non distruttiva Poiché si trattava di rimpiazzare l'opzione di aggiornamento (con cui si sostituisce Windows senza influire sui dati o sulle applicazioni dell'utente), oltre che di ottenere uno strumento da utilizzare per il ripristino del sistema, era necessario offrire agli utenti la possibilità di generare l'immagine di un sistema senza eliminare i dati già presenti sul volume. I formati basati sui settori, a meno di interventi complessi da parte dell'utente, non consentono di ottenere questi risultati. In genere o si ripristina un intero volume oppure non si ripristina nulla.
Supporto di una compressione vantaggiosa Nelle prime fasi dello sviluppo di Windows Vista si pensava ancora di distribuire il prodotto su CD. Se si considera che un'immagine di Windows XP occupa circa 1 GB, era dunque importante comprimere quanto più possibile l'immagine. Esistono degli accorgimenti applicabili a immagini basate sui settori e che consentono di ottenere una buona compressione, ma l'alto numero di parti in gioco in un processo del genere erano fonte di preoccupazione. In molti formati basati sui settori gli spazi vuoti sul disco vengono omessi per risparmiare spazio (non ha infatti senso registrare uno 0 in un'immagine quando lo 0 esiste già in partenza). Con l'adozione di un approccio basato sui file, tuttavia, il problema è stato risolto alla radice, dal momento che gli spazi vuoti non vengono registrati per definizione.
Supporto di singole istanze dei file Vale quanto detto sopra. È noto che in Windows vengono memorizzate più copie del medesimo file in varie posizioni. Con l'approccio basato sui file è più semplice memorizzare un'unica istanza di ciascun file da utilizzare secondo le diverse necessità.
Supporto dello spanning su più supporti (dischi) Già nelle prime fasi dello sviluppo di WIM, quando si pensava di poter di utilizzare un singolo CD per contenere un'immagine, si era già consapevoli della necessità di utilizzare più supporti. Se anche si distribuisce Windows su un solo CD, l'aggiunta di applicazioni, service pack e altri dati dell'utente, comporta con ogni probabilità l'aumento delle dimensioni dell'immagine ben oltre il singolo CD o DVD. Era dunque necessario consentire agli utenti di estendere le soluzioni di ripristino o installazione su più supporti.
Supporto di più immagini di volumi in un unico Blob di file È raro che una singola immagine sia utilizzabile per qualsiasi esigenza. Insieme alla funzione di "istanza singola", è stata prevista anche la possibilità di scegliere più di un volume, con le medesime compressione e istanza singola applicate a ciascuno dei volumi. Ne consegue che quando si sceglie un'immagine di Windows XP Professional e si aggiunge una nuova immagine di Windows XP Tablet PC Edition (ovvero un superset di Windows XP Professional), le dimensioni dell'immagine aumentano solo della quantità che corrisponde ai file esplicitamente diversi nelle due versioni.
Un utente OEM o aziendale può, quindi, aggiungere più immagini derivate senza che si verifichi un aumento esponenziale delle dimensioni. Un risultato che non sarebbe stato facile raggiungere con i formati basati sui settori.

Funzionamento di WIM
Il formato di WIM è stato progettato in modo da risultare quanto più semplice possibile, pur rispettando tutti i principi guida che il team si era posto. L'approccio basato sui file ha consentito di raggiungere questo obiettivo grazie alle caratteristiche illustrate di seguito.
In poche parole è possibile paragonare un file WIM a un file CAB (simile per formato a un file ZIP, ma progettato e proprietario di Microsoft). In effetti capita di sentire attribuire al formato WIM l'appellativo di "figlio di CAB". La differenza sostanziale tra un file WIM e un file CAB consiste nel fatto che in un'immagine WIM, oltre all'acquisizione e compressione dei file in senso proprio, vengono memorizzati anche dei metadati relativi ai file e alle directory che costituiscono il volume acquisito in una determinata immagine del volume. Un file WIM è, dunque, una sorta di file di archivio completo di tutte le informazioni necessarie per il ripristino del volume nello stato in cui si trovava al momento della creazione, completo di elenchi di controllo di accesso (ACL), nomi file lunghi e brevi, attributi e così via.
È opportuno sottolineare che in nessuna fase del processo di acquisizione vengono raccolte le informazioni di partizione (dimensioni o tipo), né viene eseguita la partizione del sistema durante il processo di applicazione. A differenza della maggior parte di strumenti di gestione delle immagini, ImageX, in quanto neutro rispetto al tipo di partizione, richiede che le partizioni vengano create e formattate prima dell'applicazione dell'immagine. Per automatizzare il processo prima dell'applicazione dell'immagine, è necessario utilizzare i comandi da riga di comando diskpart e format.
Non è imposto alcun limite al tipo di dati che è possibile memorizzare in un'immagine di volume. In un'immagine possono coesistere due volumi, il medesimo volume acquisito un martedì e un giovedì, un'immagine con un service pack e un'immagine senza oppure qualsiasi altro tipo di dati necessari. Il concetto di fondo che è importante comprendere è l'acquisizione unica di file identici. Meno file hanno in comune due immagini di volume, maggiore sarà lo spazio occupato.
È importante sottolineare che non sono previste limitazioni per il formato WIM che ne impediscano l'impiego anche con versioni precedenti di Windows. Il funzionamento resta identico sia con Windows 2000 che con Windows Vista. A questo punto è possibile esaminare in maggior dettaglio le procedure di acquisizione e applicazione delle immagini.

Acquisizione di un'immagine
Durante l'acquisizione dell'immagine di un volume, si verificano i seguenti eventi:
Acquisizione dei metadati del volume In ImageX vengono raccolti i dati relativi a nomi di file, SCL NTFS e altri attributi del file system sull'intero volume (è possibile decidere di escludere determinati file con uno script).
Acquisizione dei dati del file Il file viene caricato da ImageX. Ciascun file viene caricato nel volume e si prepara la raccolta di determinati dati relativi al file.
Generazione dell'hash del file Viene generato un hash crittografico del file, basato sullo stesso file. L'hash diviene l'unico identificativo dei file presenti nell'immagine.
Controllo e rimozione dei duplicati Se nell'immagine esiste già un altro file con il medesimo hash, si presume che si tratti dello stesso file. Il nuovo file viene memorizzato solo come riferimento al file già esistente.
Compressione dei dati dei file univoci A differenza dei file CAB o di molti altri formati di archiviazione, ciascun file acquisito in un file WIM viene compresso singolarmente invece che in una serie di file raggruppati come un unico flusso di dati. È possibile decidere di non eseguire alcuna compressione e, in tal caso, questo passaggio viene ignorato.
Compressione e archiviazione dei metadati del volume Dopo l'archiviazione di tutti i file, viene creata una voce dei metadati per il volume. Nella voce vengono riportati tutti i file inclusi nell'immagine del volume.
Generazione e archiviazione dei dati XML dell'immagine Un riferimento per ciascuna immagine di volume acquisita. Se, ad esempio, si esegue ImageX /info, verranno visualizzati questi dati XML.
Scrittura dell'indice dei dati WIM nella cache Infine, viene scritto l'indice principale dei dati (insieme ai dati nella cache). Si tratta della tabella di file principale per l'intero file WIM, compresa una voce per hash.
È quindi evidente che un WIM viene creato file per file. Il file WIM sarà sempre uno, indipendentemente dal numero di volumi che si aggiungono all'immagine.

Approcci diversi all'acquisizione di immagini
Quando il team ha iniziato a lavorare sul formato WIM, altri team stavano sviluppando soluzioni simili. Il team Automated Deployment Services stava sviluppando una soluzione di gestione delle immagini per una diversa tipologia di clienti. L'approccio seguito da quel team prevedeva modalità di implementazione a basso livello molto interessanti, ma il modulo di gestione delle immagini adottato, come quasi tutti a quel tempo, era basato sui settori. Anche il team Windows XP Embedded aveva sviluppato un modulo di gestione immagini basato sui settori che consentiva a un fornitore di hardware indipendente (IHV, Independent Hardware Vendor) di distribuire le proprie immagini al momento della produzione dei sistemi. Quando è stato acquisito da Microsoft nel 2003, il team Virtual PC ha portato in dote un altro formato per i file dei dischi rigidi virtuali (VHD, Virtual Hard Disk).
Tutti questi formati erano basati sui settori, rispondevano alle esigenze dei rispettivi segmenti di mercato, ma non alle linee guida definite per il formato WIM. La creazione del nuovo formato WIM è andata avanti, così come lo sviluppo dello strumento da riga di comando ImageX per l'acquisizione delle immagini. Con il passare del tempo, alcuni degli altri team hanno deciso di adottare il formato WIM molto prima che questo fosse pubblicamente disponibile come componente della versione beta di Windows Vista. Il team SMS, ad esempio, ha prodotto una prima implementazione di WIM nell'Operating System Deployment Feature Pack.

Applicazione di un'immagine
A questo punto si può esaminare il processo opposto: l'applicazione di un'immagine
Caricamento dell'indice dei dati WIM nella cache Questa operazione è correlata all'ultimo passaggio della procedura precedente. Poiché si tratta dell'indice principale, questa è la prima sezione dei dati che deve essere caricata dal file WIM dopo la scelta dell'immagine di volume da applicare.
Recupero e caricamento dei metadati dell'immagine I metadati specifici per ciascuna immagine di volume vengono caricati con ImageX.
Creazione della struttura di directory Per garantire che esista una posizione in cui ripristinare ciascuno dei file, viene ricreata l'intera struttura di directory del volume.
Estrazione dei dati dei file I file vengono estratti dal file WIM, rispettando l'esatta sequenza con cui sono stati archiviati.
Applicazione dei dati dei file Durante questa fase, i file vengono caricati, decompressi (se l'immagine del volume è stata compressa nel file WIM) e copiati nella posizione di riferimento. Vengono infine applicati tutti i metadati per ciascun file.
Applicazione di tutti i metadati delle directory È importante che questo sia l'ultimo passaggio, poiché è possibile che l'ACL di una directory impedisca la corretta applicazione dell'immagine.

Compressione flessibile
Le opzioni di compressione flessibili sono uno degli obiettivi principali che il team si è posto con la creazione del formato di gestione delle immagini WIM. Ora è possibile, se necessario, acquisire l'immagine di un volume comprimendola, ma anche acquisire l'immagine senza applicare alcuna compressione. Le immagini non compresse sono particolarmente adatte agli scenari in cui non sono prevedibili problemi di spazio oppure quando è di fondamentale importanza la velocità dell'acquisizione.
È opportuno tenere sempre presenti alcune considerazioni fondamentali relative alla compressione. Il processo di compressione impiega sempre più tempo della decompressione. Quanto più è aggressivo l'algoritmo di compressione, tanto maggiore sarà il tempo necessario per la compressione di un determinato insieme di dati. Maggiore è, inoltre, la quantità di dati a cui si applica un algoritmo di compressione, migliore sarà la qualità della compressione.
È possibile comprimere le immagini WIM utilizzando XPress o LZX oppure, ovviamente, non applicare alcuna compressione. XPress rappresenta un ottimo compromesso nei casi in cui sia necessaria una certa compressione, ma non si desidera dedicare troppo tempo al processo di acquisizione. LZX garantisce invece il miglior rapporto di compressione ma, come è facile immaginare, richiede tempi più lunghi.
Se non si applica alcuna compressione, si otterrà l'acquisizione più rapida possibile ma anche l'immagine di maggiori dimensioni. Il tipo di compressione è un'opzione che viene applicata in base al file WIM. Dopo aver acquisito un'immagine di volume in un file WIM, tutte le immagini del volume future dovranno essere acquisite con la medesima impostazione di compressione.
Ciò accade perché le immagini WIM vengono compresse file per file e la compressione non è completa come potrebbe. Questa è stata una decisione presa in piena coscienza da parte del team per facilitare gli interventi di modifica dell'immagine. La possibilità di modificare le immagini dopo l'acquisizione è importante. Perché sia possibile modificare un file dopo l'acquisizione dell'immagine, è necessario sostituire i dati del file e i metadati corrispondenti. Se il file WIM venisse compresso in un'unica soluzione, il supporto per la modifica dei file sarebbe eccessivamente complicato (forse impossibile) da implementare e la sostituzione di un file all'interno dell'immagine richiederebbe tempi molto lunghi. Il compromesso adottato dal team ha consentito di ottenere un formato con una buona compressione e un'ampia possibilità di modifica tramite gli strumenti forniti.
In questo articolo è stato illustrato, si spera in modo chiaro, il funzionamento della gestione delle immagini in Windows Vista. Nel prossimo articolo verranno descritti alcuni degli strumenti da utilizzare per la gestione e distribuzione delle immagini WIM, con un'analisi più approfondita di ImageX e Servizi di distribuzione Windows.

Wes Miller è Development Manager presso Pluck (www.pluck.com) ad Austin, Texas. Wes ha lavorato in precedenza per Winternals Software ad Austin e in Microsoft come Program Manager e Product Manager per Windows. È possibile contattare Wes scrivendo all'indirizzo technet@getwired.com. Wes ringrazia John Macintyre, il responsabile del WIM/ImageX Program in Microsoft, per l'assistenza ricevuta durante la redazione di questo articolo.


 Windows - Informazioni riservate: Aspettando RunOnce
Windows - Informazioni riservate
Aspettando RunOnce
Sul sito Web di Raymond Chen

SI CONSIDERI UN processo di installazione che richiede il riavvio del sistema mentre è in esecuzione. È possibile ad esempio che sia necessario aggiornare una DLL di sistema già in uso. In tal caso è necessario eseguire un riavvio intermedio per recuperare il nuovo file DLL installato e, una volta completato l'aggiornamento della DLL, sarà possibile utilizzarla nella fase successiva dell'installazione.
La chiave RunOnce è stata progettata specificamente per uno scenario di questo tipo, ovvero per essere utilizzata dai programmi di installazione per completare l'installazione dopo un riavvio intermedio (questo avveniva in un'epoca in cui si riteneva che i programmi non potessero creare problemi al sistema).
Esplora risorse di Windows® attende il completamento dell'esecuzione del programma RunOnce prima di creare il desktop e la barra delle applicazioni. Questo avviene in quanto RunOnce opera in base al principio secondo il quale la chiave è stata progettata esclusivamente per i programmi di installazione. È possibile che il programma RunOnce stia modificando i dati di configurazione del sistema e che non si desideri che l'utente utilizzi un sistema mentre è in corso la riconfigurazione.
Si supponga, ad esempio, che il programma RunOnce stia eseguendo la riassegnazione e l'associazione dei file appena installati e che alcuni di questi file facciano parte di un 'estensione della shell. In tal caso si desidera certamente evitare che l'utente tenti di eseguire il programma o attivare l'estensione mente è ancora in corso l'aggiornamento dell'eseguibile.
Un'altra insidia legata al principio "progettato esclusivamente per i programmi di installazione" è rappresentata dal fatto che la chiave RunOnce viene elaborata solo se l'accesso viene eseguito da un utente con privilegi di amministratore. Gli utenti che non dispongono di privilegi di amministratore non saranno in grado di completare l'installazione. Se inoltre la chiave RunOnce venisse eseguita per utenti non amministratori, non verrebbe più "eseguita una sola volta". Uno scenario di questo tipo comporterebbe un problema piuttosto serio, poiché l'utente non sarebbe in grado di impedire che la chiave, una volta eseguita, venga eseguita di nuovo. La modifica di questo stato a livello di sistema richiederebbe la disponibilità di privilegi di amministratore, privilegi che ovviamente un utente non amministratore non possiede. Il programma non verrebbe più "eseguito una sola volta", ma verrebbe "rieseguito continuamente fino a quando un amministratore non esegue l'accesso al computer".

(Fare clic sull'immagine per ridurla)

(Fare clic sull'immagine per ingrandirla)
La chiave RunOnce, progettata per consentire il completamento dell'installazione dei programmi, è visibile durante l'installazione di Windows. Quando si tenta di installare un service pack o un aggiornamento a una versione più recente di Windows, l'Installazione guidata esegue il controllo della chiave RunOnce. Se non è vuota, verrà visualizzato un messaggio di errore in cui si informa che è ancora in corso l'installazione di alcuni programmi e si chiede di completare l'installazione prima di eseguire l'aggiornamento del sistema operativo. Questo messaggio consente di evitare di modificare il sistema operativo proprio nel mezzo del processo di installazione di un programma.
La progettazione globale della chiave RunOnce ne rivela lo scopo principale. È stata realizzata in Windows 95, un sistema operativo che non prevedeva alcuna distinzione tra amministratori e utenti non amministratori. Poiché, in sostanza, ogni utente disponeva dei privilegi di amministratore in Windows 95, un programma di installazione che utilizzava RunOnce poteva basarsi sul fatto che le azioni di RunOnce sarebbero state certamente eseguite al successivo riavvio del sistema.
Nei sistemi operativi Windows più recenti, in particolare in Windows Vista™, è possibile che per alcuni mesi consecutivi nessun utente con privilegi di amministratore esegua l'accesso. Di conseguenza, un programma che richiede l'esecuzione di RunOnce si troverà nella necessità di stare in attesa per lunghi periodi di tempo.
Si sono verificate situazioni in cui si è potuto assistere a un RunOnce perpetuo, che si riaggiungeva alla chiave RunOnce a ogni esecuzione. Questo comportamento non è chiaramente conforme allo scopo della progettazione della chiave RunOnce, poiché implica che la chiave non fa più parte dell'installazione del programma ma del normale funzionamento del programma e causa inoltre la continua visualizzazione durante l'esecuzione del programma di installazione di Windows di messaggi che informano che è in corso un'installazione.
Non è mai possibile eseguire l'aggiornamento del sistema operativo, dal momento che questo fastidioso programma visualizza continuamente un messaggio che invita l'utente ad attendere il completamento di un'installazione. Un'attesa che somiglia molto a quella del celebre Godot, sebbene non in grado di provocare, si spera, la stessa crisi esistenziale.

Sul sito Web di Raymond Chen, The Old New Thing (in inglese), è possibile leggere la cronologia di Windows e della programmazione Win32. Raymond Chen sta lavorando a un libro dal titolo The Old New Thing (Addison-Wesley, 2007).