Modifiche alla connettività tra siti dell'accesso client RPC

Articolo originale pubblicato mercoledì 30 maggio 2012

Quasi due anni fa ho presentato una sessione su alcune considerazioni di progettazione per garantire un'elevata disponibilità, High Availability Design Considerations, a TechEd Nord America 2010. Durante questa sessione ho descritto le modifiche che stavamo introducendo al modo in cui la connettività MAPI deve comportarsi dopo lo spostamento di cassette postali e gli eventi *over di database tra siti. Sfortunatamente, dopo la presentazione abbiamo escluso la funzionalità a causa della complessità delle modifiche che dovevamo introdurre e della mancanza di tempo per il testing prima del rilascio del Service Pack 1. Sebbene abbia quindi cercato di dare la priorità a queste modifiche, non siamo riusciti a includerle neanche nel Service Pack 2.

Purtroppo non tutte le ciambelle riescono con il buco, quindi una parte delle modifiche al codice sono rimaste nel SP1. Ad esempio, è possibile che abbiate notato che il cmdlet Set-DatabaseAvailabilityGroup ha una proprietà denominata AllowCrossSiteRPCClientAccess. Potete attivare questa proprietà booleana per qualsiasi contenuto, ma non determinerà alcun cambiamento di comportamento nel prodotto (per questo ritengo che questa immagine sia stranamente appropriata):

Comportamento di connettività tra siti dell'accesso client RPC (RTM, SP1, SP2 fino a SP2-RU2)

Ma sto divagando. Innanzitutto esaminiamo alcuni concetti base.

Con Exchange 2010 è stato introdotto un importante cambiamento al modo in cui i client si connettono e accedono ai dati relativi alle cassette postali. Diversamente dalle versioni precedenti, i client non si connettono più direttamente all'archivio informazioni sul ruolo server Cassette postali per accedere ai dati delle cassette postali. Si connettono invece a un insieme di servizi sul ruolo server Accesso client (CAS) e i servizi nel ruolo CAS accedono ai dati delle cassette postali usando MAPI/RPC dal server Cassette postali per conto dell'utente che si connette. Questo può essere considerato un livello di astrazione.

In pratica, è stata apportata una semplice modifica in modo che tutta la connettività MAPI relativa alle cassette postali passi attraverso il servizio di accesso client RPC sul ruolo server Accesso client. Per semplificare questo livello di astrazione, sono state introdotte modifiche tali che gli oggetti del database non sono più oggetti figlio dei server Cassette postali. È stata aggiunta una nuova proprietà al database delle cassette postali, RPCClientAccessServer, che definisce il valore legacyExchangeDN da usare per accedere al database in questione. Questa proprietà usa come valore un nome di dominio completo. Per garantire un'elevata disponibilità e la tolleranza d'errore in caso di un errore del server Accesso client, questo valore deve essere il nome di dominio completo di un array del server Accesso client con bilanciamento del carico. Tale nome di dominio completo con bilanciamento del carico è ciò che indichiamo come array del server Accesso client RPC.

Per ulteriori informazioni, fate riferimento ai post di Brian Day Chiarimenti sull'oggetto array di server Accesso client, Parte 1 e Parte 2.

Esperienza tipica con Outlook

Tutte le versioni di Outlook si comportano in modo coerente in un unico scenario di datacenter (o in un singolo sito Active Directory). L'endpoint RPC del profilo di Outlook è l'array del server Accesso client (o un server Accesso client specifico se per qualche motivo non avete creato un array, come avreste dovuto e se non sapete perché leggete i post di Brian). Ogni volta che si verifica un errore nel DAG (nel database, nel server e così via), l'endpoint RPC non cambia, pertanto Outlook continua a connettersi allo stesso array del server Accesso client RPC. Ogni volta che si verifica un errore nell'array del server Accesso client (nel server, nel servizio di bilanciamento del carico e così via), l'endpoint RPC non cambia, pertanto Outlook continuerà a tentare di connettersi all'array del server Accesso client.

Tutte le versioni di Outlook si comportano coerentemente anche in uno scenario di passaggio di datacenter, presupponendo che seguiate le nostre linee guida. Ciò è dovuto al fatto che, in un passaggio di datacenter, modificate l'indirizzo IP del DNS dell'array del server Accesso client RPC per il datacenter principale in modo che punti all'array del server Accesso client RPC del datacenter in standby. L'individuazione automatica continua a passare l'array del server Accesso client RPC per il datacenter principale come endpoint RPC. I client Outlook esistenti non devono essere riconfigurati, infatti una volta che la cache DNS del client viene aggiornata, il client si connette semplicemente all'endpoint che ora si trova nel datacenter in standby. Per comprendere appieno il funzionamento di questo meccanismo dovete considerare che né al client né al server Accesso client interessa il sito in cui si trova il server stesso, bensì accettano semplicemente di potersi connettere e che il server Accesso client a cui è connesso il client sia in grado di garantire l'accesso alla cassetta postale.

