È necessario molto tempo…

Articolo originale pubblicato lunedì 20 febbraio 2012

Dopo il recente annuncio del rilascio dell'Aggiornamento cumulativo 1 per Exchange 2010 Service Pack 2, si sarà notato che sono state rilasciate numerosissime correzioni. In questo blog ne verrà trattata una in particolare e verranno fornite allo stesso tempo alcune informazioni di base su come si manifestano problemi di questo tipo e su come vengono risolti.

La correzione specifica 2556113 viene indicata astutamente con il titolo È necessario molto tempo per un utente per scaricare una Rubrica offline in un'organizzazione Exchange Server 2010.

Un titolo di questo tipo potrebbe indurre a pensare che sia stato semplicemente individuato un modo per velocizzare i download della Rubrica offline, che siano stati eliminati a caso alcuni degli utenti nella Rubrica offline (quelli che non si conoscono, ad esempio le persone che lavorano nel reparto di contabilità al quarto piano), che si sia tentato di ridurre i dettagli inclusi nella Rubrica offline, forse rimuovendo semplicemente informazioni superflue come i cognomi, le ubicazioni degli uffici o i numeri di telefono oppure, infine, che sia stata semplicemente aumentata la velocità di Internet. Questo sarebbe veramente facile.

In realtà l'intervento non è stato di questo tipo (anche se si sta esaminando l'intera questione Internet per individuare una soluzione, per quanto possa sembrare sorprendente). È stata semplicemente aggiunta la logica necessaria per fare in modo che Outlook tenti di scaricare la Rubrica offline da un server Accesso client più vicino.

Chiedersi "Perché?" è una buona domanda, che trova una risposta, come nell'articolo della Knowledge Base, nella frase "Considerate lo scenario seguente…".

• Si dispone di due siti Active Directory in una rete lenta di un'organizzazione Microsoft Exchange Server 2010.
• Si dispone di un server Accesso client Exchange Server 2010 e di un server delle cassette postali Exchange Server 2010 in un sito Active Directory.
• Si dispone di un server Accesso client Exchange Server 2010 e si aggiunge un utente di Office Outlook nell'altro sito Active Directory.
• L'utente la cui cassetta postale è contenuta nell'altro sito Active Directory tenta di scaricare la Rubrica offline di Exchange.

In questo scenario è necessario molto tempo per scaricare la Rubrica offline.

Questa è la verità. Nel caso di una Rubrica offline di grandi dimensioni, il download può richiedere effettivamente molto tempo. È opportuno però espandere ulteriormente lo scenario, perché sono necessarie altre informazioni aggiuntive. L'esistenza inoltre di un sito Active Directory contenente solo un server Accesso client non sembra una mossa molto intelligente per la maggior parte delle persone.

Si consideri quindi uno scenario più esteso:

• Si dispone di una distribuzione centralizzata e tutte le cassette postali sono contenute in una posizione centrale.
• Si dispone di molte piccole postazioni in cui lavorano gli utenti.
• Queste postazioni sono connesse al sito centrale con reti lente. Satellite, ISDN, PSTN, diffusione troposferica(avevo un cliente con uno di questi sistemi una volta, intelligente, finché non ci fu un temporale), comunque una connessione di bassa qualità.
• La Rubrica offline è estesa. Indipendentemente dalla definizione che si preferisce, è possibile concordare sul fatto che la Rubrica offline sia di dimensioni significative.
• Il client di Outlook tenta di scaricare la Rubrica offline dal data center centrale. Il client di Outlook utilizzato dalla persone accanto procede nello stesso modo, così come quello del buffo giovane nell'angolo in fondo. Stanno tutti scaricando la stessa Rubrica offline. Sempre con la stessa connessione di bassa qualità e quindi molto lentamente.

È evidente che tutti si stanno contendendo la stessa larghezza di banda, tentando anche di lavorare, e benché la tecnologia client BITS utilizzata per i download della Rubrica offline sia efficiente, non sarà comunque di molto aiuto.

Viene pertanto aggiunto un server Accesso client a ogni postazione remota, come illustrato nel diagramma riportato in https://technet.microsoft.com/en-us/library/bb232155.aspx. L'idea è di fare in modo che il computer client scarichi la Rubrica offline dal server Accesso client locale. Potrebbe sembrare un'ottima idea, ma Exchange non ha mai funzionato in questo modo, almeno prima dell'aggiornamento cumulativo 1 per Exchange 2010 SP2…

Come funzionava allora? E come è possibile affermare che TechNet abbia mentito?

