Coda di Exchange & R: migrazioni e aggiornamenti
In caso di migrazione da un gruppo a un altro gli aggiornamenti non sono sempre automatici... e a volte possono essere indesiderati.
Henrik Walther
Exchange 2010 e Hyper-V
D. Stiamo progettando di distribuire Exchange Server 2010. Politica aziendale afferma che tutti i nuovi server deve essere macchine virtuali (VM) in esecuzione con Hyper-V. Al fine di aumentare l'applicazione e la disponibilità del servizio, tutti i server di Hyper-V radice partecipano in un cluster di Failover di Hyper-V.
Abbiamo visto recentemente questo blog post sul blog del Team di Microsoft Exchange annuncia il supporto di virtualizzazione hardware avanzata per Exchange 2010. Abbiamo soprattutto trovato la seguente dichiarazione interessanti:
"La combinazione di soluzioni di alta disponibilità di Exchange 2010 (gruppi di disponibilità database [DAGs]) con basata sull'hypervisor clustering, elevata disponibilità, o soluzioni di migrazione che si sposta o automaticamente failover server di cassette postali che sono membri del DAG tra server in cluster radice, è ora supportato."
Questo è una buona notizia per noi, in quanto significa che noi ora possiamo distribuire i server cassette postali di Exchange 2010 partecipando in un DAG come macchine virtuali in un Cluster di Failover di Hyper-V. C'è niente altro che dovremmo essere consapevoli di nel fare questo?
**R.**Certamente cronometrato la distribuzione di Exchange 2010 bene. Tu sei assolutamente corretto che Microsoft supporta ora combinando DAGs con tecnologia migrazione e clustering di failover basata su host. Questo vale non solo per Hyper-V, ma qualsiasi fornitore di virtualizzazione hardware partecipano il Windows Server Virtualization Validation Program (SVVP).
Tuttavia, ci sono un paio di punti importanti da tenere a mente se hai intenzione di membri di migrazione dal vivo del DAG. Avete bisogno di Exchange 2010 SP1 o versioni successive per questo di essere sostenuta. E ha anche altamente raccomandato di utilizzare volumi cluster condiviso e dischi non pass-through. Se il gruppo di prodotti Exchange e la squadra di Hyper-V prova ogni metodo, hanno notato l'offline tempo connesso con le risorse storage in movimento è stato tagliato a metà utilizzando volumi cluster condiviso.
Se il tempo non in linea del server supera i cinque secondi, il nodo DAG verrà sfrattato dal cluster. Quindi è importanta assicurarsi che il Cluster di Failover di Hyper-V possono migrare le risorse in meno di cinque secondi. Se può, regolare il timeout di heartbeat cluster su un valore superiore. Non dovrebbe indicare superiore a 10 secondi, però.
Dovrebbe anche assicurarsi che voi avete applicato le patch più recenti di Hyper-V legate ai server host Hyper-V. Per quanto riguarda la rete di migrazione in tempo reale, assicurarsi che sono attivati frame jumbo e gli interruttori coinvolti supportano frame jumbo. Si raccomanda inoltre di modificare buffer di ricezione su ciascun host Hyper-V a 8192. Inoltre, è necessario distribuire più larghezza di banda possibile per la rete di migrazione in tempo reale (5 GB o maggiore è preferibile).
È importante configurare ogni VM tale che essi salvare e ripristinare lo stato su disco quando spostata o non in linea. Qualsiasi failover deve causare un avvio a freddo, quando il nodo di destinazione è in esecuzione una VM. Un processo di migrazione pianificata deve includere anche un avvio, arresto e freddo. L'azione in linea controllata cluster è impostato su "Save State" per impostazione predefinita. Invece, esso deve essere impostato su "Shut down" (vedere Figura 1) affinché il server freddo stivali quando vivere-migrati da un nodo di Hyper-V a un altro.
.jpg)
Figura 1 Cluster controllato in linea azione impostata su "Shut down.”
La recente pubblicazione "Procedure consigliate per la virtualizzazione di Exchange Server 2010 con Windows Server 2008 R2 Hyper-V" libro bianco include un sacco di buone informazioni su Exchange 2010 virtualizzazione usando Hyper-V. E, ultimo ma non meno importante, il documentazione di Exchange 2010 su TechNet è stato aggiornato per riflettere questo nuovo atteggiamento di supporto.
Registrazione di nomi di dominio completi
D. Ci avete distribuito Exchange 2010 e hanno un totale di 12 ruoli del Server Accesso Client (CAS). Utilizziamo un modello di datacenter di distribuzione di utente attivo/passivo. Questo significa che abbiamo un centro dati primario e un datacenter di failover. Ci sono sei ruoli CAS in ogni datacenter. Utilizziamo una soluzione di bilanciamento del carico basato su hardware per caricare l'equilibrio traffico di accesso client in ogni datacenter. Abbiamo circa 50.000 utenti, con il collegamento di più alla propria cassetta postale utilizzando il client Outlook 2007/2010 interni.
Abbiamo visto recentemente questo post del blog sul Blog del Team di Exchange, che raccomanda a tutti i clienti abilitare l'autenticazione Kerberos per client Outlook interni e spiega perché. A causa della presente raccomandazione, stiamo progettando di abilitare l'autenticazione Kerberos per il client Outlook interni nella nostra organizzazione.
Anche se abbiamo letto il post di blog in dettaglio e verificato la pertinente documentazione Exchange 2010 su TechNet, siamo ancora in dubbio quando si tratta di cui pienamente qualificati i nomi di dominio (FQDN) abbiamo bisogno di registrarsi come nomi di entità servizio (SPN). Che cosa circa l'auto-Scopri FQDN? Sarebbe, abbiamo bisogno di registrarsi questo FQDN pure?
**R.**Riesco a capire perché sei un po' confuso circa l'auto-Scopri FQDN. La maggior parte dei clienti hanno un'individuazione automatica FQDN solitamente denominato individuazione automatica.. com (companyname). Questo nome di dominio completo è per i clienti esterni (principalmente Outlook via Internet ed Exchange ActiveSync dispositivi) per la creazione automatica di profilo.
Diverse funzionalità di Outlook 2007/2010 si basano sul servizio di individuazione automatica (fuori sede [FS], Offline Address Book [OAB] e messaggistica unificata [UM]). Client Outlook 2007/2010 interni non usare questo nome di dominio completo servizio di individuazione automatica, però. Sembrano fino al punto di connessione del servizio in Active Directory utilizzando il servizio di individuazione automatica interno identificatore URI (Uniform Resource), che, per impostazione predefinita, evidenzia il FQDN CAS (vedere Figura 2).
Quando si utilizza una soluzione di bilanciamento del carico per distribuire il traffico client tra CASs in una matrice CAS, è solito impostare il servizio di individuazione automatica interno URI per indicare l'indirizzo IP virtuale (VIP) connesso con il rispettivo servizio virtuale bilanciamento del carico. Alcuni clienti di utilizzare un nome di dominio completo dedicato per questo. Altri basta usare la stessa FQDN utilizzato per Outlook Web App (OWA), pannello di controllo di Exchange (ECP), rubrica fuori rete e servizi Web di Exchange (EWS).
.jpg)
Figura 2: il nome di dominio completo per il servizio di individuazione automatica interno URI.
Aggiornamenti dell'endpoint
D. Abbiamo una soluzione di resilienza del sito Exchange 2010 con un primario e il failover datacenter. Abbiamo recentemente fatto il passaggio di un datacenter pianificata per verificare i passi nel nostro datacenter piano di disaster recovery. Durante il passaggio, abbiamo notato qualcosa. Anche se il client Outlook interni potrebbe connettersi bene dopo aver cambiato il record DNS per la matrice CAS nel centro dati primario in modo esso ha sottolineato la matrice CAS nel datacenter failover, l'endpoint di connessione è stato mai aggiornato sui client.
Quando la matrice CAS non è disponibile nel centro dati primario e il record DNS per questa matrice CAS viene aggiornato per puntare alla matrice CAS nel datacenter failover, non è che ci aspetta il comportamento che l'endpoint di connessione viene aggiornato nel client Outlook pure?
**R.**Quello che vedete è in realtà il comportamento previsto. L'endpoint di connessione non / non deve essere aggiornato quando si cambia il record DNS per la matrice CAS nel centro dati primario per indicare l'indirizzo IP associato a matrice CAS nel datacenter failover. Come avete visto voi stessi, i client Outlook si connetteranno bene, purché il nome della matrice CAS risolve raggiungibile indirizzo IP.
Questo comportamento rende le cose meno doloroso quando fare il passaggio al datacenter. Devi solo prendere cura di replica DNS — non è necessario preoccuparsi se un client Outlook ha avuto il suo profilo aggiornato.
Aggiornamenti del profilo
D. Abbiamo più siti di Active Directory, tutti con il server Exchange 2010 SP1. Ogni sito ha tre ruoli CAS. Al fine di distribuire il traffico client tra i tre ruoli CAS in ciascun sito, abbiamo creato CAS matrici e DAGs per fornire resilienza delle cassette postali.
A volte, un utente permanentemente sposta da un luogo fisico ad un altro. In questo caso, ci muoviamo la cassetta postale dell'utente per un database delle cassette postali nel nuovo sito. Perché ci muoviamo la cassetta postale dell'utente da un database delle cassette postali con un valore di Server di accesso Client RPC diverso dal valore del database di destinazione, ci saremmo aspettati di profilo di Outlook dell'utente verrebbe aggiornato per riflettere il valore CAS RPC del database delle cassette postali di destinazione (vedere Figura 3).
.jpg)
Figura 3: Server Accesso Client RPC di valore per un database delle cassette postali.
Non abbiamo alcun client Outlook 2003, unico 2007 e 2010. Finora, abbiamo solo riusciti ad avere il profilo di Outlook aggiornato eseguendo una riparazione di profilo.
**R.**Capisco come ci si aspetterebbe il profilo di Outlook per aggiornare automaticamente durante una mossa di cassette postali tra siti da un database delle cassette postali con un valore di RPC CAS per un database delle cassette postali di destinazione con un altro valore di RPC CAS. In realtà, però, che cosa stai riscontrando è il comportamento previsto.
La ragione di questo comportamento ha a che fare con il fatto che la fonte CAS (matrice) determina la cui cassetta postale dovrebbe accedere in base alle proprietà di Active Directory. Se Active Directory è aggiornato, esso sarà mai parlare con database delle cassette postali sbagliato e mai ricevere la risposta di anecWrongServer, che è necessaria al fine di innescare un aggiornamento di profilo di Outlook. Il gruppo di prodotti Exchange è pienamente consapevole di questo comportamento lontano-da-ideale. Non non c'è nessuna parola ancora su quando — o anche se — questo verrà risolto.
Fiducia, ma verificare
D. Stiamo cercando di impostare la federazione tra il nostro gruppo Exchange 2010 e l'altro. Mi sembra di ricordare che è necessario utilizzare un certificato da un'autorità di certificazione di terze parti (CA) per impostare federative tra organizzazioni di Exchange 2010. Ho voluto verificare se questo è vero.
**R.**Probabilmente leggere questo prima di Exchange 2010 SP1 era stato rilasciato. Con Exchange 2010 RTM, richiedono un certificato da una CA di terze parti per ottenere una relazione di trust federativa lavorando tra due organizzazioni di Exchange 2010.
Tuttavia, questo cambiò con il rilascio della SP1 di Exchange 2010. Con Exchange 2010 SP1, è possibile utilizzare un certificato autofirmato o un certificato rilasciato da una PKI interna. In realtà, la procedura guidata "Nuova Federazione fiducia" automaticamente crea e installa un certificato autofirmato specificamente per scopi di fiducia di Federazione (vedere Figura 4).
.jpg)
Figura 4 il nuovo certificato autofirmato creato dal wizard "nuova Federazione Trust".
.jpg)
Henrik Waltherè un Microsoft Certified Master: Exchange 2007 ed Exchange MVP con più di 15 anni di esperienza nel settore IT. Lavora come technology architect per Timengo Consulting (un Microsoft Gold Certified Partner in Danimarca) e come un technical writer per Biblioso Corp. (una società statunitense specializzata in gestione servizi di localizzazione e documentazione).