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

Articolo originale pubblicato giovedì 29 marzo 2012

Bentornati. In Chiarimenti sull'oggetto array di server Accesso client - Parte 1 sono stati illustrati questi tre punti per iniziare a fornire chiarimenti sull'oggetto array di server Accesso client in Exchange Server 2010.

1. Un oggetto array di server Accesso client non bilancia il carico del traffico
2. Un oggetto array di server Accesso client non fornisce servizi di individuazione automatica, Outlook Web App, pannello di controllo di Exchange, Servizi Web Exchange, IMAP, POP o SMTP
3. Un oggetto array di server Accesso client non deve far parte del certificato SSL

Nella Parte 2 verranno invece illustrati i tre punti seguenti in modo da liberarsi una volta per tutte delle convinzioni errate sull'oggetto array di server Accesso client e correggere le distribuzioni esistenti e/o effettuare pianificazioni strategicamente più efficaci per distribuzioni future.

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 Server 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

4. Un oggetto array di server Accesso client non deve essere risolvibile tramite DNS da parte di client esterni

Come già affermato almeno due volte nella Parte 1, l'FQDN dell'oggetto array di server Accesso client non deve corrispondere a quello utilizzato per altri servizi, ad esempio Outlook Web App, il pannello di controllo di Exchange, Servizi Web Exchange, individuazione automatica o il nome host esterno di Outlook via Internet.

Il motivo principale dipende dal fatto che i client Outlook via Internet tenteranno innanzitutto di risolvere l'FQDN dell'oggetto array di server Accesso client tramite DNS, in modo da verificare se è possibile tentare una connessione RPC (su TCP) oppure passare direttamente a HTTPS. Nei vostri sistemi sono consentite connessioni RPC (su TCP) direttamente da Internet alla rete Intranet? Mi auguro di no, altrimenti otterrete un contrassegno rosso nel report di Exchange Risk and Health Assessment Program. Se il client tenta innanzitutto di connettersi tramite RPC (su TCP) perché è in grado di risolvere l'FQDN dell'oggetto array di server Accesso client, può verificarsi un ritardo significativo prima che tenti una connessione HTTPS all'URL del proxy Outlook via Internet. Questo ritardo può comportare un aumento del volume di chiamate all'helpdesk se gli utenti finali lo percepiscono come un problema di prestazioni e/o di interruzione del servizio.

Per evitare questo problema, è sufficiente fare in modo che l'FQDN dell'oggetto array di server Accesso client sia univoco nel DNS interno, ad esempio outlook.corp.contoso.com, e che altri URL non appartenenti al servizio RPC (su TCP) utilizzino ad esempio mail.contoso.com internamente ed esternamente tramite DNS diviso.

Se non avete avuto l'opportunità di utilizzare DNS diviso, si tratta in pratica di uno scenario in cui è presente un insieme di server DNS interni ED esterni che gestiscono le richieste per la stessa zona di ricerca diretta, ad esempio contoso.com. Le due infrastrutture DNS sono completamente isolate l'una dall'altra. Non si verifica alcun trasferimento di zona né vengono utilizzate reciprocamente come server di inoltro DNS. Questa configurazione consente agli utenti interni di utilizzare l'infrastruttura DNS interna per risolvere mail.contoso.com dell'host in un indirizzo IP interno (ad esempio 192.168.1.10) che accede all'IP virtuale della soluzione di bilanciamento del carico, mentre gli utenti esterni lo risolvono nell'indirizzo IP pubblico, che può puntare all'infrastruttura Forefront TMG/UAG esposta a Internet nella rete perimetrale. È comune che l'indirizzo IP dell'oggetto array di server Accesso client e l'indirizzo IP interno degli URL di servizi non RPC (su TCP) (Outlook Web App, pannello di controllo di Exchange, Servizi Web Exchange e così via) corrispondano allo stesso indirizzo IP virtuale della soluzione di bilanciamento del carico, ma possono utilizzare controlli di attività per l'individuazione dello stato del servizio appropriato.

DNS fornisce una risposta con caratteri jolly?

Ho avuto almeno un cliente con un server DNS esterno che utilizzava un record con caratteri jolly in risposta a una query ricevuta per un nome host non esistente. Era possibile pertanto inviare una richiesta DNS per NomeInesistente.contoso.com e il server DNS restituiva sempre l'indirizzo IP del sito Web aziendale. I record con caratteri jolly sono del tutto validi dal punto di vista degli standard Internet. Informazioni dettagliate sono disponibili nella sezione 4.3.3 in RFC 1034.

Per questo motivo, i client Outlook via Internet potevano sempre risolvere l'FQDN del'oggetto array di server Accesso client e tentare innanzitutto una connessione RPC (su TCP) prima di passare a HTTPS. Se vi trovate in una situazione simile con un server DNS esterno che utilizza risposte con caratteri jolly per una zona di ricerca diretta specifica, suggerisco di provare a non utilizzare tale zona di ricerca diretta per l'URL del proxy Outlook via Internet.