Per rispondere alla prima domanda, l'URL utilizzato dal client per il download della Rubrica offline viene fornito al client dal servizio di individuazione automatica. Il codice di individuazione automatica ha sempre selezionato un URL per la Rubrica offline da scaricare dal sito Active Directory in cui si trova la cassetta postale e non dal sito Active Directory in cui si trova il computer client.

Per rispondere alla seconda domanda, è importante sapere che TechNet non sbaglia mai (alcuni amici in Europa, come Scott Schnoll, diventano molto suscettibili se si insinua che i loro articoli non sono corretti). È solo che in alcuni casi non è corretto da un certo punto di vista. La descrizione fornita su TechNet viene indicata come parte della specifica della relazione finale originale definita al momento della progettazione della versione 2007. Probabilmente non avrei dovuto dirlo, ma è andata così. E non è stata portata a termine. Questo può accadere in un prodotto software con oltre 20 milioni di righe di codice quando è tutto in continua evoluzione. TechNet in genere non mente, o comunque non molto.

Torniamo ora al funzionamento. Si dispone di una Rubrica offline di 1 GB e si aggiunge una replica di tale Rubrica in un server Accesso client nel sito Active Directory remoto, dove si trovano gli utenti. Questi utenti comunque non la utilizzano mai (a meno che le relative cassette postali non si trovino nello stesso sito Active Directory, ma non è questo lo scenario corrente). Questo è un vero spreco, come illustrato nel diagramma seguente.

Outlook utilizza il server Accesso client più vicino al computer client per le richieste di individuazione automatica del client (almeno dovrebbe, torneremo su questo aspetto più avanti), ma l'URL della Rubrica offline che restituisce è relativo allo stesso sito Active Directory della cassetta postale. Quindi anche se la Rubrica offline viene replicata nel sito Active Directory B, il client la acquisisce dal sito Active Directory A.

Pertanto, un grosso cliente con molti piccoli siti e una Rubrica offline enorme segnala che questo sistema non funziona e che i download sono lentissimi, indipendentemente dalla larghezza di banda della rete WAN. Come è possibile procedere? Esistono alcuni modi per risolvere il problema e questo è uno degli aspetti più divertenti di questo lavoro, provare a risolvere questo tipo di problemi. È una cosa da geni del computer.

1. Il cliente potrebbe ridurre le dimensioni della Rubrica offline, velocizzare la rete WAN, avvicinare gli uffici remoti e così via. Nessuno di questi suggerimenti è stato accettato come soluzione, anche se comunque si è tentato.
2. Sarebbe possibile creare molte Rubriche offline con lo spesso contenuto e specificare per utente o per database la Rubrica offline che deve essere scaricata dall'utente. La Rubrica offline allora sarebbe disponibile solo nella postazione remota e pertanto il servizio di individuazione automatica fornirebbe l'unico URL esistente per essa, ovvero quello della postazione remota. Questa soluzione sembra buona, se non fosse che gli utenti si spostano da un sito all'altro e un download implicherebbe un doppio lento passaggio tra siti della rete. Questa soluzione quindi non verrà presa in considerazione.
3. Lo stesso vale per le cassette postali e per l'eventualità di spostarle nelle postazioni remote. Lo spostamento complicherebbe l'amministrazione e comporterebbe l'esigenza di una disponibilità elevata con un conseguente aumento dei costi.
4. Sarebbe possibile eseguire una specie di mapping inverso tra indirizzi IP e siti Active Directory. In origine si era pensato di risolvere il problema in questo modo, ma è difficile. Sarebbe necessario verificare che tutte le subnet di provenienza di un client siano contenute in Siti e servizi di Active Directory e quindi decompilare il sito Active Directory in cui si trova l'utente, esaminare i costi dei collegamenti del sito e altro ancora. È piuttosto evidente che si tratta di una soluzione complicata e resa impossibile da NAT o dall'eventualità che l'amministratore non elenchi tutte le possibili subnet in Siti e servizi di Active Directory.
5. Sarebbe possibile "interferire" con DNS o con il codice XML di individuazione automatica per indurre il client a ritenere di interagire con la posizione centralizzata anziché con un'istanza di IIS locale. Di nuovo, questa soluzione è difficile e complicata da implementare e supportare.
6. La soluzione doveva essere un'altra, poiché le altre scelte sembravano veramente difficili.

Tornando indietro di qualche paragrafo, nel punto in cui è stato affermato "Outlook utilizza il server Accesso client più vicino al computer client per le richieste di individuazione automatica del client", vale la pena introdurre il concetto di AutoDiscoverServiceSiteScope.

