Chiarimenti sull'oggetto array di server Accesso client - Parte 1

Articolo originale pubblicato sabato 24 marzo 2012

Sin dalla data del suo rilascio nel 2009, Exchange 2010 ha suscitato un enorme interesse. Nel corso delle attività di formazione e di preparazione dei clienti per il passaggio a Exchange 2010, abbiamo rilevato una serie di convinzioni errate comuni. Alcune di queste sono relative all'oggetto array di server Accesso client, in forma abbreviata oggetto array di CAS. Il technical writer e blogger frequente Scott Schnoll mi ha suggerito di trattare questo argomento mentre commentavo questo aspetto in un gruppo di distribuzione Microsoft interno ed eccomi quindi con questo post.

Non verranno esaminati tutti gli aspetti tecnici di un oggetto array di server Accesso client in questo post. Questi aspetti infatti sono stati splendidamente illustrati da Nagesh Magadev in un post precedente: Analisi del servizio Accesso client RPC di Exchange 2010.

Vengono elencate di seguito alcune affermazioni sull'oggetto array di server Accesso client di cui molti clienti non sono a conoscenza e per le quali tenterò di fornire una spiegazione. Nella Parte 1 verranno trattati i primi tre punti e nella Parte 2 verranno trattati gli ultimi tre.

1. Un oggetto array di server Accesso client non bilancia il carico del traffico
2. Un oggetto array di server Accesso client non fornisce il servizio di individuazione automatica, Outlook Web App, pannello di controllo di Exchange, Servizi Web Exchange, IMAP, POP o SMTP
3. L'FQDN dell'oggetto array di server Accesso client non deve far parte del certificato SSL
4. Un oggetto array di server Accesso client non deve essere risolvibile tramite DNS da parte di client esterni
5. Un oggetto array di server Accesso client non deve essere configurato o modificato dopo la creazione di database delle cassette postali di Exchange 2010 e lo spostamento delle cassette postali nei database
6. Un oggetto array di server Accesso client deve essere configurato anche se è presente un solo server Accesso client o un singolo server multiruolo

Siete confusi? Bene. Proviamo a chiarire nel miglior modo possibile ogni singolo aspetto. Poiché verranno riportati alcuni nomi di server in questo articolo, osserviamo innanzitutto quali elementi vengono utilizzati nel mio laboratorio.

OK, andiamo più a fondo.

1. Un oggetto array di server Accesso client non bilancia il carico del traffico

Un oggetto array di server Accesso client non esegue il bilanciamento del carico. È solo un oggetto Active Directory utilizzato per automatizzare alcune funzioni in Exchange. Nella documentazione di Exchange 2010 viene indicato che è consigliabile utilizzare soluzioni di bilanciamento del carico per bilanciare il carico del traffico di server Accesso client. Che cosa si intende quindi affermando che l'oggetto array di server Accesso client non esegue il bilanciamento del carico?

Una soluzione di bilanciamento del carico in pratica distribuisce equamente il traffico in un pool di server Accesso client, ovvero un array di server Accesso client. L'operazione però non viene eseguita dall'oggetto array di server Accesso client stesso. La differenza è sottile, ma netta. Forse siamo stati noi stessi a creare confusione non distinguendo a sufficienza i nomi.

Il motivo principale, e forse l'unico, per cui esiste un oggetto array di server Accesso client è quello di popolare automaticamente l'attributo RpcClientAccessServer di ogni nuovo database delle cassette postali di Exchange 2010 creato nello stesso sito Active Directory dell'oggetto array di server Accesso client.

L'attributo RpcClientAccessServer viene utilizzato per indicare ai client Outlook durante il processo di creazione dei profili il nome di server da utilizzare nel profilo. Questo è tutto. Dopo aver creato l'oggetto array di server Accesso client, si dispone semplicemente di un oggetto in Active Directory e non viene eseguito alcun tipo di bilanciamento del carico in questa fase.

