Post MortemMigrazione 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 **(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

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 **(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.

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