Aggiornamento da Exchange 2007 Transport

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2015-03-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 in uno scenario di coesistenza tra Exchange 2010 e Exchange 2007 è che tutti i server delle cassette postali necessitano di un server trasporto Hub con una corrispondente versione di Exchange nello stesso sito di 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 su come i messaggi vengono instradati in un ambiente di coesistenza, vedere "Instradamento 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, vedere Exchange 2007 - Roadmap di pianificazione per l'aggiornamento e la coesistenza.

Prima di introdurre server di trasporto Hub e server di trasporto Edge di Exchange 2010, accertarsi che tutti i server Exchange 2007 in quel sito siano stati aggiornati a Exchange 2007 Service Pack 3 (SP3). Exchange 2007 SP3 è richiesto per la coesistenza di server Trasporto Hub di Exchange 2010 e Exchange 2007 in un singolo sito Active Directory. Exchange 2007 SP3 è necessario anche per consentire il funzionamento del servizio Microsoft Exchange EdgeSync con più 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 di trasporto Hub di Exchange 2010 nel sito. Appena il server di trasporto Hub Exchange 2010 viene introdotto nel sito, inizia a utilizzare il server di trasporto Edge Exchange 2007 per il recapito dei messaggi su Internet. Il processo di sincronizzazione di EdgeSync continuerà a essere gestito dal server di trasporto Hub Exchange 2007.

   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. Questa operazione aggiunge il server di trasporto Hub Exchange 2010 alla sottoscrizione Edge come server di origine. I server di trasporto Hub Exchange 2010 hanno la precedenza sul server di trasporto Hub Exchange 2007 per la funzione di selezione dei server di origine di EdgeSync. Pertanto il server di trasporto Hub Exchange 2010 assumerà il controllo della sincronizzazione Edge, come illustrato nella figura seguente. Poiché tuttavia il server di trasporto Edge esegue ancora Exchange 2007 SP3, il server di trasporto Hub Exchange 2010 continuerà a replicare tutti i dati di EdgeSync.

   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 di server nel Sito B non vengono mostrate nella figura, dato che la gestione del traffico SMTP intersito è uguale a quella in Exchange 2007. Il server di trasporto Hub inoltra i messaggi al server di trasporto Hub del 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.

L'instradamento tra versioni è stato aggiunto in 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 SP3. Se Exchange 2010 ed Exchange 2007 SP3 si trovano nello stesso sito Active Directory, ogni server Trasporto Hub gestirà 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. Specialmente nelle organizzazioni con un alto numero di destinatari, questo può richiedere molto tempo. Exchange 2010 introduce l'aggiornamento incrementale 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.

Sebbene il server di trasporto Hub di Exchange 2007 possa partecipare in EdgeSync con il server di trasporto Hub di Exchange 2010, l'aggiornamento incrementale è disponibile solo tra server di trasporto Hub di Exchange 2010 e server di 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 tornare ai server di trasporto Hub di Exchange 2007 disabilitando il sevizio Microsoft Exchange EdgeSync sui server di 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 ai formati   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 come le regole di trasporto vengono archiviate su Active Directory. I server si trasporto Hub di Exchange 2007 non possono elaborare questi nuovi predicato 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.

• Locazione di archiviazione in Active Directory   per impedire all'agente Regole di trasporto di Exchange 2007 di caricare e tentare di elaborare le regole create in Exchange 2010, le regole Exchange 2010 vengono archiviate in un contenitore separato di Active Directory. La stessa situazione si applica alle regole di inserimento nel journal.

Copia della configurazione esistente in Exchange 2010

Quando si installa Exchange 2010, se il programma di installazione rileva la presenza di regole di trasporto di Exchange 2007, queste regole legacy vengono automaticamente esportate in una locazione temporanea e successivamente 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, solo il contenitore delle regole di Exchange 2010 in Active Directory verrà aggiornato. 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, così come gli amministratori, possono ora verificare i messaggi inviati utilizzando lo strumento Rapporti di recapito nel 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, sono state implementate nuove procedure di verifica dei messaggi RPC (remote procedure call) e interfaccia servizio Web per supportare Rapporti di recapito. 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. Tuttavia, è possibile utilizzare lo strumento di verifica messaggi in Exchange 2007 per verificare i 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 Verifica dei messaggi.

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, ci si deve assicurare che non venga riportata su un server di 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 in grado di visualizzare le opzioni di approvazione e rifiuto per una richiesta di approvazione. Si raccomanda che tutti i moderatori utilizzino Microsoft OfficeOutlook 2010 o Outlook Web App in Exchange 2010. Entrambi questi client hanno l'interfaccia utente incorporata che consente al moderatore di prendere decisioni sui messaggi.

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

 ©2010 Microsoft Corporation. Tutti i diritti riservati.