Trasporto in una distribuzione ibrida
Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Ultima modifica dell'argomento: 2016-04-20
Service Pack 2 (SP2) per Microsoft Exchange Server 2010 offre la possibilità di ospitare alcuni degli utenti di Exchange in un'organizzazione Exchange Online ospitata in Microsoft Office 365 per aziende, mantenendo le stesse prestazioni di messaggistica per tutti gli utenti. Questo argomento descrive l'utilizzo dei server di trasporto in questo scenario.
Una distribuzione ibrida richiede la presenza di almeno un server con Exchange Server 2010 SP2 nell'organizzazione. Se si dispone di una versione precedente di Exchange, è necessario aggiungere uno o più server Exchange 2010 SP2 che svolgano la funzione di gateway per l'organizzazione Exchange Online. In questo modo, si può abilitare una distribuzione ibrida senza dover aggiornare l'intera distribuzione esistente. Questi server Exchange 2010 sono conosciuti come server ibridi.
L'organizzazione deve contenere uno o più server ibridi con installati i ruoli Trasporto Hub e Accesso client. Il ruolo del server Cassette postali è necessario anche per le organizzazioni Exchange Server 2003 che devono supportare lo scambio di informazioni sulla disponibilità tra le cassette postali di Exchange 2003 locali e quelle di Exchange Online. L'aggiunta di questo server ibrido all'organizzazione equivale a introdurre il primo server Exchange 2010 nella distribuzione. Per maggiori informazioni sulle distribuzioni ibride, vedere Distribuzioni ibride con Exchange 2010 SP3.
Sommario
Flusso di posta
Funzionalità di trasporto
Trasporto Edge in una distribuzione ibrida
Flusso di posta
Il flusso di posta tra la distribuzione locale e l'organizzazione Exchange Online è messo in sicurezza e protetto da Transport Layer Security (TLS). L'endpoint TLS nell'organizzazione locale deve essere un server Trasporto Hub o Trasporto Edge di Exchange 2010 SP2 con Exchange 2010 SP1 o SP2.
L'organizzazione locale e l'organizzazione Exchange Online si inviano i messaggi direttamente attraverso un canale protetto. Per abilitare questo flusso di posta elettronica, un connettore di invio ibrido viene creato automaticamente dalla procedura guidata di gestione della configurazione ibrida. Solo un server Trasporto Hub in esecuzione su Exchange 2010 SP2 o server di origine Trasporto Edge in esecuzione su Exchange 2010 SP1 o Exchange 2010 SP2 può essere selezionato per questo connettore di invio. Se nell'organizzazione è disponibile Exchange 2010 SP2, qualsiasi server Trasporto Hub o Trasporto Edge può svolgere la funzione di gateway per l'organizzazione Exchange Online. Se sono disponibili versioni precedenti di Exchange, è necessario distribuire un server ibrido Trasporto Hub o Trasporto Edge per smistare i messaggi tra le due organizzazioni.
In una distribuzione ibrida, ciascuna organizzazione considera l'altra come un'organizzazione interna. Non vi è praticamente nessuna differenza tra un utente ospitato sui server locali e un utente Exchange Online quando Exchange elabora i messaggi. I filtri posta indesiderata vengono inoltre esclusi per i messaggi scambiati tra le due organizzazioni.
Flusso di posta protetto e autenticato
Anche se i messaggi tra le organizzazioni locali e le organizzazioni Exchange Online passano attraverso un canale logico, vengono sempre trasferiti in Internet e devono quindi essere protetti da utenti malintenzionati. Exchange 2010 offre le seguenti misure di protezione:
Privacy canale Gli utenti non autorizzati non possono accedere ai pacchetti acquisiti.
Autenticazione destinatario I mittenti sono protetti da utenti non autorizzati che si spacciano per destinatari validi.
Autenticazione mittente I destinatari sono protetti da utenti non autorizzati che si spacciano per mittenti validi.
Privacy canale
Per proteggere sia le organizzazioni locali che quelle basate su cloud, Exchange 2010 forza TLS con i certificati SSL (Secure Sockets Layer) forniti da un'autorità di certificazione (CA) affidabile. I certificati autofirmati non sono supportati per la privacy di canale in una distribuzione ibrida. Tutti i messaggi inviati attraverso il canale protetto TLS sono crittografati.
I server di invio e riceventi esaminano il certificato configurato sull'altro server. Il nome soggetto o uno dei nomi alternativi soggetto configurato sui certificati deve essere uguale al nome di dominio completo che un amministratore ha specificato esplicitamente sull'altro server. Ad esempio, se la configurazione dell'organizzazione Exchange Online prevede che questa accetti e protegga i messaggi inviati dal dominio con nome completo mail.contoso.com, i server ibridi locali di invio devono avere un certificato SSL con mail.contoso.com nel nome del soggetto o come SAN. Se questa condizione non è soddisfatta, la connessione viene rifiutata.
Autenticazione destinatario
Oltre ai normali controlli dei certificati eseguiti durante TLS, i connettori di invio che partecipano al flusso di posta della distribuzione ibrida eseguono anche la convalida del dominio. La convalida del dominio è una funzionalità di sicurezza aggiuntiva che riduce il rischio rappresentato da utenti malintenzionati che tentano di farsi passare per server ricevente. Quando è abilitata la convalida del dominio su un connettore di invio, il server di trasporto esegue i seguenti controlli di sicurezza sulla connessione esterna:
Il canale di comunicazione è crittografato con TLS.
Il certificato del server ricevente viene convalidato e vengono eseguiti i controlli dell'elenco di revoche.
Il server di trasporto verifica che il nome di dominio completo sul certificato del server ricevente corrisponda al dominio configurato nelle proprietà del connettore di invio.
Autenticazione mittente
Per impedire a un utente malintenzionato di farsi passare per un mittente valido, ciascun messaggio viene autenticato per verificare che sia stato inoltrato dal mittente specificato. All'interno di un'organizzazione Exchange, l'autenticazione del mittente viene verificata utilizzando le intestazioni personalizzate del messaggio aggiunte dai server Exchange. Per i messaggi scambiati tra le organizzazioni locali e le organizzazioni Exchange Online, i valori di queste intestazioni sono crittografate all'origine e quindi decrittografate e verificate alla destinazione. Quando sono in transito, queste intestazioni non possono essere decrittografate da eventuali soggetti che potrebbero acquisire il messaggio.
Posta elettronica da e verso Internet
I destinatari di organizzazioni locali e organizzazioni Exchange Online, in genere dispongono dello stesso indirizzo di risposta, come @contoso.com. Poiché hanno lo stesso indirizzo di risposta, tutti i messaggi ai destinatari in entrambe le organizzazioni devono seguire lo stesso instradamento in ingresso. Tutti i messaggi in ingresso possono essere inviati sia all'organizzazione locale che all'organizzazione Exchange Online. Dove instradare i messaggi in ingresso dipende da dove sono ubicate la maggior parte delle cassette postali, se è presente Microsoft Forefront Online Protection (FOPE) e altri fattori.
I messaggi inviati verso Internet dalle organizzazioni locale e Exchange Online possono seguire lo stesso instradamento o un instradamento diverso. I messaggi inviati da organizzazioni locali vengono sempre inviati direttamente a Internet. I messaggi inviati dai destinatari Exchange Online possono essere inviati direttamente a Internet o instradati prima attraverso l'organizzazione locale. Può essere necessario instradare i messaggi Exchange Online attraverso l'organizzazione locale se prima si vogliono applicare loro dei criteri di conformità.
È necessario fare molte considerazioni quando si pianifica il trasporto per la distribuzione ibrida, quali ad esempio se usare FOPE per proteggere l'organizzazione locale, se avere un server di trasporto Edge configurato e come si vuole instradare la posta elettronica in ingresso e in uscita da e verso Internet. Per informazioni dettagliate relative a queste considerazioni e per un aiuto nel decidere quali opzioni sono migliori per l'organizzazione, vedere Concetti relativi alle opzioni di trasporto nelle distribuzioni ibride di Exchange 2003.
Funzionalità di trasporto
In questa sezione è descritto l'uso delle varie funzionalità di trasporto in una distribuzione ibrida. Le informazioni qui riportate implicano l'utilizzo di Exchange 2010 nella distribuzione locale, perché alcune delle funzionalità qui descritte non sono disponibili per le versioni precedenti di Exchange. Per ulteriori informazioni, vedere gli argomenti seguenti:
Nota
Le funzionalità descritte in questa sezione sono disponibili solo in una distribuzione ibrida.
Regole di trasporto e regole di journal
Le regole di trasporto e le regole di journal non sono sincronizzate tra la distribuzione locale e l'organizzazione Exchange Online. Di conseguenza, è necessario garantire che le regole implementate siano le stesse in entrambe le organizzazioni.
Rapporti di recapito
Gli utenti possono tenere traccia dei messaggi inviati e ricevuti in una distribuzione ibrida purché per le corrispondenti relazioni siano abilitati i rapporti di recapito sia per le organizzazioni locali che per le organizzazioni Exchange Online. Per impostazioni predefinita, questa funzionalità è abilitata in una distribuzione ibrida. Tuttavia, tenere presente che se non si dispone di versioni precedenti di Exchange nella distribuzione locale, i rapporti di recapito non visualizzeranno il recapito finale ai destinatari ospitati sui server legacy, ma piuttosto che il messaggio è stato trasferito sul sistema Exchange legacy. Questa non è una limitazione della distribuzione ibrida; il motivo è dovuto alle modifiche nell'implementazione della verifica dei messaggi in Exchange 2010. Per ulteriori informazioni, vedere la sezione “Verifica messaggi tra versioni diverse” in Aggiornamento da Exchange 2007 Transport.
MailTips
I suggerimenti messaggio sono progettati per funzionare perfettamente in una distribuzione ibrida. Se un utente locale invia un messaggio a un destinatario nell'organizzazione Exchange Online, i server Accesso client locali contattano i server di Accesso client dell'organizzazione Exchange Online e richiedono i dati dell'avviso di quello specifico messaggio. A questa richiesta, i server Accesso client dell'organizzazione Exchange Online elaborano la richiesta di avviso messaggi, valutano la presenza di avvisi nel messaggio e restituiscono tutti gli avvisi applicabili ai server Accesso client. Il processo è lo stesso anche quando un utente dell'organizzazione Exchange Online invia un messaggio a un destinatario locale.
In una distribuzione ibrida occorre tenere in considerazione le seguenti differenze relative a Suggerimenti messaggio:
L'avviso messaggio per i destinatari esterni viene valutato solo nell'organizzazione locale. Questo è perché l'organizzazione Exchange Online non riesce a stabilire quali destinatari sono considerati esterni per un utente locale.
Per lo stesso motivo, il numero dei destinatari esterni in un gruppo di avvisi messaggi viene valutato solo per i gruppi locali che utilizzano i dati della metrica di gruppo.
L'avviso di messaggio con dimensione oltre i limiti consentiti viene valutato sia localmente che dall'organizzazione remota. Di conseguenza, è importante accertarsi che i limiti di dimensione dei messaggi per l'organizzazione locale corrispondano a quelli configurati per l'organizzazione Exchange Online per evitare incongruenze per gli utenti.
Tutti gli oggetti nell'organizzazione remota sono rappresentati come oggetti abilitati alla posta elettronica nell'organizzazione locale. Ad esempio, una cassetta postale nell'organizzazione Exchange Online è rappresentata come utente di posta nell'organizzazione locale. Poiché tutti gli oggetti possono avere avvisi messaggi personalizzati, potenzialmente è possibile configurare due diversi avvisi personalizzati per lo stesso destinatario. In questo caso, verranno visualizzati solo gli avvisi messaggi personalizzati. Gli utenti locali vedranno gli avvisi messaggi personalizzati configurati per l'oggetto locale e gli utenti basati su cloud vedranno gli avvisi messaggi personalizzati configurati per l'oggetto Exchange Online.
È inoltre possibile che vi sia una diversa configurazione per i destinatari moderati o i destinatari con limitazioni. Ad esempio, una cassetta postale locale potrebbe avere limitazioni, ma il corrispondente utente di posta nell'organizzazione Exchange Online potrebbe non averne. In questo scenario, verrà visualizzato l'avviso Destinatario con limitazioni anche per l'utente Exchange Online. L'avviso Destinatario con limitazioni funziona in modo simile.
Gli avvisi messaggio sono configurati per funzionare in una distribuzione ibrida per impostazione predefinita. Tuttavia, è possibile personalizzare il modo in cui gli avvisi messaggi vengono gestiti se si desidera differenziare l'esperienza tra utenti locali e utenti Exchange Online. Per ulteriori informazioni, vedere la sezione "Architettura degli avvisi messaggi" in Informazioni sugli avvisi messaggio e la sezione "Configurazione degli avvisi messaggi per le relazioni tra le organizzazioni con Shell" in Configurazione delle impostazioni organizzative per i suggerimenti messaggio.
Moderazione messaggio
La funzionalità di moderazione dei messaggi per la distribuzione ibrida si basa sui seguenti requisiti:
Sincronizzazione degli attributi di moderazione degli oggetti abilitati alla posta.
Almeno una cassetta postale di arbitraggio creata nell'organizzazione locale.
Almeno una cassetta postale di arbitraggio creata nell'organizzazione Exchange Online. Sarà necessario creare manualmente un contatto di posta elettronica con un indirizzo SMTP sul cloud e impostare DomainType su InternalRelay.
Conservazione delle intestazioni e del formato TNEF tra le due organizzazioni.
Quando si configura una distribuzione con Office 365, vengono soddisfatti tutti i precedenti requisiti. Non è necessario fare nulla di aggiuntivo per far funzionare la moderazione dei messaggi.
Per ulteriori informazioni sui tipi di dominio, vedere Domini di inoltro.
Trasporto Edge in una distribuzione ibrida
Il flusso di posta in una distribuzione ibrida richiede un server con Exchange 2010 SP2 come endpoint TLS per la distribuzione locale. Di norma, si tratta di un server Trasporto Hub Exchange 2010 SP2 nell'organizzazione locale. Tuttavia, se non si vuole esporre il server Trasporto Hub interno direttamente a Internet, è possibile usare un server Trasporto Edge Exchange 2010 SP2 come endpoint TLS. Se si usa un server Trasporto Edge, quel server gestirà la posta elettronica tra l'organizzazione locale e l'organizzazione Exchange Online al posto del server Trasporto Hub. È anche possibile usare un server Trasporto Edge per gestire la posta elettronica da e verso utenti Internet per l'organizzazione locale.
Per ulteriori informazioni relative ai server Trasporto Edge nella distribuzione ibrida, vedere:
Se si utilizzano server Trasporto Edge Exchange 2007 nell'organizzazione, questi devono essere aggiornati a Exchange 2010 SP2 se si sta pianificando di utilizzarli in una distribuzione ibrida.
©2010 Microsoft Corporation. Tutti i diritti riservati.