Exchange Queue & R: Gestione di ambienti ibridi

Configurazione di distribuzioni di Exchange ibrido con funzionalità di Office 365 può essere confusionaria al meglio, ma è valsa la pena.

Henrik Walther

Coesistenza di ibrido

D. Noi attualmente stiamo configurando una distribuzione ibrida basata su Exchange 2010. Ci stiamo preparando eseguire la migrazione di cassette postali dalla nostra organizzazione di Exchange 2007 locale a Exchange Online in Office 365. Stiamo usando server basati su Exchange 2010 per la coesistenza, perché noi non abbiamo ancora aggiornato il nostro inquilino di Office 365.

Siamo una grande azienda con gli utenti di Exchange utilizzando più di 30 differenti domini SMTP. Abbiamo gli utenti con molti domini di indirizzo di posta elettronica primario diverso. Alcuni usano alias@contoso.com, altri usano alias@fabrikam.com e così via. Vogliamo convivenza quando si lavora con Exchange Online e l'organizzazione di Exchange 2007 locale per tutti gli utenti.

Questo richiederebbe di creare un record DNS di individuazione automatica per tutti i domini SMTP, così come aggiungere il nome di dominio completo (FQDN) del servizio di individuazione automatica per il certificato di storage area network (SAN) ci stiamo progettando di utilizzare sui server Exchange 2010 ibrido?

**R.**Con i vecchi server ibrido —, ibrido server che esegue Exchange 2010, è necessario creare un record di individuazione automatica nel DNS per tutti i domini SMTP. Inoltre, il certificato di SAN ha includere tutti i record DNS di individuazione automatica usata nell'elenco SAN. Ad esempio, se usato tre domini SMTP (contoso.com, fabrikam.com e wingtiptoys.com) nell'organizzazione di Exchange e si desidera configurare la coesistenza per tutti e tre con Exchange Online in Office 365, è necessario creare i seguenti record di individuazione automatica in DNS:

• Autodiscover.contoso.com.
• Autodiscover.fabrikam.com
• Autodiscover.wingtiptoys.com

Inoltre sarebbe necessario includere questi record nel certificato SAN. È possibile utilizzare i record CNAME per il reindirizzamento di individuazione automatica, ma che non cambia il fatto che è necessario aggiungere tutti i record di individuazione automatica per il certificato di SAN. Inoltre, distribuzioni di ibrido di Exchange non supportano il reindirizzamento di individuazione automatica basata su SRV.

Con la funzione di dominio di individuazione automatica, avete l'opzione di impostazione di uno dei tuoi domini SMTP come il dominio di individuazione automatica. Quando così facendo, si rimuove i seguenti requisiti:

• La necessità di creare un record di individuazione automatica per tutti i domini SMTP in DNS, ad eccezione del dominio che è impostato come il dominio di individuazione automatica
• La necessità di includere il FQDN Autodiscover per tutti i domini SMTP utilizzati nel certificato di SAN

Questa è davvero una grande novità del Exchange Server 2013. Il gruppo di prodotti Exchange introduce sempre nuove funzionalità nella versione più recente, ma ora e poi scelgono anche di retro-porta una caratteristica di una versione precedente di Exchange. Quando si tratta di funzionalità di dominio di individuazione automatica, questo è accaduto con il rilascio di Exchange 2010 SP3 RU1 (si può scaricare qui). Sì, quando si applicano RU1, è possibile utilizzare la funzionalità di dominio di individuazione automatica in una configurazione ibrida basata su Exchange 2010. Per impostare il dominio di individuazione automatica, utilizzare il seguente comando:

Set-HybridConfiguration –Domains "contoso.com, fabrikam.com", "autod:wingtiptoys.com"

Si può quindi vedere il dominio di individuazione automatica è stato impostato eseguendo il cmdlet Get-HybridConfiguration (vedi Figura 1).

Figura 1 eseguire il cmdlet Get-HybridConfiguration per confermare il dominio di individuazione automatica è impostato.

Messaggi mancanti

D. Noi abbiamo appena configurato una distribuzione basata su Exchange 2010 ibrida per alzarsi la coesistenza di Exchange e corsa tra Exchange 2003 ed Exchange Online in Office 365. Perché abbiamo bisogno di flusso di posta dentro e fuori di Exchange Online per passare attraverso il nostro server di ibrido on-premise Exchange 2010, abbiamo scelto la seguente opzione della procedura guidata di configurazione ibrida al fine di configurare il trasporto centralizzato: "Indirizzare tutti i messaggi associati a Internet attraverso il server di Exchange on-premise. Questo è solitamente fatto per ragioni di conformità."

