إصلاح تواريخ ترحيل imapsync في Microsoft 365
لماذا يكسر imapsync تواريخ البريد في Microsoft 365
يبدو الترحيل إلى Microsoft 365 باستخدام imapsync منطقيا. مجاني وقابل للأتمتة ويتعامل مع عمليات نقل IMAP إلى IMAP بكفاءة في معظم السيناريوهات. لكن Exchange Online ليس "معظم السيناريوهات."
بوابة IMAP في Exchange Online هي طبقة توافق مثبتة فوق نظام مصمم حول EWS وMAPI. عندما يدفع imapsync رسالة عبر هذه البوابة باستخدام بروتوكول نقل البريد القياسي تدخل الرسالة نظام النقل الكامل في Exchange Online - نفس النظام الذي يعالج البريد الوارد من الإنترنت. يضيف هذا النظام رؤوس النقل ويشغل فحوصات منع فقدان البيانات ويطبق قواعد الامتثال ويختم رأس Received جديدا باللحظة الدقيقة لوصول الرسالة إلى الخادم. علم --syncinternaldates؟ لا يبالي نظام النقل في Exchange Online به. يستبدل INTERNALDATE ليطابق الطابع الزمني للتسليم.
هذا ليس خطأ تخطط Microsoft لإصلاحه. هكذا تعمل بنية Exchange Online. يعامل نظام النقل كل APPEND كتسليم رسالة جديدة ولا استثناء. سواء رحلت 500 رسالة أو 500,000، كل واحدة تحصل على نفس تاريخ الترحيل مختوما في رؤوسها وبياناتها الوصفية.
تخيل أن تخبر مدير تقنية المعلومات أن الترحيل الذي نفذته خلال عطلة نهاية الأسبوع سطح للتو 6 سنوات من تاريخ البريد في تاريخ واحد. هذا هو الواقع الذي يواجهه المسؤولون بعد ترحيل imapsync إلى Microsoft 365. وعلى عكس Google Workspace (حيث يمكن لعميل Gmail على الويب إخفاء المشكلة) يعرض Microsoft 365 التاريخ الخاطئ في كل مكان - Outlook للكمبيوتر وOWA وOutlook للهاتف وMicrosoft Search. لا يوجد مهرب من جانب العميل.
كيف تضر التواريخ التالفة بعمليات Microsoft 365
في Microsoft 365 الضرر شامل ومرئي. كل عميل - Outlook لنظام Windows وOutlook لنظام Mac وOWA وOutlook للهاتف على iOS وAndroid - يعرض الطابع الزمني للترحيل. لا يستطيع المستخدمون الترتيب حسب التاريخ ولا إيجاد الرسائل زمنيا ولا الوثوق بنتائج البحث المصفاة حسب نطاق التاريخ. صندوق بريد فيه 80,000 رسالة تعرض جميعها "12 نوفمبر 2024" معطل وظيفيا للعمل اليومي.
تداعيات الامتثال أسوأ. يفهرس Exchange Online Protection وMicrosoft Purview وسياسات الاحتفاظ جميعها الطابع الزمني للتسليم التالف. سياسة احتفاظ مضبوطة لحذف الرسائل الأقدم من 7 سنوات تعمل على التاريخ الخاطئ - مما يعني أن رسائل 2018 التي يجب أن تقترب من الحذف تبدو الآن وكأنها من 2024. تواجه المؤسسات الخاضعة للائحة حماية البيانات العامة (GDPR) أو HIPAA أو لوائح هيئة الأوراق المالية تعرضا تنظيميا حقيقيا عندما لا يمكن الوثوق بالاحتفاظ بالبريد. وإذا جاء طلب حجز قانوني لـ "جميع رسائل الربع الثالث 2023" فإن التواريخ التالفة تعني أن Purview لا يعيد شيئا - لأن حسب البيانات الوصفية لا توجد رسائل من تلك الفترة.
يتصل Redate.io بـ Microsoft 365 ويطبق تحليل سلسلة الرؤوس وإعادة بناء بيانات التاريخ الوصفية على كل رسالة متأثرة. تحدد مطابقة الأنماط عبر بصمات ترحيل imapsync المحددة رؤوس Received المحقونة أثناء الترحيل مقابل تلك التي تنتمي لسلسلة التسليم الأصلية. تصحح كل رسالة ويتم التحقق منها بشكل فردي مع حفظ النسخة الأصلية في مجلد نسخ احتياطي. تتعامل خطة المؤسسات مع صناديق بريد حتى 100,000 رسالة ويمكن للمسؤولين معالجة صناديق بريد متعددة من لوحة تحكم واحدة.
الأسئلة الشائعة
لماذا لا يعمل --syncinternaldates مع Microsoft 365؟
يعالج Exchange Online كل رفع عبر IMAP من خلال نظام النقل الخاص به الذي يعامل الرسالة كتسليم جديد ويستبدل INTERNALDATE. يضيف النظام أيضا رأس Received خاصا به بالطابع الزمني للرفع. هذه سلوكيات من جانب الخادم لا يمكن لأي علم في imapsync منعها.
هل كانت أداة ترحيل تجارية ستتجنب هذه المشكلة؟
معظم الأدوات التجارية (BitTitan MigrationWiz وCloudM وQuest) تنتج نفس تلف التواريخ لأن السبب الجذري هو نظام النقل في Exchange Online وليس أداة الترحيل نفسها. يصلح Redate.io التواريخ بغض النظر عن الأداة المسببة للمشكلة.
هل يمكن لـ Redate.io معالجة صناديق بريد Microsoft 365 متعددة في آن واحد؟
نعم. يدعم Redate.io معالجة صناديق البريد بالجملة لمستأجري Microsoft 365. يتصل المسؤولون مرة واحدة عبر Azure AD ويمكنهم فحص وإصلاح صناديق البريد عبر المؤسسة من لوحة تحكم واحدة.
كم يستغرق إصلاح صندوق بريد Microsoft 365 مرحل بـ imapsync؟
تعتمد سرعة المعالجة على حجم صندوق البريد وحدود معدل API في Microsoft. صندوق بريد نموذجي يحتوي على 30,000 رسالة يستغرق بين 4 و8 ساعات. يتعامل Redate.io مع تقييد المعدل تلقائيا ويستأنف من حيث توقف إذا انقطع.