Aggiornamento da Exchange 2007 Transport

Si applica a: Exchange Server 2010

Ultima modifica dell'argomento: 2009-12-09

Durante l'aggiornamento da Microsoft Exchange Server 2007 a Exchange Server 2010, per un certo periodo entrambe le versioni coesistono nell'ambiente di produzione. È possibile pianificare un percorso di aggiornamento da Exchange 2007 a Exchange 2010 utilizzando le informazioni in questo argomento, che include cenni preliminari, informazioni tecniche sul flusso dei messaggi in un ambiente di coesistenza e considerazioni sull'uso in un ambiente a versioni miste.

Il punto più importante di uno scenario di coesistenza di Exchange 2010 e Exchange 2007 riguarda il fatto che ogni server Cassette postali necessita di un server Trasporto Hub con una versione corrispondente di Exchange nello stesso sito Active Directory. A causa delle modifiche apportate al modello Exchange Server Object (XSO) in Exchange 2010, i server Trasporto Hub di Exchange 2010 non possono prelevare e recapitare i messaggi nei server Cassette postali di Exchange 2007. Allo stesso modo, i server Trasporto Hub di Exchange 2007 non sono in grado di comunicare con i server Cassette postali Exchange 2010. Di conseguenza, è necessario mantenere i server Trasporto Hub di Exchange 2007 in un sito Active Directory specifico fino a quando tutti i server Cassette postali di Exchange 2007 non sono stati rimossi dal sito. Per ulteriori informazioni sull'instradamento dei messaggi in un ambiente di coesistenza, vedere "Routing dei messaggi tra le versioni" più avanti in questo argomento.

Sommario

Percorso di aggiornamento del server di trasporto

Routing dei messaggi tra le versioni

Differenze in EdgeSync

Regole di trasporto e inserimento nel journal in uno scenario di coesistenza

Gestione delle impostazioni DSN in un ambiente misto

Verifica dei messaggi tra le versioni

Funzionalità di trasporto di Exchange 2010 in uno scenario di coesistenza

Percorso di aggiornamento del server di trasporto

L'aggiornamento dei server Trasporto Hub e Trasporto Edge di Exchange 2007 deve essere parte della strategia di aggiornamento complessiva. L'ordine consigliato prevede di aggiornare i server di trasporto dopo i server Accesso client e prima dei server Messaggistica unificata e Cassette postali. I server Trasporto Edge devono essere aggiornati dopo l'aggiornamento dei server Trasporto Hub. Per ulteriori informazioni sulla pianificazione dell'aggiornamento, vedereExchange 2007 - Planning Roadmap for Upgrade and Coexistence.

Prima di introdurre i server Trasporto Hub o Trasporto Edge di Exchange 2010, assicurarsi che tutti i server Exchange 2007 nel sito siano aggiornati a Exchange 2007 Service Pack 2 (SP2). Exchange 2007 SP2 è richiesto per la coesistenza di server Trasporto Hub di Exchange 2010 e Exchange 2007 in un singolo sito Active Directory. È richiesto anche Exchange 2007 SP2 per il funzionamento del servizio Microsoft Exchange EdgeSync tra le versioni.

Se Exchange 2007 è stato distribuito in più siti, è necessario aggiornare prima i siti connessi a Internet. L'ordine di aggiornamento dei siti rimanenti dipende dalla topologia e dalle priorità dell'organizzazione.