Comportamento *over nei database tra siti

Per comprendere questo scenario, è importante capire che quando configurate un DAG con più siti, la proprietà RPCClientAccessServer per un determinato database è in genere associata all'array del server Accesso client RPC che si trova nello stesso sito AD in cui è presente la copia del database delle cassette postali con il numero più basso di preferenza di attivazione. Ad esempio:

Figura 1: gruppo di disponibilità del database esteso a due siti Active Directory

         

Se nel datacenter in standby viene attivata una copia del database, gli utenti continueranno a usufruire dell'array del server Accesso client RPC dal sito AD in cui si trova il database delle cassette postali con il valore più basso di preferenza di attivazione.

Figura 2: il database MDB1 è stato attivato nel sito Active Directory in standby

Se esaminate i registri di Accesso client RPC nell'array del server Accesso client RPC noterete quanto segue:

2012-05-06T15:44:29.001Z,67,112,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SFPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.0468822,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 5/6/2012 3:43:23 PM, currently Mounted; LogonId: 5",

Se l'array del server Accesso client RPC nel sito AD in cui si trova il database delle cassette postali con il valore più basso di preferenza di attivazione diventi inaccessibile dagli utenti, i client Outlook non riescono a connettersi alle relative cassette postali che si trovano nel datacenter opposto. In pratica, si verifica un evento di interruzione del datacenter ed è necessario eseguire il processo di passaggio del datacenter.

Un modo più semplice di vedere questo comportamento è che Outlook si connette sempre all'endpoint RPC configurato (sempre che sia raggiungibile) indipendentemente dal valore della proprietà RPCClientAccessServer del database.

Il sistema può modificare automaticamente il valore di RPCClientAccessServer?

L'unico caso in cui il sistema modifica il valore di RPCClientAccessServer nel database è quando l'amministratore modifica il numero di ActivationPreference nella copia del database attivata in modo da diventare il valore più basso (quindi diventa la copia preferita), come mostrato nella figura 3.

Figura 3: il database MDB1 è stato attivato nel sito Active Directory in standby e la proprietà RPCClientAccessServer è stata modificata

