Perbaiki Tanggal Migrasi Exchange IMAP di Outlook

Alat migrasi IMAP bawaan Microsoft, yang tersedia melalui Exchange Admin Center dan PowerShell, seharusnya menjadi cara resmi dan aman untuk membawa kotak surat ke Exchange Online. Administrator memercayainya karena ini adalah alat pihak pertama Microsoft. Jadi ketika setiap email yang dimigrasi muncul di Outlook dengan tanggal migrasi, bukan tanggal asli, reaksinya biasanya adalah ketidakpercayaan.

Begini yang terjadi di balik layar. Migrasi IMAP Exchange mengunduh setiap pesan dari server sumber dan memasukkannya ke kotak surat Exchange tujuan melalui jalur transportasi. Jalur tersebut melakukan apa yang selalu dilakukan dengan email masuk: menambahkan header Received dengan stempel waktu pemrosesan saat ini dan menyetel properti PR_MESSAGE_DELIVERY_TIME agar sesuai. IMAP INTERNALDATE asli dari server sumber? Dibuang. Tidak dibawa. Bahkan tidak dicoba.

Hasilnya: setiap email di kotak surat yang dimigrasi, baik yang dikirim pada tahun 2012 maupun 2025, kini menampilkan tanggal migrasi di kolom "Received" Outlook. Dan inilah bagian yang paling membuat frustrasi administrator: dokumentasi migrasi Exchange hampir tidak menyebutkan perilaku ini. Anda mengetahuinya ketika 500 pengguna membuka Outlook mereka pada Senin pagi dan mengajukan tiket helpdesk tentang inbox mereka yang terlihat salah.

Kolom "Received" Outlook menampilkan stempel waktu migrasi untuk setiap email. Item terkirim juga menampilkannya, karena Exchange memproses pesan terkirim melalui jalur yang sama selama pengunggahan. Bahkan email terkait rapat (undangan, RSVP, pembatalan) membawa tanggal migrasi, yang mendistorsi kronologi interaksi kalender di masa lalu.

Tetapi kerusakan sesungguhnya ada pada pencarian dan otomatisasi. Bilah pencarian Outlook menggunakan indeks sisi server Exchange, yang merujuk pada waktu pengiriman yang terkorupsi. Pencarian berfilter tanggal mengembalikan hasil yang salah. AutoArchive, yang memindahkan atau menghapus email berdasarkan usia, mengira setiap pesan masih baru dan menolak mengarsipkan apa pun. Aturan yang dipicu oleh tanggal penerimaan gagal berfungsi. Aturan Conditional Formatting yang memberi kode warna pada email berdasarkan usia (praktik umum di kalangan pengguna berpengalaman yang menangani volume email tinggi) berhenti bekerja sepenuhnya. Bagi organisasi dengan 200 orang, itu berarti 200 inbox yang rusak, 200 pengalaman pencarian yang rusak, dan 200 orang yang tidak bisa lagi memercayai klien email mereka untuk menampilkan kapan sesuatu sebenarnya terjadi.