Il processo seguente mostra il percorso di aggiornamento consigliato per i server di trasporto in un sito con connessione Internet. (Si presuppone l'utilizzo di server Trasporto Edge con EdgeSync. Se si utilizza uno smart host di terze parti, è possibile tralasciare i passaggi 2-6). Il processo di aggiornamento è il seguente:

1. Introdurre il primo server Trasporto Hub di Exchange 2010 nel sito. Non appena il server Trasporto Hub di Exchange 2010 viene introdotto nel sito, viene eseguita la sincronizzazione di Edge. Tuttavia, dal momento che il server Trasporto Edge esegue ancora Exchange 2007 SP2, il server Trasporto Hub di Exchange 2010 non esegue una sincronizzazione di EdgeSync incrementale, ma replica i dati di EdgeSync completi, come un server Trasporto Hub di Exchange 2007. Per il recapito dei messaggi su Internet, il server Trasporto Hub di Exchange 2010 passa attraverso il server Trasporto Hub di Exchange 2007, come mostrato nella figura.
   Introduzione di un server Trasporto Hub di Exchange 2010 in un sito di Exchange 2007 esistente
   

2. Sottoscrivere nuovamente il server Trasporto Edge di Exchange 2007 nel sito. In questo modo il server Trasporto Hub di Exchange 2010 viene aggiunto alla sottoscrizione di Edge come server di origine, come mostrato nella figura.

   Nota

   Se si prevede di aggiungere più server Trasporto Hub di Exchange 2010 al sito Active Directory, per risparmiare tempo è possibile distribuire tutti i nuovi server Trasporto Hub prima di sottoscrivere i server Trasporto Edge.

   Sottoscrizione dei server Trasporto Edge di Exchange 2007 dopo l'introduzione del server Trasporto Hub di Exchange 2010
   

3. Introdurre il primo server Trasporto Edge di Exchange 2010 nella rete perimetrale.

4. Sottoscrivere il server Trasporto Edge di Exchange 2010 nel sito. A questo punto, il server Trasporto Hub di Exchange 2010 avvia gli aggiornamenti incrementali verso il server Trasporto Edge di Exchange 2010, come mostrato nella figura.
   Sottoscrizione del server Trasporto Edge di Exchange 2010
   

5. Rimuovere la sottoscrizione Edge di Exchange 2007.

6. Rimuovere le autorizzazioni dai server Trasporto Edge di Exchange 2007, come mostrato nella figura.
   Rimozione dei server Trasporto Edge di Exchange 2007
   

7. Dopo aver trasferito tutte le cassette postali sui server Cassette postali di Exchange 2010, rimuovere le autorizzazioni dai server Trasporto Hub di Exchange 2007.

Inizio pagina

Routing dei messaggi tra le versioni

A causa delle modifiche apportate al modello Exchange Server Object (XSO) in Exchange 2010, i server Trasporto Hub di Exchange 2010 non possono prelevare e recapitare i messaggi nei server Cassette postali di Exchange 2007. Allo stesso modo, i server Trasporto Hub di Exchange 2007 non sono in grado di comunicare con i server Cassette postali Exchange 2010. Di conseguenza, per utilizzare sia Exchange 2010 sia Exchange 2007 nello stesso sito Active Directory, è necessario mantenere entrambe le versioni dei server Trasporto Hub in quel sito, come mostrato nella figura. Le versioni dei server nel sito B non sono mostrate nella figura, perché la gestione del traffico SMTP tra siti equivale a quella in Exchange 2007. Il server Trasporto Hub inoltra i messaggi al server Trasporto Hub nel sito remoto per il recapito.

Flusso dei messaggi tra Exchange 2010 ed Exchange 2007

Per abilitare il flusso dei messaggi tra le versioni, in Exchange 2010 viene implementata una funzionalità chiamata routing con versione. Nel routing con versione, il modulo di gestione del routing controlla la versione del server principale della cassetta postale e il suo sito Active Directory. Se la versione non corrisponde, il messaggio viene inoltrato a un server Trasporto Hub con una versione corrispondente, come mostrato nel flusso di lavoro di routing con versione nella figura. Il routing ora è dipendente sia dai siti Active Directory sia dalle versioni di Exchange.

Flusso di lavoro del routing con versione

Quando l'utente di una cassetta postale di Exchange 2010 invia un messaggio all'utente di una cassetta postale di Exchange 2007 nello stesso sito, si verifica quanto segue:

1. Il server Cassette postali Exchange 2010 notifica al server Trasporto Hub di Exchange 2010 la presenza di nuovi messaggi.
2. Il server Trasporto Hub di Exchange 2010 preleva il messaggio.
3. L'agente di routing determina che la versione del server Cassette postali che rappresenta il server principale della cassetta postale di destinazione non corrisponde alla propria versione.
4. L'agente di routing individua un server Trasporto Hub di Exchange 2007 nel sito locale.
5. Il server Trasporto Hub di Exchange 2010 inoltra il messaggio al server Trasporto Hub di Exchange 2007.
6. L'agente di routing sul server Trasporto Hub di Exchange 2007 determina che la cassetta postale di destinazione si trova su un server Cassette postali di Exchange 2007 nel sito locale.
7. Il server Trasporto Hub di Exchange 2007 recapita il messaggio al server Cassette postali di Exchange 2007.

Tutti i messaggi inviati da utenti di cassette postali di Exchange 2007 a destinatari di Exchange 2010 seguono un percorso simile.

Il routing con versione è stato aggiunto a Exchange 2007 in SP2. Per la coesistenza di Exchange 2010 e Exchange 2007 nello stesso sito Active Directory, è necessario per prima cosa aggiornare i server Exchange 2007 esistenti a SP2. Se Exchange 2010 ed Exchange 2007 SP2 si trovano nello stesso sito Active Directory, ciascun server Trasporto Hub gestisce i messaggi per i server Cassette postali con versioni corrispondenti. Il routing con versione non modifica il modo in cui vengono instradati i messaggi all'interno del sito.

Quando si dispone di Exchange 2010 e Exchange 2007 nello stesso sito, tenere presente quanto segue:

• Non è possibile specificare un server Trasporto Hub incompatibile come sostituzione del server di invio per un server Cassette postali.
• Per uno specifico server Cassette postali, se non si dispone di un server Trasporto Hub con una versione corrispondente nel sito locale, eventuali messaggi inviati dall'utente su quel server Cassette postali rimarranno sul server Cassette postali.
• Per uno specifico server Cassette postali, se non si dispone di un server Trasporto Hub con una versione corrispondente nel sito locale, saranno emessi report di mancato recapito per tutti i messaggi inviati dagli utenti su quel server Cassette postali.
• I messaggi inviati a cartelle pubbliche abilitate alla posta vengono gestiti in modo analogo ai messaggi inviati alle cassette postali.

Inizio pagina

Differenze in EdgeSync

Il processo di sincronizzazione di Edge è stato migliorato in Exchange 2010. In Exchange 2007, EdgeSync replicava tutte le informazioni di configurazione e sui destinatari nella loro interezza. Questa procedura richiedeva molto tempo, in particolare nelle organizzazioni con un elevato numero di destinatari. Exchange 2010 introduce gli aggiornamenti incrementali per EdgeSync. Alla prima sottoscrizione di un server Trasporto Edge di Exchange 2010 in un sito, vengono sincronizzate tutte le informazioni di configurazione e i dati dei destinatari. In tutti gli aggiornamenti successivi, vengono replicate solo le modifiche. Di conseguenza, il tempo di sincronizzazione e l'utilizzo sono sostanzialmente ridotti.

Anche se i server Trasporto Hub di Exchange 2007 possono partecipare a EdgeSync con i server Trasporto Edge di Exchange 2010, gli aggiornamenti incrementali sono disponibili solo tra server Trasporto Hub di Exchange 2010 e server Trasporto Edge di Exchange 2010. Per impostazione predefinita, quando un server Trasporto Edge di Exchange 2010 viene sottoscritto in un sito Active Directory contenente server Trasporto Hub di Exchange 2010, i server Trasporto Hub di Exchange 2010 hanno la precedenza nel processo EdgeSync. È possibile ritornare ai server Trasporto Hub di Exchange 2007 disabilitando il servizio Microsoft Exchange EdgeSync nei server Trasporto Hub di Exchange 2010. Tuttavia, se si esegue questa operazione, è possibile ritornare alla replica di tutti i dati ad ogni aggiornamento EdgeSync, invece di utilizzare gli aggiornamenti incrementali.

Per ulteriori informazioni su EdgeSync, vedere Informazioni sulle sottoscrizioni Edge.

Inizio pagina

Regole di trasporto e inserimento nel journal in uno scenario di coesistenza

Se si utilizzano già le regole di trasporto o l'inserimento nel journal nell'organizzazione di Exchange 2007, assicurarsi che queste funzionalità continuino a funzionare durante il periodo di coesistenza, indipendentemente dal server Trasporto Hub che elabora un messaggio specifico.

Alle regole di trasporto e di inserimento nel journal in Exchange 2010 sono state apportate le seguenti modifiche significative, che influiscono sulla gestione di queste funzionalità in un ambiente misto:

• Modifiche al formato   Le regole di trasporto di Exchange 2010 supportano una serie di nuovi predicati e azioni. Per supportare questi nuovi predicati e azioni, è stato modificato il formato di archiviazione delle regole di trasporto in Active Directory. I server Trasporto Hub di Exchange 2007 non possono elaborare questi nuovi predicati e azioni. Per un elenco completo dei predicati e delle azioni disponibili in Exchange 2010, vedere Predicati delle regole di trasporto e Azioni delle regole di trasporto.
• Percorso di archiviazione in Active Directory   Per impedire agli agenti Regole di trasporto di Exchange 2007 di caricare e tentare di elaborare le regole create in Exchange 2010, le regole di Exchange 2010 sono memorizzate in un contenitore di Active Directory distinto. Lo stesso vale per le regole di inserimento nel journal.

Copia della configurazione esistente in Exchange 2010

Durante l'installazione di Exchange 2010, se il programma rileva la presenza di regole di trasporto di Exchange 2007, le regole legacy vengono automaticamente esportate in un percorso temporaneo e successivamente vengono importate nel contenitore delle regole di trasporto di Exchange 2010 in Active Directory. Questo processo avviene automaticamente senza interazione dell'utente.

Analogamente, tutte le regole del journal di Exchange 2007 vengono convertite e copiate in regole del journal di Exchange 2010 durante l'installazione. Per ulteriori informazioni, vedere Esportazione e importazione delle regole di inserimento nel journal di Exchange 2007.

Gestione delle regole di trasporto e dell'inserimento nel journal in un ambiente misto

L'importazione automatica delle regole in Exchange 2010 viene eseguita solo durante l'installazione iniziale. In questa fase, viene sincronizzato l'insieme di regole di trasporto e regole del journal per Exchange 2010 ed Exchange 2007. In seguito, se si apportano modifiche a una regola esistente, o se si crea una regola, la regola interessata viene modificata in un singolo percorso, in base allo strumento di gestione utilizzato. Ad esempio, in Exchange 2010, se si utilizza Exchange Management Shell per creare una regola, viene aggiornato solo il contenitore delle regole di Exchange 2010 in Active Directory. Analogamente, se si utilizza Exchange Management Console (EMC) su un server Exchange 2007 per modificare una regola esistente, viene modificata solo la versione Exchange 2007 di tale regola.

Per assicurare che le regole di trasporto e del journal rimangano coerenti tra le versioni, eventuali modifiche apportate devono essere eseguite due volte, una con gli strumenti di gestione di Exchange 2010 e una con gli strumenti di gestione di Exchange 2007.

Inizio pagina

Gestione delle impostazioni DSN in un ambiente misto

In Exchange 2010, le impostazioni DSN interne ed esterne vengono configurate per l'intera organizzazione di Exchange. In Exchange 2007, queste impostazioni venivano configurate in base al singolo server. Di conseguenza, le impostazioni sono memorizzate in oggetti di configurazione diversi in Active Directory e, come le regole di trasporto, devono essere gestite separatamente in uno scenario di coesistenza.

Nello specifico, le seguenti impostazioni sono state spostate dal cmdlet Set-TransportServer al cmdlet Set-TransportConfig in Exchange 2010:

• ExternalDelayDsnEnabled
• ExternalDsnDefaultLanguage
• ExternalDsnLanguageDetectionEnabled
• ExternalDsnMaxMessageAttachSize
• ExternalDsnReportingAuthority
• ExternalDsnSendHtml
• ExternalPostmasterAddress
• InternalDelayDsnEnabled
• InternalDsnDefaultLanguage
• InternalDsnLanguageDetectionEnabled
• InternalDsnMaxMessageAttachSize
• InternalDsnReportingAuthority
• InternalDsnSendHtml

Se è necessario modificare una di queste impostazioni nell'organizzazione, la modifica deve essere eseguita una volta per l'organizzazione utilizzando il cmdlet Set-TransportConfig in Exchange 2010 Shell e una volta per ciascun server Trasporto Hub di Exchange 2007 nell'organizzazione utilizzando il cmdlet Set-TransportServer in Exchange 2007 Shell.

Inizio pagina

Verifica dei messaggi tra le versioni

Exchange 2010 fornisce funzionalità di verifica dei messaggi migliorate. Gli utenti finali e gli amministratori ora possono tenere traccia dei messaggi inviati utilizzando lo strumento Rapporti di recapito del Pannello di controllo di Exchange.

I rapporti di recapito consentono la verifica dei messaggi end-to-end da una singola posizione, mettendo a disposizione informazioni dettagliate sul recapito, tra cui l'ora in cui un messaggio è stato segnato come letto. In Exchange 2010, per supportare i rapporti di recapito sono stati implementati una chiamata di procedura remota di verifica dei nuovi messaggi e un'interfaccia del servizio Web. Queste interfacce non esistevano in Exchange 2007, pertanto la funzionalità relativa ai rapporti di recapito non si estende all'infrastruttura di Exchange 2007 in uno scenario di coesistenza. Ad ogni modo, è possibile utilizzare lo strumento di verifica dei messaggi in Exchange 2007 per tenere traccia dei messaggi tra le versioni.

Nella seguente tabella è indicato come procedere per tenere traccia dei messaggi in un ambiente misto.

Verifica dei messaggi in un ambiente misto

Per ulteriori informazioni sulla verifica dei messaggi in Exchange 2010, vedere Understanding Message Tracking.

Inizio pagina

Funzionalità di trasporto di Exchange 2010 in uno scenario di coesistenza

Per la maggior parte, le nuove funzionalità di trasporto in Exchange 2010 operano solo nell'area di autenticazione di Exchange 2010. Il momento in cui iniziare a utilizzare le nuove funzionalità dipende dalle esigenze dell'organizzazione. È possibile attendere il termine dell'aggiornamento, oppure iniziare subito dopo l'introduzione di Exchange 2010 nell'ambiente. Per decidere quando utilizzare le nuove funzionalità in un ambiente misto, prendere in considerazione le seguenti informazioni.

Destinatari con moderatore

Exchange 2010 introduce i destinatari con moderatore, che consentono di sottoporre a un processo di approvazione i messaggi inviati a destinatari specifici. Se si prevede di utilizzare i destinatari con moderatore in uno scenario di coesistenza, è opportuno tenere conto dei seguenti problemi, che dipendono dal tipo di destinatario:

• Cassette postali   È possibile abilitare alla moderazione solo le cassette postali sui server Cassette postali Exchange 2010. Dopo aver abilitato una cassetta postale per la moderazione, assicurarsi che non venga nuovamente spostata in un server Cassette postali di Exchange 2007.
• Gruppi di distribuzione e gruppi di distribuzione dinamici   I messaggi indirizzati a un gruppo di distribuzione moderato devono superare il processo di approvazione solo quando il gruppo di distribuzione viene espanso su un server Trasporto Hub di Exchange 2010. Dal momento che il gruppo di distribuzione può essere espanso su qualsiasi server, si consiglia di attendere fin quando tutti i server Trasporto Hub non sono stati aggiornati a Exchange 2010 prima di utilizzare i gruppi di distribuzione moderati.
• Contatti di posta e utenti di posta   I server Trasporto Hub instradano i messaggi in base all'indirizzo e-mail esterno specificato per ogni utente o contatto di posta. Dal momento che non è possibile forzare il passaggio in un server Trasporto Hub di Exchange 2010 dei messaggi per questi tipi di destinatari, potrebbe essere preferibile non abilitare la moderazione per questi tipi di destinatari in un ambiente misto.

Se si abilita un destinatario per la moderazione, assicurarsi che i moderatori designati utilizzino un client che consenta di visualizzare le opzioni di approvazione e rifiuto per una richiesta di approvazione. Tutti i moderatori dovrebbero utilizzare Microsoft Outlook 2010 o Microsoft Office Applicazione Web Outlook in Exchange 2010.

Per ulteriori informazioni sui destinatari con moderatore, vedere Informazioni sul trasporto moderato.

Ridondanza shadow

Exchange 2010 introduce la ridondanza shadow per garantire la ridondanza dei messaggi per l'intera fase di transito. La soluzione richiede una tecnica simile al dumpster di trasporto. Con la ridondanza shadow, l'eliminazione di un messaggio dai database di trasporto viene ritardata fin quando il server di trasporto non verifica che tutti gli hop successivi per quel messaggio abbiano completato il recapito. Se uno degli hop successivi restituisce un risultato negativo prima di segnalare il completamento corretto del recapito, il messaggio viene inviato nuovamente a tale hop per il recapito.

La ridondanza shadow è abilitata per impostazione predefinita in Exchange 2010 e garantisce che i messaggi siano ridondanti solo durante il trasferimento tra server Exchange 2010. Dopo il trasferimento a un server Exchange 2007, il messaggio non è più ridondante. Di conseguenza, per garantire che un messaggio che ha origine da un server Exchange 2010 rimanga ridondante fino al recapito, è necessario assicurarsi che non venga trasferito a un server Exchange 2007. Ad esempio, se si utilizza un sito hub contenente server Exchange 2007, i messaggi tra due spoke non saranno ridondanti anche se entrambi utilizzano server Exchange 2010.

Per ulteriori informazioni sulla ridondanza shadow, vedere Informazioni sulla ridondanza shadow.

Inizio pagina