Potrebbe verificarsi una perdita di dati durante la migrazione di cartelle pubbliche di Exchange 2013, 2016 Exchange o Exchange Online

IMPORTANTE: il presente articolo è stato tradotto tramite un software di traduzione automatica di Microsoft ed eventualmente revisionato dalla community Microsoft tramite la tecnologia CTF (Community Translation Framework) o da un traduttore professionista. Microsoft offre articoli tradotti manualmente e altri tradotti automaticamente e rivisti dalla community con l’obiettivo di consentire all'utente di accedere a tutti gli articoli della Knowledge Base nella propria lingua. Tuttavia, un articolo tradotto automaticamente, anche se rivisto dalla community, non sempre è perfetto. Potrebbe contenere errori di vocabolario, di sintassi o di grammatica. Microsoft declina ogni responsabilità per imprecisioni, errori o danni causati da una traduzione sbagliata o dal relativo utilizzo da parte dei clienti. Microsoft aggiorna frequentemente il software e gli strumenti di traduzione automatica per continuare a migliorare la qualità della traduzione.

Clicca qui per visualizzare la versione originale in inglese dell’articolo: 3161916
Sintomi
Se si utilizza migrazione di batcho migrazione seriale per migrare le cartelle pubbliche di Microsoft Exchange Server 2007 o Microsoft Exchange Server 2010, Exchange Server 2013 2016 Exchange Server o Exchange Online, la perdita di dati può verificarsi se non tutte le repliche di cartelle sul database principale (il server di database primario che il servizio di migrazione si connette a). Vengono copiati tutti i dati che si trova prima presenti nelle cartelle incluse nella migrazione, ma vengano perse le modifiche incrementali che vengono registrate dopo la sincronizzazione iniziale.

Scenario di esempio

Si supponga di disporre di due database delle cartelle pubbliche, PFDB1 e PFDB2, che sono in esecuzione sui server di Exchange 2007 o 2010 di Exchange. Inoltre, si dispongono di due cartelle, F1 e F2. Cartella F1 la replica su PFDB1 e cartella F2 la replica su PFDB2.

Quando si avvia la migrazione e specificare PFDB1 del database a cui connettersi nel cmdlet New -MigrationEndpoint , tutti i dati dalle cartelle F1 e F2 viene copiato durante la sincronizzazione iniziale (come mostrato nella figura 1). Ciò si verifica anche se PFDB1 non dispone di una replica locale della cartella F2.

Dopo il primo processo di sincronizzazione, la preparazione per la sincronizzazione finale e si avvia per il completamento del batch. Si prevede che tutti i dati che viene aggiunto alla cartella F1 e F2 dopo la prima sincronizzazione deve essere copiato su durante la sincronizzazione finale.

Diagramma che mostra la cartella F1 e F2 dall'origine viene copiato nella destinazione durante la sincronizzazione iniziale.
Figura 1. Cartella F1 e F2 dall'origine viene copiato nella destinazione durante la prima sincronizzazione.

Problema
Durante la sincronizzazione incrementale e finale, i dati dalla cartella F2 incrementali non vengono copiati nelle cartelle pubbliche moderne (come mostrato nella figura 2). In questo modo PFDB1 viene specificato come il punto finale. Statusis di batch visualizzati come sincronizzato. Tuttavia, tutti i nuovi dati aggiunti alla cartella F2 dopo la prima sincronizzazione non vengono copiati nelle cartelle pubbliche moderne.

Inoltre, se sono disponibili tutte le nuove cartelle che vengono aggiunti a PFDB2 dopo la sincronizzazione prima (cartella F3 nella figura 2), il contenuto di queste cartelle verrà copiato. (Ciò è possibile anche se la cartella F3 viene visualizzata nella gerarchia).

Diagramma che mostra i dati nella cartella F1 incrementali verrà copiato e le modifiche apportate alla cartella F2 non sono copiate. I dati nella cartella appena aggiuntivo non vengono copiati F3 ma la cartella verrà visualizzato nella gerarchia.
Figura 2. Incrementale vengono copiati i dati nella cartella F1 e non vengono copiate le modifiche apportate alla cartella F2. Anche se non viene copiati nella cartella appena aggiunto F3 dati, verrà visualizzata la cartella nella gerarchia.
Workaround
Prima di iniziare la migrazione di batch, assicurarsi che tutte le cartelle pubbliche sono una replica nel database di cartelle pubbliche che verrà specificato come origine per la migrazione. Inoltre, assicurarsi che la replica pubblica è sincronizzata.

Soluzione alternativa per lo scenario di esempio

Per risolvere questo problema, aggiungere una replica di cartelle F2 ed F3 in PFDB1, assicurarsi che la replica di cartelle pubbliche è sincronizzata e quindi avviare la migrazione di batch. Ciò garantisce che i dati incrementali copiati (indipendentemente da quale replica si è originariamente scritta).

Ci rendiamo conto che questa soluzione non funziona per alcuni clienti a causa delle dimensioni della distribuzione di cartelle pubbliche. Se si trova in questa situazione, si consiglia di attendere finché non viene risolto il problema prima di eseguire la migrazione.

DOMANDE FREQUENTI

Q:Quando il problema è partito a verificarsi?
Oggetto: questo problema è stato osservato prima in Exchange Server 2013 aggiornamento cumulativo 1, 2016 RTM di Exchange Server ed Exchange Online.

Q: quali dati potenzialmente perdessi?
Oggetto: report In the Signora, cercare "modifiche alla gerarchia di cartelle indicato in origine," selezionare il primo elemento "modifiche alla gerarchia di cartelle indicato in origine" elencato e quindi selezionare la data e l'ora in cui è associato al log. Tutti i dati che viene aggiunto alla cartella F2 o le nuove cartelle che vengono aggiunti a PFDB2 dopo questo tempo vengono perse.

Q: è stato il mio database di cartelle pubbliche di Exchange Server 2007 o Exchange Server 2010 nello stato bloccato poiché abbiamo migrato a Exchange Server 2013, 2016 Exchange Server o Exchange Online. È possibile comunque migrare i dati persi?
Oggetto: solo una copia manuale dei dati è possibile.

Q: la migrazione in passato erano necessarie settimane allo stato pronto per completare reachthe. È necessario ricominciare?
Oggetto: No, non è necessario riavviare la migrazione delle cartelle pubbliche. Quando sono state completate le correzioni e gli aggiornamenti vengono installati sul server (o sui server Exchange Online, se si sta eseguendo la migrazione a Exchange Online), la migrazione può essere rilevata da dove è ora e eseguirà la migrazione dei dati rimanenti. Potrebbe essere necessario riavviare il processo batch della migrazione. Tuttavia, in questo caso, il processo per le modifiche e non ricomincerà. Un batch di migrazione riprende solo se si elimina e quindi ricrearlo.

Avviso: questo articolo è stato tradotto automaticamente

Properti

ID Artikel: 3161916 - Tinjauan Terakhir: 06/24/2016 12:47:00 - Revisi: 4.0

Exchange Server 2016 Enterprise Edition, Exchange Server 2016 Standard Edition, Microsoft Exchange Server 2013 Enterprise, Microsoft Exchange Server 2013 Standard, Microsoft Exchange Online

  • kbsurveynew kbbug o365 kbgraphic kbgraphxlink kbmt KB3161916 KbMtit
Tanggapan