AutoDiscoverServiceSiteScope è un'impostazione del server Accesso client che consente al client di Outlook di eseguire il mapping tra i siti Active Directory e il server Accesso client per individuare il server Accesso client più vicino al client per le richieste di individuazione automatica. A tale scopo, ricerca i punti di connessione del servizio, che in pratica sono puntatori per il servizio di individuazione automatica.

Ecco come funziona. Quando viene avviato, un client di Outlook si dirige verso Active Directory e cerca tutti i punti di connessione del servizio inseriti dalla configurazione di Exchange. Ne individua un gruppo e ogni membro di tale gruppo è associato a un attributo Keywords, che è impostato/modificato/a volte complicato dall'utilizzo di Set-ClientAccessServer -AutoDiscoverServiceSiteScope: ADSiteNameA, ADSiteNameB e così via. Gli attributi Keywords vengono utilizzati per specificare i siti Active Directory di cui è responsabile il server Accesso client per le richieste di individuazione automatica.

Se il client di Outlook individua più punti di connessione del servizio, crea un elenco di punti di connessione del servizio utilizzabili confrontando il valore archiviato nell'attributo Keywords con il proprio sito Active Directory (aggiornato dinamicamente dal servizio locale Accesso rete all'avvio o quando cambia indirizzo IP).

Crea quindi un elenco contenente solo i punti di connessione del servizio che corrispondono al proprio sito Active Directory (dove attributo Keywords = sito Active Directory del client) oppure, se non ve ne sono, tutti i punti di connessione del servizio. Questi sono i server che possono essere utilizzati per le richieste di individuazione automatica.

Si avvia infine in corrispondenza dell'inizio dell'elenco (sempre nello stesso ordine, per data di installazione) e tenta di connettersi all'URI contenuto nell'attributo ServiceBindingInformation, ovvero la posizione del servizio di individuazione automatica. Pubblica il codice XML, ottiene una risposta e così via. Ulteriori informazioni sul servizio di individuazione automatica sono disponibili qui.

Perché tutto ciò è interessante? L'impostazione AutoDiscoverServiceSiteScope consente a Outlook di individuare il server Accesso client più vicino alla posizione del client, presupponendo che l'amministratore abbia configurato gli ambiti del sito correttamente (come ci raccomandiamo sempre con gli amministratori). Non è necessario pertanto capire quale sia il server Accesso client più vicino al client quando riceviamo la richiesta, poiché questa operazione è stata già effettuata nel momento in cui la richiesta raggiunge il server Accesso client.

Dopo che la richiesta ha raggiunto il server Accesso client, si tenta di capire quali impostazioni restituire al client, dimenticando sempre che la Rubrica offline richiesta dall'utente potrebbe essere locale nel server Accesso client in cui è in esecuzione la richiesta, mentre invece veniva sempre fornito all'utente un URL di un server Accesso client distante. È questo l'errore da correggere.

La soluzione è in teoria molto semplice e non implica la necessità di dover inventare un nuovo modo per individuare il server Accesso client più vicino al client. Esiste già una soluzione perfettamente funzionante.

Partendo dal presupposto che l'amministratore abbia configurato AutoDiscoverServiceSiteScope correttamente, il server Accesso client a cui si connette il client per l'individuazione automatica sarà quello più vicino. Se questo presupposto è valido, quando il server Accesso client tenta di individuare cosa restituire nel codice XML di individuazione automatica, deve semplicemente controllare se dispone di una copia della Rubrica offline valida per l'utente e, in tal caso, fornire semplicemente il proprio URL per la Rubrica offline. Questo non è valido per un server Accesso client nel sito Active Directory in cui si trova la cassetta postale dell'utente. Se naturalmente non è disponibile una copia della Rubrica offline utile per l'utente, prevarrà il vecchio comportamento e il server Accesso client restituirà l'URL della Rubrica offline di un server Accesso client nel sito Active Directory della cassetta postale.

La figura pertanto cambia come indicato di seguito:

Questa soluzione è molto più compatibile con la WAN. Viene replicata una copia sulla WAN e tutti i client in tale posizione ottengono la Rubrica offline dal rispettivo server Accesso client locale.

Come è possibile rendere effettivo questo nuovo comportamento? È sufficiente effettuare due operazioni. Distribuire l'aggiornamento cumulativo 1 per il Service Pack 2 nel server Accesso client e verificare che i parametri di AutoDiscoverServiceSiteScope siano configurati correttamente.

Mi auguro che queste informazioni possano rivelarsi utili e che la vostra rete WAN possa essere per sempre veloce ed efficiente.

Greg Taylor
Principal Program Manager
Exchange Customer Experience

Questo è un post di blog localizzato. L'articolo originale è disponibile in It Takes a Long Time…