Kehilangan data dapat terjadi selama migrasi folder publik Exchange 2013, Exchange 2016 atau Exchange Online

PENTING: Artikel ini diterjemahkan oleh perangkat lunak penerjemahan mesin Microsoft, dan mungkin telah diedit oleh Masyarakat Microsoft melalui teknologi CTF dan bukan oleh seorang penerjemah profesional. Microsoft menawarkan baik artikel yang diterjemahkan oleh manusia maupun artikel hasil editan terjemahan oleh mesin/komunitas, sehingga Anda dapat mengakses semua artikel di Sentra Pengetahuan yang kami miliki dalam berbagai bahasa. Namun artikel hasil editan mesin atau bahkan komunitas tidak selalu sempurna. Artikel ini dapat mengandung kesalahan dalam hal kosa kata, sintaksis atau tatabahasa, sangat mirip dengan penutur asing yang membuat kekeliruan ketika berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab atas ketidakakuratan, kesalahan atau kerugian apa pun akibat dari kekeliruan dalam penerjemahan isi atau penggunaannya oleh pelanggan kami. Microsoft juga akan senantiasa memperbarui perangkat lunak penerjemahan mesin dan alat untuk menyempurnakan Editan Hasil Penerjemahan Mesin.

Klik disini untuk melihat versi Inggris dari artikel ini: 3161916
Gejala
Jika Anda menggunakan batch migrasiatau serial migrasi untuk memindahkan folder publik dari Microsoft Exchange Server 2007 atau Microsoft Exchange Server 2010 untuk Exchange Server 2013, Exchange Server 2016, atau Exchange Online, kehilangan data dapat terjadi jika semua folder replika tidak database utama (utama server database yang menyambungkan Layanan migrasi ke). Semua data yang ada saat pertama di folder yang sedang dimigrasi disalin, tetapi perubahan tambahan yang dikirim setelah sinkronisasi awal mungkin akan hilang.

Contoh skenario

Misalnya Anda memiliki dua folder publik database, PFDB1 dan PFDB2, yang berjalan di server Exchange 2007 atau Exchange 2010. Selain itu, Anda memiliki dua folder, F1 dan F2. Folder F1 memiliki replika PFDB1 dan folder F2 memiliki replika PFDB2.

Ketika Anda memulai migrasi dan menentukan PFDB1 sebagai pangkalan data untuk menyambung ke dalam BaruMigrationEndpoint cmdlet, semua data dari folder F1 dan F2 disalin selama sinkronisasi awal (seperti yang ditunjukkan pada gambar 1). Hal ini terjadi meskipun PFDB1 tidak memiliki replika lokal map F2.

Setelah proses sinkronisasi ini pertama kali, Anda mempersiapkan untuk sinkronisasi akhir dan memulai untuk menyelesaikan kumpulan. Anda mengharapkan bahwa data yang ditambahkan ke folder F1 dan F2 setelah sinkronisasi pertama harus disalin selama sinkronisasi akhir.

Diagram menunjukkan bahwa folder F1 dan F2 dari sumber yang disalin ke tujuan selama sinkronisasi awal.
Angka 1. Folder F1 dan F2 dari sumber yang disalin ke tujuan selama sinkronisasi pertama.

Masalah
Selama sinkronisasi tambahan dan akhir, data inkremental dari folder F2 tidak disalin ke folder publik modern (seperti yang ditunjukkan pada gambar 2). Hal ini karena PFDB1 ditetapkan sebagai titik akhir. Batch statusis ditampilkan sebagai disinkronkan. Namun, semua data baru yang ditambahkan ke folder F2 setelah sinkronisasi pertama tidak disalin ke folder publik modern.

Selain itu, jika ada lebih baru folder yang ditambahkan ke PFDB2 setelah pertama sinkronisasi (folder F3 di gambar 2), konten map tersebut tidak akan disalin salah. (Ini benar meskipun F3 ditampilkan dalam hirarki).

Diagram menampilkan data inkremental ke folder F1 disalin dan perubahan ke folder F2 tidak disalin. Data dalam folder yang baru ditambahkan F3 tidak disalin tetapi folder yang ditampilkan dalam hirarki.
Gambar 2. Tambahan data ke folder F1 disalin, dan perubahan ke folder F2 tidak disalin. Meskipun data di folder baru ditambahkan F3 tidak disalin, folder muncul dalam hirarki.
Teknik pemecahan masalah
Sebelum Anda memulai migrasi batch, pastikan bahwa semua folder publik memiliki replika database folder publik yang akan ditetapkan sebagai sumber untuk migrasi. Selain itu, pastikan bahwa replikasi umum sinkron.

Penyelesaian untuk contoh skenario

Untuk mengatasi masalah ini, tambahkan replika folder F2 dan F3 di PFDB1, pastikan bahwa replikasi map publik sinkron, dan kemudian mulai batch migrasi. Hal ini memastikan bahwa data inkremental disalin (terlepas dari replika yang awalnya dituliskan ke).

Kami menyadari bahwa pemecahan masalah ini tidak akan bekerja untuk beberapa pelanggan karena ukuran map publik deployment. Jika Anda berada dalam situasi ini, kami sarankan Anda menunggu hingga masalah diperbaiki sebelum Anda menjalankan migrasi.

PERTANYAAN UMUM

Q:Saat masalah ini mulai terjadi?
A: masalah ini pertama kali diamati di Exchange Server 2013 1 Update kumulatif, Exchange Server 2016 RTM dan Exchange Online.

Q: data apa yang potensial saya kehilangan?
A: laporan di ibu, pencarian untuk "perubahan hierarki map dilaporkan di sumber," Pilih item "perubahan hierarki map dilaporkan di sumber" pertama yang dicantumkan, dan kemudian pilih tanggal dan waktu yang terkait dengan log. Data apa pun yang ditambahkan ke folder F2 atau folder baru yang ditambahkan ke PFDB2 setelah waktu ini akan hilang.

Q: saya masih memiliki saya Exchange Server 2007 atau Exchange Server 2010 database folder publik dalam keadaan terkunci karena kami bermigrasi ke Exchange Server 2013, Exchange Server 2016 atau Exchange Online. Dapat saya masih migrasi data hilang?
A: hanya manual kopi karbon data mungkin.

Q: migrasi saya mengambil minggu reachthe siap untuk menyelesaikan negara. Apakah saya harus mulai melalui?
A: tidak, Anda tidak perlu memulai ulang migrasi folder publik. Saat perbaikan selesai dan pembaruan diinstal pada server Anda (atau di server Exchange Online, jika Anda sedang migrasi ke Exchange Online), migrasi dapat diambil dari mana sekarang dan akan memindahkan data yang tersisa. Anda mungkin harus memulai ulang kumpulan migrasi. Namun, bila Anda melakukannya, proses terlihat perubahan dan tidak memulai lagi. Kumpulan migrasi dimulai melalui hanya jika Anda menghapus dan kemudian membuat ulang itu.

Peringatan: Artikel ini telah diterjemahkan secara otomatis

Properti

ID Artikel: 3161916 - Tinjauan Terakhir: 06/24/2016 08:00: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 KbMtid
Tanggapan