A questo punto è compito dell'utente:

• Creare un record 'A' in DNS che consenta al computer client di risolvere il nome host in un indirizzo IP. Questo indirizzo IP sarà molto probabilmente l'IP virtuale della soluzione di bilanciamento del carico raggiungibile solo da client interni. Questo IP virtuale è l'indirizzo a cui si connetterà Outlook o qualsiasi altra applicazione che supporta MAPI/chiamate RPC per accedere a risorse cassetta postale di Exchange 2010.
• Configurare la soluzione di bilanciamento del carico per passare il traffico al pool di server Accesso client tramite l'IP virtuale.

I server Accesso client non sono informati che non viene eseguito alcun bilanciamento del carico.

È anche possibile che si generi confusione per quanto viene mostrato dopo la creazione di un oggetto array di server Accesso client tramite il cmdlet New-ClientAccessArray o dopo la visualizzazione di un oggetto array di server Accesso client preesistente tramite il cmdlet Get-ClientAccessArray.

Qui di seguito viene creato un nuovo oggetto array di server Accesso client nel laboratorio con nome CASArray-A, FQDN outlook.lab.local e sito Active Directory denominato Site-A.

Figura 1 - Creazione di un array di server Accesso client

Innanzitutto i campi FQDN e Name non corrispondono perché Name è un nome visualizzato. Può essere denominato come si preferisce per indicare l'utilizzo dell'oggetto array di server Accesso client. L'FQDN è il record che deve essere successivamente creato in DNS, altrimenti i client non saranno mai in grado di risolverlo in un indirizzo IP a cui connettersi. A questo punto è opportuno ricordare che può esistere un solo oggetto array di server Accesso client per sito Active Directory.

Allora perché la proprietà Members viene popolata con due server Accesso client subito dopo la creazione? Non era stato affermato che non viene eseguito alcun bilanciamento del carico a questo punto? Sembra quasi che io abbia mentito.

Per essere onesti, la proprietà Members è leggermente fuorviante. Se non aveste letto i passaggi per la creazione di un oggetto array di server Accesso client, potreste pensare di aver completato l'operazione. Avete creato l'oggetto array di server Accesso client a cui sono stati aggiunti automaticamente due server Accesso client. A questo punto potreste uscire a festeggiare oppure rubare alcuni biscotti a questo ragazzo. Non siamo ancora amici.

Poiché abbiamo associato l'oggetto array di server Accesso client al sito Active Directory Site-A, il cmdlet trova semplicemente tutti i server Accesso client registrati in Site-A e li elenca nella colonna Members. Questa colonna può essere considerata come la colonna dei membri potenziali oppure, come suggerisce il mio collega Kamal Abburi, un altro PFE presso Microsoft, come la colonna dei membri server Accesso client del sito. È possibile aggiungere questi server Accesso client come nodi nella soluzione di bilanciamento del carico poiché si trovano tutti nello stesso sito Active Directory. Finché tuttavia la soluzione di bilanciamento del carico non è configurata, non viene eseguito alcun bilanciamento del carico.

In che modo i cmdlet hanno individuato il sito in cui si trovano i server Accesso client? Per trovare la risposta dobbiamo esulare da AdsiEdit.msc e scavare nella partizione Configurazione di Active Directory.

Figura 2 - L'attributo msExchServerSite di un server Exchange 2010 contiene il sito Active Directory in cui si trova il server

Per ogni server Exchange è presente un attributo msExchServerSite contenente il sito Active Directory in cui si trova il server. Questo attributo viene aggiornato in modo dinamico se si sposta un server Exchange in un nuovo sito e il servizio Topologia di Active Directory di Microsoft Exchange può essere eseguito per aggiornare alcuni aspetti. L'attributo AutoDiscoverSiteScope (parte di Get/Set-ClientAccessServer) tuttavia non verrà aggiornato in modo dinamico ed è possibile che vengano ottenuti strani risultati di individuazione automatica finché non si risolve questo problema, a seconda del layout del sito, del server e del client.