È opportuno a questo punto ricordare di configurare il monitoraggio dello stato di servizio per la soluzione di bilanciamento del carico. Per ottenere risultati ottimali di monitoraggio del servizio, consultare il fornitore della soluzione di bilanciamento del carico. In Distribuzione di soluzioni di bilanciamento del carico per Exchange Server 2010 è disponibile un elenco dei fornitori di soluzioni di bilanciamento del carico che hanno testato le soluzioni con Exchange 2010 con i collegamenti alle relative pagine Web (per Exchange 2010). Questo comunque *non* è un elenco definitivo dei fornitori di soluzioni di bilanciamento del carico supportati. Si tratta semplicemente di un elenco di fornitori che hanno scelto di impegnarsi con Microsoft direttamente per i test e il supporto delle soluzioni.

Considerate come rapido esempio uno scenario in cui per gli FQDN basati sul servizio HTTPS vengono eseguiti test di attività su risposte TCP/443 e la soluzione di bilanciamento del carico smette di inviare nuovo traffico client ai server Accesso client che smettono di rispondere su TCP/443. Per l'FQDN del servizio RPC (su TCP) dell'oggetto array di server Accesso client, i test di attività possono essere eseguiti su Agente mapping endpoint RPC su TCP/135, nonché sulle due porte TCP statiche scelte per il servizio Accesso client RPC e per il Servizio Rubrica. Se una di queste tre porte smette di rispondere a un server Accesso client specifico, la soluzione di bilanciamento del carico non invierà nuovo traffico client a tale server per RPC (su TCP) finché non risponderanno di nuovo tutte le porte. Se non si configurano porte TCP statiche, Exchange sceglierà una porta TCP dinamica per ogni servizio all'avvio rendendo più difficile, se non impossibile, l'esecuzione di test di attività per alcune soluzioni di bilanciamento del carico.

5. Un oggetto array di server Accesso client non deve essere configurato dopo la creazione di database di Exchange 2010

In molti casi ci affrettiamo a installare i server cassette postali, creare i database delle cassette postali e iniziare a eseguire i test di convalida delle soluzioni di archiviazione con Jetstress. Posso suggerire di rallentare in modo da non dover affrontare problemi in un secondo momento? Benché il ruolo server cassette postali sia considerato da molti il più importante, non è una buona soluzione se la porta principale è sprangata perché non è possibile accedere ai server cassette postali attraverso i server Accesso client.

Se si inizia a creare database delle cassette postali prima che sia disponibile un oggetto array di server Accesso client, sarà visibile un server Accesso client casuale nello stesso sito Active Directory indicato nell'attributo RpcClientAccessServer di ogni database.

Invece di ottenere il risultato previsto (utilizzo dell'FQDN dell'oggetto array di server Accesso client)

Figura 1 - Se viene creato un oggetto array di server Accesso client, la proprietà RpcClientAccessServer del database delle cassette postali verrà popolata con l'FQDN dell'oggetto array di server Accesso client

Si otterrà il risultato seguente:

Figura 2 - Se non viene creato l'oggetto array di server Accesso client, la proprietà RpcClientAccessServer del database delle cassette postali verrà popolata con l'FQDN del server Accesso client

I profili client saranno simili ai seguenti…

Figura 3 - Se non viene creato un oggetto array di server Accesso client, i client Outlook verranno configurati con l'FQDN del server Accesso client

I client si connetteranno come indicato di seguito…

Figura 4 - I client si connettono all'FQDN del server Accesso client

A prima vista questo scenario può sembrare innocuo e tutto sembra funzionare correttamente, ma in realtà si stanno creando le premesse per problemi futuri. Se si inizia a spostare le cassette postali in Exchange Server 2010 con questa configurazione, Outlook utilizzerà il nome del server Accesso client nel campo "Server" del profilo utente. Questa soluzione funzionerà, a meno che il server Accesso client non sia più disponibile o ne vengano rimosse le autorizzazioni in un secondo momento e venga sostituito da un server con un nome diverso. Non sarebbe meglio utilizzare un pool di server Accesso client con bilanciamento del carico quando si verifica questa situazione?

Potreste pensare di risolvere il problema creando un oggetto array di server Accesso client e correggere la proprietà RpcClientAccessServer nei database quando si verifica questa situazione. In realtà, questa soluzione può funzionare solo per le cassette postali spostate in Exchange 2010 dopo l'evento. Tutti gli utenti con un profilo di Outlook preesistente configurato per puntare a un nome di server Accesso client e non all'oggetto array di server Accesso client continueranno a connettersi al nome del server Accesso client e non si aggiorneranno per utilizzare l'FQDN dell'oggetto array di server Accesso client.

