Perbaiki Tanggal Migrasi CloudM di Microsoft 365

CloudM Migrate adalah alat yang sering digunakan organisasi untuk memindahkan kotak surat dari Google Workspace, Exchange lokal, atau platform lain ke Microsoft 365. Migrasinya sendiri biasanya berjalan mulus. Kemudian seseorang membuka Outlook dan melihat sesuatu yang mengkhawatirkan: setiap email, ribuan di antaranya, menampilkan tanggal penerimaan yang sama.

Apa yang terjadi? Selama pengunggahan, jalur transportasi Exchange Online memperlakukan setiap pesan yang dimigrasi sebagai pengiriman baru. Sistem menambahkan header Received baru dengan stempel waktu pemrosesan saat ini dan menyetel properti PR_MESSAGE_DELIVERY_TIME sesuai. Properti inilah yang dirujuk oleh Outlook desktop, Outlook on the web, Outlook mobile, dan bahkan fitur Copilot Microsoft saat menampilkan tanggal. Berbeda dengan Google Workspace (di mana klien web dapat menyembunyikan masalah), Microsoft 365 menampilkan tanggal yang salah secara konsisten di mana pun.

Konsistensi inilah yang sebenarnya membuat versi M365 dari masalah ini begitu terlihat. Tidak ada jalan keluar "di browser berfungsi normal". Setiap pengguna, di setiap perangkat, di setiap aplikasi Microsoft 365 melihat tanggal migrasi. Tim IT biasanya menemukan masalah ini dalam hitungan jam setelah menyelesaikan migrasi CloudM, tetapi pada saat itu kerusakan sudah tertanam dalam metadata pesan di level server.

Dampaknya menjalar ke seluruh ekosistem M365. Outlook desktop, OWA, Outlook mobile, integrasi email Teams, Microsoft Search, semuanya menampilkan stempel waktu migrasi. Pengguna tidak dapat menghindari tanggal yang salah dengan beralih aplikasi. Bayangkan seorang pengacara mencari "email yang diterima antara Januari dan Maret 2023" sebagai persiapan litigasi. Pencarian tidak menghasilkan apa-apa, atau menghasilkan segalanya, tergantung kapan migrasi dilakukan. Ini bukan ketidaknyamanan kecil; ini adalah potensi kegagalan penemuan bukti.

Microsoft Purview (sebelumnya Compliance Center) dan eDiscovery Premium mengindeks pesan berdasarkan tanggal pengiriman yang terkorupsi. Pencarian konten berdasarkan rentang tanggal menghasilkan hasil yang tidak dapat diandalkan. Label retensi yang diterapkan secara otomatis berdasarkan usia pesan beroperasi pada garis waktu yang salah, yang berarti beberapa pesan dihapus terlalu cepat sementara yang lain dipertahankan tanpa batas. Kebijakan arsip otomatis di Outlook salah menghitung usia pesan secara menyeluruh. Bagi organisasi yang tunduk pada persyaratan retensi email regulasi, ini menciptakan celah kepatuhan yang bertahan sampai tanggal dikoreksi.