2. Un oggetto array di server Accesso client non fornisce il servizio di individuazione automatica, Outlook Web App, pannello di controllo di Exchange, Servizi Web Exchange, IMAP, POP o SMTP

Torniamo per un momento alla funzione svolta da un oggetto array di server Accesso client. Popola l'attributo RpcClientAccessServer di un database delle cassette postali di Exchange 2010, che viene quindi utilizzato per indicare a Outlook dove deve connettersi per l'utilizzo di RPC (su TCP). Per i client Outlook via Internet (HTTPS), indica dove deve connettersi il traffico che esce dal proxy RPC su HTTP per conto del client in modo da raggiungere la cassetta postale.

A quali servizi tenta quindi di connettersi il client Outlook quando viene utilizzato RPC (su TCP)?

Innanzitutto Outlook si connette all'oggetto array di server Accesso client su TCP/135 per comunicare con Agente mapping endpoint RPC in modo da individuare le porte TCP su cui sono in attesa i due servizi seguenti:

1. Servizio di accesso client RPC di Microsoft Exchange (ovvero MSExchangeRPC)
2. Rubrica di Microsoft Exchange (ovvero MSExchangeAB)

Questo è tutto per la modalità RPC (su TCP).

I client Outlook via Internet (ovvero RPC su HTTP) si connettono al componente proxy RPC su HTTP su TCP/443 in un server Accesso client risolvendo il nome host esterno di Outlook via Internet oppure all'elemento indicato nel profilo di Outlook come server proxy.

Dal punto di vista tecnico, una nota importante è data dal fatto che Outlook aggiunge automaticamente /rpc/rpcproxy.dll al nome del server specificato. Questo è infatti il server a cui è necessario connettersi, ma se chiedessimo agli utenti di digitare effettivamente questi nomi, come accadeva ai tempi di Outlook 2003, verrebbero inevitabilmente effettuati errori di digitazione.

Figura 3 - Specifica dell'URL del proxy RPC in Outlook 2003

Il traffico viene instradato al di fuori del proxy RPC su HTTP verso l'endpoint MAPI/RPC appropriato utilizzando un elenco di porte TCP specificate a livello di codice (hard-coded) anziché assegnate in modo dinamico, ovvero le porte TCP 6001, TCP 6002 e TCP 6004. Il nome host esterno di Outlook via Internet non corrisponde intenzionalmente all'FQDN dell'oggetto array di server Accesso client. Il motivo verrà illustrato più avanti.

Un client può inoltre effettuare connessioni HTTPS a servizi quali l'individuazione automatica, download della Rubrica offline, Servizi Web Exchange, POP o IMAP, ma questi servizi sono definiti mediante metodi completamente diversi, ad esempio URL di directory virtuali oppure il valore AutoDiscoverServiceInternalUri. Nessuno di questi servizi aggiuntivi è fornito dall'oggetto array di server Accesso client poiché nessuno di essi utilizza RPC, anche se probabilmente si connettono allo stesso server. L'FQDN dell'oggetto array di server Accesso client può condividere lo stesso IP virtuale degli URL degli altri servizi, ma è consigliabile non consentire questa condivisione se viene utilizzato DNS diviso. Quest'ultimo aspetto verrà esaminato nei dettagli più avanti.

3. L'FQDN dell'oggetto array di server Accesso client non deve far parte dell'elenco di nomi di certificati SSL

Questa è una convinzione errata molto comune che deriva dal punto immediatamente precedente. I certificati SSL nell'ambito di questo articolo vengono utilizzati solo per eseguire operazioni come ad esempio stabilire una sessione HTTP protetta tramite SSL. Poiché RPC (su TCP) non è una sessione HTTP, non verrà applicata la protezione tramite SSL e pertanto non è necessario includere l'FQDN dell'oggetto array di server Accesso client nell'elenco di nomi soggetto del certificato SSL. Esaminiamo questo aspetto.