Il profilo non si aggiornerà perché il client non riceverà una risposta ecWrongServer dal server Accesso client e questo perché i server Accesso client rappresentano un punto di connessione valido per i database delle cassette postali tramite RPC (su TCP). I client pertanto supereranno indenni eventi di passaggio/failover di data center senza essere riconfigurati e gli amministratori dovranno solo modificare il record DNS dell'oggetto array di server Accesso client in modo da puntare a un pool di server Accesso client ancora attivo. Attualmente, l'unico modo per correggere i profili delle cassette postali potrebbe consistere nel correggere manualmente i profili in Outlook pubblicando un file PRF di Office tramite oggetto Criteri di gruppo (non funzionerà per computer non aggiunti al dominio) oppure rimuovendo le autorizzazioni per il server Accesso client denominato nei profili degli utenti, in modo che l'endpoint non sia più disponibile. Questa ultima opzione dovrebbe generare una correzione completa dei profili (eseguire sempre i test) da parte del servizio di individuazione automatica in Outlook 2007 oppure Outlook 2010. In Outlook 2003 la correzione può essere effettuata solo correggendo i profili o utilizzando un file PRF. Il servizio di individuazione automatica alla data attuale non aggiorna un profilo a un nuovo nome di server nell'ambito del normale processo di individuazione automatica, che comporta l'aggiornamento della configurazione di Outlook via Internet e l'individuazione degli URL di Servizi Web Exchange per altre funzionalità quali la gestione dello stato Fuori sede, delle informazioni sulla disponibilità e di Regole posta in arrivo.

Questo significa inoltre che se una cassetta postale di un database contenuto in un sito Active Directory Site-A in cui viene utilizzato un oggetto array di server Accesso client denominato Boston-CASArray viene spostata in un database di un sito Active Directory Site-B in cui viene utilizzato un oggetto array di server Accesso client denominato Redmond-CASArray, il profilo non si aggiornerà e il campo relativo al nome del server manterrà l'FQDN Boston-CASArray. È opportuno tenere conto di questo fattore se si dispone di una popolazione di utenti di cui viene eseguita la migrazione a siti diversi per cambiamenti di lavoro o per cui vengono eseguiti spostamenti di massa di cassette postali interne in un altro sito in un determinato momento del ciclo di vita della soluzione. Se si creano database di Exchange 2010 prima della creazione di un oggetto array di server Accesso client, è di fondamentale importanza correggere l'attributo RpcClientAccessServer dei database in modo da utilizzare l'oggetto array di server Accesso client prima di spostare le 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

Riflettete un istante su quanto illustrato nel punto precedente. Un client non si aggiornerà per l'utilizzo di un oggetto array di server Accesso client se questo viene aggiunto successivamente. Come procedere se si dispone di un solo server Accesso client? Potreste pensare che non sia importante. Può sembrare così in un primo momento, ma perché non premunirsi in anticipo per evitare problemi in futuro? E se tra un anno fosse necessario sostituire il server Accesso client? Se tutti i profili dei client puntano a un nome di server Accesso client, non esiste un modo semplice per la transizione senza prevedere interruzioni del servizio o interventi manuali. Sarà necessario correggere i profili procedendo in uno dei modi già illustrati dopo aver aggiunto un nuovo server Accesso client oppure rimuovere le autorizzazioni per il server Accesso client esistente e introdurre un nuovo server Accesso client con lo stesso nome host, operazioni che comporteranno tempi di inattività. Secondo me nessuna di queste opzioni è accettabile.

Che cosa accadrebbe se in un secondo momento dovessero cambiare i requisiti aziendali e fosse necessario garantire un'elevata disponibilità di accesso client? Potreste sempre raggiungere questo scopo aggiungendo un secondo server Accesso client e una soluzione di bilanciamento del carico. Vi trovereste però di nuovo invischiati nello stesso problema, dovendo correggere ogni singolo profilo tramite uno dei metodi già illustrati. Di nuovo, queste non sono soluzioni accettabili per me.

Il mio suggerimento è di creare un oggetto array di server Accesso client fin dall'inizio. Come è possibile procedere se non si dispone di una soluzione di bilanciamento del carico e di altri server Accesso client? È semplice. È sufficiente configurare l'oggetto array di server Accesso client normalmente, assegnargli un nome, un sito Active Directory, un FQDN e quindi fare in modo che il record 'A' DNS punti all'IP come unico server Accesso client o server multiruolo attualmente disponibile. In questo modo vi siete tutelati da possibili problemi futuri e se dovesse essere necessario sostituire il singolo server Accesso client o il server multiruolo, sarà sufficiente creare il nuovo server e quindi modificare l'indirizzo IP del record DNS in modo che tutto continui a funzionare senza interruzioni. Se desiderate aggiungere successivamente la disponibilità elevata, basterà rendere operativa la soluzione di bilanciamento del carico e quindi modificare l'indirizzo IP del record DNS dell'oggetto array di server Accesso client in modo da puntare all'IP virtuale della soluzione di bilanciamento del carico.

Mi auguro che questo articolo si sia rivelato utile per chiarire alcune convinzioni errate sull'oggetto array di server Accesso client e consenta di eseguire la migrazione a Exchange Server 2010 senza problemi.

Brian Day
Premier Field Engineer, Messaging

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