Noi abbiamo configurato la coesistenza di libro. Vediamo la procedura guidata di configurazione ibrida creata la ricezione necessaria e invia il connettore on-premise e i connettori in ingresso e in uscita, in Forefront Online Protection per Exchange (FOPE). Il nome del dominio che viene utilizzato per forzare TLS da FOPE ai server on-premise ibrido è il certificato di terze parti sul server ibrido. È correttamente impostato su "ricevere per il connettore che accetta le sessioni SMTP dalle gamme FOPE IP."

Nonostante tutto questo, e-mail inviate da Exchange Online in Office 365 per i destinatari nelle organizzazioni di Exchange on-premise (così come i destinatari esterni) non sono mai consegnati. Quando si utilizza il messaggio di rilevamento nell'admin di FOPE, vediamo il seguente errore:

"Indirizzo IP di destinazione primaria 451 4.4.0 ha risposto con: 'Mancata convalida 454 4.7.5 certificato.' Failover tentato a host alternativo, ma che non è riuscito."

Davvero siamo bloccati qui. Ci stiamo chiedendo se avete idee su come risolvere questo ulteriore?

**R.**In realtà, ho visto questo messaggio di errore in uno scenario di distribuzione ibrida di Exchange 2010. Quando la configurazione di una configurazione ibrida utilizzando la procedura guidata configurazione ibrida, una delle cose che crea è ricevere un nuovo connettore denominato "Inbound da Office 365" su ogni server di trasporto di ibridi (vedi Figura 2).

Figura 2 The Hybrid configurazione guidata crea la nuova in arrivo dal connettore di ricezione di Office 365.

Questo connettore è impostato per accettare solo sessioni SMTP in arrivo da uno specifico set di intervalli di IP, che sono associati con il servizio FOPE utilizzato in Office 365 (vedere Figura 3).

Figura 3 solo l'entrata da Office 365 connettore di ricezione riceve i messaggi da un insieme specifico di indirizzi IP.

Questo ricevere connettore verrà inoltre impostato il nome FQDN che corrisponde al FQDN il certificato utilizzato per la coesistenza (vedere Figura 4).

Figura 4 The Inbound da impostazioni di Office 365 connettore di ricezione corrispondere il nome di dominio completo sul certificato ibrido.

Questo è anche impostato presso il certificato per abbinare il nome FQDN del connettore in uscita di FOPE, quindi è possibile utilizzare costretto TLS. Tutto questo è stato istituito il libro, come si spiega che ha fatto, ma ancora genera lo stesso messaggio di errore hai ricevuto per i messaggi in uscita da Exchange Online.

Mentre guardando il Registro di protocollo per il connettore di ricezione sul server ibrido, ho visto qualcosa di strano. Sessioni SMTP in arrivo da FOPE stavano per default connettore di ricezione. Perché l'IP corretto varia e altre impostazioni erano corrette su Office 365 connettore di ricezione, questo non ha senso. Poi, ho notato che anche se le sessioni SMTP in ingresso si presentavano come FOPE, l'indirizzo IP sorgente era un indirizzo IP privato. Si scopre che era un indirizzo IP virtuale (VIP) su un bilanciamento del carico che distribuite sessioni SMTP in ingresso tra i server Exchange 2010 ibrido.

Ho aggiunto il VIP private per l'elenco di intervalli IP server remoto su Office 365 connettore di ricezione. Poi i messaggi sono stati consegnati con successo. Se stai utilizzando un sistema di bilanciamento del carico per SMTP, controllare per vedere se hai a che fare con lo stesso problema.

Il tasto destro

D. Noi abbiamo appena configurato due server ibridi Exchange Server 2013. Ci stiamo chiedendo se possiamo utilizzare una chiave di edizione Exchange Server 2013 ibrido per questi server come si può con i server Exchange 2010 ibrido?

**R.**Le cose sono ancora essere risolto adesso quando si tratta di codice product key utilizzato per correttamente licenze Exchange Server 2013 come un server di coesistenza. Così, per ora, basta usare Exchange Server 2013 in modalità di prova. Quando scade il trial, non dovrebbe avere alcun impatto sulla vostra distribuzione ibrida. Appena si tradurrà in extra nag-screen.

Henrik Walther è un Microsoft Certified Master: Exchange 2007 ed Exchange MVP con più di 18 anni di esperienza nel settore IT. Lavora come consulente senior del team di cloud Office 365 con Microsoft Services Danimarca e come un technical writer per Biblioso Corp. (una società statunitense specializzata in gestione servizi di localizzazione e documentazione). Ha più di 14 anni di esperienza di scrittura di libri, articoli, colonne, white paper e newsletter.

Contenuti correlati

• Exchange Queue & R: Lavorabile Work-around

• Exchange Queue & R: Gestione della migrazione

• Exchange Queue & R: Exchange è sempre in evoluzione