Di seguito viene illustrato Outlook 2010 in modalità MAPI/RPC connesso a un oggetto array di server Accesso client di Exchange 2010.

Figura 4 - Connessioni RPC (su TCP) di Outlook 2010 a server Accesso client di Exchange 2010

Come è possibile osservare, sono state create una directory e due connessioni di posta. Nell'output netstat (sovrapposto alla schermata) viene indicato che il computer ha effettuato una connessione di mapper di endpoint (TCP 135) all'oggetto array di server Accesso client, nonché connessioni a TCP 59531 e TCP 59532, che rappresentano le porte TCP assegnate in modo statico rispettivamente ai servizi MSExchangRPC e MSExchangeAB in questo laboratorio.

Sul lato server è possibile risalire ai servizi in attesa utilizzando il comando netstat –n –b.

Figura 5 - Servizi a cui deve connettersi Outlook quando viene utilizzato RPC (su TCP)

Come previsto, nessuno dei servizi viene contattato su HTTP (TCP 443). È per questo motivo che non è necessario l'FQDN dell'oggetto array di server Accesso client nel certificato SSL.

È facile essere indotti a credere che sia necessario l'FQDN dell'array di server Accesso client nel certificato SSL a causa del modo in cui Outlook visualizza le connessioni mentre è attiva la modalità HTTPS, come illustrato qui di seguito.

Figura 6 - Connessioni di Outlook via Internet

Dalla schermata è possibile osservare che Outlook 2010 ha effettuato due connessioni di posta e una connessione della cartella pubblica e che viene utilizzato HTTPS. Nell'ambito di Outlook si ha l'impressione di essere connessi a outlook.lab.local e E2K10-MLT-01.lab.local, mentre utilizzando di nuovo netstat è possibile osservare come in realtà si sia connessi al proxy RPC su HTTP in webmail.lab.local su TCP/443 (HTTPS). Outlook visualizzerà sempre il server a cui viene effettuata la connessione per i dati direttamente o tramite il proxy RPC su HTTP. Se vi chiedete perché siano visibili sei connessioni tramite netstat anziché tre, la risposta dipende dal fatto che HTTP è un protocollo half-duplex e pertanto vengono stabiliti un canale RPC_DATA_IN e un canale RPC_DATA_OUT per ogni connessione visibile all'interno di Outlook.

Potreste pensare che poiché Outlook 2007 e 2010 crittografano le sessioni RPC per impostazione predefinita, è necessario disporre del nome nel certificato. Non è così, perché l'impostazione di crittografia riportata qui di seguito utilizza la crittografia RPC e non deve essere confusa con SSL. Le comunicazioni vengono comunque eseguite su RPC e non su HTTPS.

Figura 7 - Durante la connessione con RPC (su TCP), Outlook utilizza la crittografia RPC

È semplice. Se un oggetto array di server Accesso client dovesse soddisfare i requisiti di un'Autorità di certificazione (CA) e la CA dovesse dichiarare di essere necessaria, l'oggetto potrebbe rispondere semplicemente di non averne bisogno. Tutto ciò naturalmente se sono stati seguiti i consigli per l'utilizzo di un FQDN diverso per l'oggetto array di server Accesso client rispetto agli FQDN degli altri servizi.

Mi auguro che la Parte 1 di questo articolo si sia rivelata utile per chiarire alcuni degli aspetti generalmente fraintesi degli oggetti array di server Accesso client. Mi auguro inoltre che leggerete successivamente anche la Parte 2, dove verranno illustrate le altre tre convinzioni errate comuni relative agli oggetti array di server Accesso client.

Brian Day
Premier Field Engineer, Messaging

Questo è un post di blog localizzato. L'articolo originale è disponibile in Demystifying the CAS Array Object - Part 1.