Exchange 2010 RPC Client Access Cross-Site Connectivity Changes – Parte 2

Dalla pubblicazione del precedente post su quest’argomento ho già avuto diverse occasioni di lavorare su questa nuova feature, introdotta da Exchange 2010 SP2 + Update RollUp 3+.

L’argomento è “caldo” soprattutto per l’impatto che ha sui client, mi riferisco alla disconnessione ed al pop-up che segnala all’utente la modifica al suo profilo MAPI ed alla necessità di riavviare Outlook per riprendere la connessione con la propria mailbox:

“The Microsoft Exchange Administrator has made a change that requires you quit and restart Outlook”

Il cambiamento introdotto si manifesta su infrastrutture con DAG distribuiti su diversi site AD, questo significa che abbiamo a che fare con infrastrutture di una certa dimensione, con un elevato numero di utenti, quindi chi si trova ad amministrare infrastrutture di questa entità può capire cosa significa quando qualche centinaio di utenti (nel caso migliore) si trovino un pop-up (che spesso chiudono senza leggere :-)) che chiede di riavviare Outlook per riconnettersi alla mailbox: Allarme rosso!!!!! 🙂

Ora che conosciamo l’impatto sull’infrastruttura Exchange 2010, dal punto di vista Helpdesk :-), vediamo che vantaggi ci ha portato questa nuova feature.

Per descrivere il primo grosso vantaggio analizziamo un caso reale sul quale ho lavorato alcuni giorni fa:

image

– Site A e Site B rappresentano due Site AD differenti

– In ogni site è presente un solo server Exchange 2010, con tutti i ruoli (CAS, H&T, MBX)

– I due server sono membri di un DAG

– Il mailbox server A ospita le copie attive dei DB degli utenti del site A

– Il mailbox server B ospita le copie attive dei DB degli utenti del site B

Nei due site sono stati definiti due distinti CAS Array, per fare in modo che l’RPC Endpoint per i vari DB fosse un nome host risolto con l’ip del CAS locale, svincolato del nome host del server:

– “casarray-a.contoso.com” (CNAME di server-a.contoso.com)

– “casarray-b.contoso.com” (CNAME di server-b.contoso.com)

Quindi in realtà non ci sono dei veri e propri array di CAS, ma si è scelta questa soluzione per dare la possibilità di reindirizzare i client su un sito o sull’altro in modo manuale, in caso di down pianificato o non pianificato di uno dei due server, modificando i record DNS. In ogni caso il comportamento sarebbe lo stesso, anche in presenza di CAS Array “tradizionale”, quindi costituito da più di un Server CAS e da un meccanismo di load balancing.

Analizziamo il comportamento di questa infrastruttura, prima dell’introduzione dell’RPC CAS Cross-Site Redirection:

Supponiamo che il server B sia down, questo è ciò che accadrebbe:

1) Le copie dei DB si attivano tutte sul server A

2) I client RPC del site B perdono la connessione alla mailbox

3) Attraverso il Service Connection Point (SCP) pubblicato in AD i client del site B “scoprono” che il loro RPC Endpoint NON è cambiato, perchè viene restituito il valore di RpcClientAccessServer=outlook-b.contoso.com, impostato sul Mailbox Database che ospita le loro Mailbox

4) I client Outlook del site B non riusciranno a stabilire una connessione alla mailbox, a meno che non venga modificato manualmente il valore del record DNS “outlook-b.contoso.com” facendolo puntare al Server A.

A questo punto verrebbe da chiedersi: “Ma se invece modifico la proprietà RpcClientAccessServer sul mailbox database degli utenti del site B?”

La risposta è: “Non avrebbe nessun effetto, a meno che non venga eseguito il “repair” del profilo Outlook, su ogni client del site B”:

image

Analizziamo ora il comportamento di questa infrastruttura, dopo l’introduzione dell’RPC CAS Cross-Site Redirection:

Supponiamo che il server B sia down, questo è ciò che accadrebbe:

1) Le copie dei DB si attivano tutte sul server A

1) I client RPC del site B perdono la connessione alla mailbox

2) Attraverso il Service Connection Point (SCP) pubblicato in AD i client del site B “scoprono” che il loro RPC Endpoint è cambiato, non è più “outlook-b.contoso.com” ma “outlook-a.contoso.com”, cioè il CAS (array) che appartiene allo stesso site AD del Mailbox Server che ospita le copie attive dei loro Mailbox Database

3) Il profilo MAPI di Outlook viene riconfigurato e compare il pop-up che chiede di riavviare Outlook per riconnettersi alla mailbox

4) Quando l’utente riavvia il client Outlook viene stabilita la connessione con il server A (outlook-a.contoso.com)

In questo caso non è stato eseguito nessun intervento manuale.

Move Mailbox

La seconda novità, più che un’innovazione è la correzione di un bug, ovvero, prima dell’introduzione della nuova feature, se veniva eseguito il move di una mailbox tra DB ospitati su Mailbox Server di site AD differenti (con RpcClientAccessServer differente), non necessariamente in DAG, l’RPC endpoint definito nel profilo MAPI del client Outlook non veniva aggiornato, era neccessario eseguire questa manovra manualmente, eseguendo il “repair” del profilo.

Ora invece a seguito del move della mailbox, tra site AD differenti e con differente valore di RpcClientAccessServer, il client riceve attraverso la comunicazione RPC una segnalazione di “WrongServer” che come conseguenza produce un “discovery & update” del profilo MAPI.  A questo punto viene notificata all’utente la necessità di riavviare Outlook per ripristinare la connessione con la mailbox:

“The Microsoft Exchange Administrator has made a change that requires you quit and restart Outlook”

A presto

Roberto