I client Outlook con un profilo di Outlook esistente continuerebbero tuttavia a usare il precedente endpoint RPC invece del nuovo endpoint RPC (anche se l'individuazione automatica rileva il cambiamento). Ciò accade perché l'endpoint RPC precedente non restituisce una risposta ecWrongServer al client, bensì accetta la connessione. Pertanto Outlook ignora la risposta dell'individuazione automatica in quanto dispone di una connessione funzionante. Se l'endpoint RPC precedente diventa inaccessibile, Outlook 2007/2010 aggiorna le proprie impostazioni (cosa che non accade con Outlook 2003, poiché non si avvale dell'individuazione automatica). In qualsiasi momento potete imporre a Outlook di usare il nuovo endpoint RPC forzando un ripristino del profilo.

Cosa accade se l'amministratore aggiorna manualmente il valore di RPCClientAccessServer dopo un evento *over nel database tra siti?

Tornando alla figura 2, se l'amministratore aggiorna manualmente il valore RPCClientAccessServer in modo che punti a cas-sec.contoso.com per MDB1 dopo che la copia del database delle cassette postali su MBX-C è stata attivata (con un valore ActivationPreference maggiore di 1), i client Outlook con un profilo esistente continueranno a usare il precedente endpoint RPC invece del nuovo fintanto che quello precedente resta disponibile (il ripristino del profilo corregge questo problema). I profili di Outlook creati dopo la modifica del valore RPCClientAccessServer useranno il nuovo endpoint RPC.

Spostamento di cassette postali tra siti Active Directory

Prima del rilascio di Exchange 2010, se spostavate le cassette postali tra i server, l'endpoint RPC di Outlook si aggiornava puntando al server delle cassette postali (o all'istanza del server delle casette postali nel cluster) che ospitava il database in cui si trovava la cassetta postale. Dopo aver completato lo spostamento della cassetta postale, all'utente del client Outlook veniva mostrata la finestra di dialogo “L'amministratore di Microsoft Exchange ha apportato una modifica che richiede la chiusura e il riavvio di Outlook”. Dopo il riavvio di Outlook, il client si connetteva al nuovo endpoint RPC.

Con Exchange 2010, dovreste aver notato che quando spostate le cassette postali tra diversi siti AD, gli utenti non visualizzano questa finestra di dialogo. È possibile inoltre che abbiate notato che l'endpoint RPC degli utenti non viene aggiornato per riflettere l'array del server Accesso client RPC associato al database delle cassette postali nel sito AD in cui si trova attualmente la cassetta postale. Ciò accade poiché l'endpoint RPC precedente non restituisce una risposta ecWrongServer al client. L'endpoint RPC accetta la connessione, pertanto Outlook ignora la risposta dell'individuazione automatica in quanto dispone di una connessione funzionante. Se l'endpoint RPC precedente diventa inaccessibile, Outlook aggiorna le proprie impostazioni (cosa che non accade con Outlook 2003, poiché non si avvale dell'individuazione automatica). In qualsiasi momento potete imporre a Outlook di usare il nuovo endpoint RPC forzando un ripristino del profilo.

Ora sono sicuro che comprendete l'immagine precedente.

Il futuro: SP2 RU3 e oltre

Non ho mai abbandonato la speranza di risolvere questi problemi. Alcuni di noi si sono scoraggiati, ma il team di sviluppo di Accesso client RPC, il team responsabile dei servizi Exchange ed io abbiamo lavorato senza sosta per includere le due modifiche necessarie nel prodotto. La prima consiste nel correggere il profilo di Outlook quando una cassetta postale viene semplicemente spostata tra database di diversi siti AD, mentre la seconda riguarda il caso in cui, in seguito a un'operazione *over di database tra siti, Outlook usa un server Accesso client che non rappresenta la scelta ottimale per la posizione del database attualmente attivato.

Spostamenti di cassette postali

Per impostazione predefinita, dopo che avete installato SP2 RU3, se spostate le cassette postali tra siti AD, a tutte le versioni di Outlook verrà richiesto il riavvio e l'endpoint RPC del profilo di Outlook verrà aggiornato.

Se esaminate i registri di Accesso client RPC nell'array del server Accesso client RPC noterete quanto segue:

2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Notate che l'operazione RPC (ROP) è WrongServer (anche definita ecWrongServer). Ciò impone al client Outlook di eseguire l'individuazione dei profili e l'aggiornamento del profilo in base alle nuove informazioni presenti nella directory. Il profilo viene aggiornato e, quando il client viene riavviato, quest'ultimo stabilisce le connessioni con il nuovo endpoint RPC.

Quali altre condizioni determinano la visualizzazione della finestra di dialogo “L'amministratore di Microsoft Exchange ha apportato una modifica che richiede la chiusura e il riavvio di Outlook”?

1. Se specificate la proprietà DoNotPreserveMailboxSignature su New-MoveRequest.
2. Se i database delle cassette postali di origine e di destinazione dispongono di archivi gerarchici differenti delle cartelle pubbliche.
3. Se aggiornate la cassetta postale da una versione legacy di Exchange a Exchange 2010.

Eventi *over nei database tra siti

Il comportamento degli eventi *over nei database tra siti dipende dal valore della proprietà DAG AllowCrossSiteRPCClientAccess. Se impostate il valore della proprietà AllowCrossSiteRPCClientAccess su $true, il comportamento che ho descritto nella sezione precedente rappresenta il comportamento predefinito: se il database viene attivato nel datacenter di standby, gli utenti continuano a usare come endpoint di connettività dell'array del server Accesso client RPC nel sito AD in cui si trova il database delle cassette postali con il valore più basso di preferenza di attivazione.

Se impostate il valore della proprietà AllowCrossSiteRPCClientAccess su $false (il valore predefinito della proprietà è $false), l'endpoint RPC del profilo Outlook verrà aggiornato in modo da corrispondere all'array del server Accesso client RPC che si trova nello stesso sito AD in cui il database è attivo e montato. Notate che la proprietà RPCClientAccessServer non viene aggiornata, poiché indica il sito preferito.

Figura 4: il database MDB1 è stato attivato nel sito Active Directory in standby e il profilo Outlook è stato aggiornato automaticamente

Se esaminate i registri di Accesso client RPC nell'array del server Accesso client RPC noterete quanto segue:

2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Analogamente allo scenario dello spostamento della cassetta postale, l'operazione ROP WrongServer impone al client Outlook di eseguire l'individuazione dei profili e l'aggiornamento del profilo in base alle nuove informazioni presenti nella directory. Il profilo viene aggiornato e, quando il client viene riavviato, quest'ultimo stabilisce le connessioni con il nuovo endpoint RPC.

Conclusione

Installando il SP2 RU3 (o una versione successiva) potete garantire che il profilo delle cassette postali spostate tra siti AD venga aggiornato correttamente. Nello scenario dell'evento *-over nei database tra siti potete inoltre scegliere se consentire la connettività RPC tra siti o imporre al client Outlook l'uso dell'array del server Accesso client RPC che si trova nello stesso sito AD in cui è presente il database attivato e montato (il comportamento predefinito). Mi sembra appropriato concludere in questo modo:

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Questo è un post di blog localizzato. L'articolo originale è disponibile in RPC Client Access Cross-Site Connectivity Changes