Pierderi acoperire de date se poate produce în timpul migrării foldere publice Exchange 2013, Exchange 2016 sau Exchange Online

IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată și poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate și articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cunoștințe în mai multe limbi. Articolele traduse automat și post-editate pot conține greșeli de vocabular, sintaxă și/sau gramatică. Microsoft nu este responsabil de inexactitățile, erorile sau daunele cauzate de traducerea greșită a conținutului sau de utilizarea acestuia de către clienți. Găsiți mai multe informații despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 3161916
Simptome
Dacă folosiți batch migraresau migrare serial migrarea folderelor publice din Microsoft Exchange Server 2007 sau Microsoft Exchange Server 2010 în pierderi acoperire de date Exchange Server 2013, 2016 de Server Exchange sau Exchange Online, se poate produce dacă toate dublurile folder nu sunt pe bază acoperire de date primară (serverul de bază acoperire de date primară care serviciul de migrare se conectează la). Se copiază toate datele care se află în prezent prima în foldere care sunt în curs de migrare, dar modificări incrementală publicate după sincronizare inițială se pot pierde.

Exemplu de scenariu

Să presupunem că aveți două foldere publice bazele acoperire de date, PFDB1 și PFDB2, care se execută pe serverele Exchange 2007 sau Exchange 2010. De asemenea, aveți două foldere, F1 și F2. Folderul F1 are o dublură pe PFDB1 și folderul F2 are o dublură pe PFDB2.

Când porniți migrare și specificați PFDB1 ca baza acoperire de date de conectare la în cmdletul New -MigrationEndpoint , toate datele din folderele F1 și F2 este copiat în timpul sincronizării inițiale (cum se arată în figura 1). Acest lucru se produce chiar dacă PFDB1 nu are o replică locală a folderului F2.

După prima acest proces de sincronizare, să vă pregătiți pentru sincronizare finale și începe pentru a termina lot. Vă așteptați că datele pe care este adăugat la folderul F1 și F2 după trebuie copiate prin sincronizarea prima în timpul sincronizării finale.

Diagramă acel folder F1 și F2 din sursa este copiat de destinație în timpul sincronizării inițiale.
Figura 1. Folderul F1 și F2 din sursa este copiată destinație în timpul sincronizării prima.

Problema
În timpul sincronizare incrementală și finale, incrementală datele din folderul F2 nu este copiat în foldere publice moderne (cum se arată în figura 2). Aceasta se întâmplă deoarece PFDB1 este specificat ca punctul final. Batch statusis afişate ca sincronizate. Cu toate acestea, orice date noi, care a fost adăugat la folderul F2 după prima sincronizare nu sunt copiate pe moderne foldere publice.

În plus, dacă există orice nou foldere care sunt adăugate la PFDB2 după prima sincronizare (folder F3 în figura 2), conținutul din aceste foldere nu va fi fie copiat. (Acest lucru este adevărat chiar dacă F3 se afișează în ierarhia).

Diagramă care arată că datele incrementală folderul F1 este copiat și modificările la folder F2 nu sunt copiate. Date în folderul nou adăugat F3 nu este copiat, dar folderul apare în ierarhia.
Figura 2. Date incrementală folderul F1 este copiată și modificările la folder F2 nu sunt copiate. Deși nu se copiază datele în folderul nou adăugat F3, folderul apare în ierarhia.
Remediere
Înainte de a începe migrarea batch, asigurați-vă că toate folderele publice au o dublură pe baza acoperire de date a folderului public, care vor fi specificate ca sursă pentru migrare. De asemenea, asigurați-vă că reproducerea publice este sincronizat.

Soluție pentru scenariul exemplu

Pentru a rezolva această problemă, adăugați o reproducere a folderelor F2 și F3 pe PFDB1, asigurați-vă că reproducerea folderului public este sincronizat și apoi porniți batch migrare. Acest lucru asigură că datele incrementală este copiat (indiferent ce replică este inițial scris pentru).

Am dat seama că această soluție nu va funcționa pentru unii clienţi din cauza dimensiunea de implementare de public folder. Dacă vă aflați în această situație, vă recomandăm să aşteptaţi până când problema este fix înainte de a executa o migrare.

întrebări frecvente

Q:Când a început această problemă să apară?
A: această problemă a fost observată mai întâi în Exchange Server 2013 actualizarea cumulativă 1, Exchange Server 2016 RTM și Exchange Online.

Q: ce date s-a potențial pierd?
A: raport în d-na, caută "Folder ierarhie modificările raportat în sursă," Selectați prima "Folder ierarhie modificările raportat în sursă" elementul pe care este listat, și apoi selectați data și ora asociat cu Jurnalul. Datele pe care este adăugat la folderul F2 sau toate folderele noi care sunt adăugate la PFDB2 după această dată se pierde.

Q: tot am meu bazele acoperire de date foldere publice Exchange Server 2007 sau Exchange Server 2010 în starea lor blocat deoarece ne migrate la Exchange Server 2013, 2016 de Server Exchange sau Exchange Online. Pot pot migra tot pierde datele mele?
A: doar o copie manuală a datelor este posibilă.

Q: mea de migrare a luat săptămâni reachthe gata pentru a finaliza stare. Trebuie să porniți prin?
A: nu, nu trebuie să reporniți migrarea folderului public. Când se termină remedierile și actualizările sunt instalate pe server (sau pe serverele Exchange Online, dacă migraţi la Exchange Online), migrare pot fi ridicate de la care este acum și se vor migra datele rămase. Trebuie să reporniți migrare. Cu toate acestea, când faceți aceasta, procesul caută modificări și nu pornește prin. Un grup de migrare începe peste numai dacă ștergeți, apoi să o creați.

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 3161916 - Ultima examinare: 09/20/2016 19:38:00 - Revizie: 5.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 KbMtro
Feedback