English
Francais
Deutsch
Espanol
Portugues
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Turkce
Ellinika
Russkij
Polski
Cestina
Ukrajinska
Magyar
Romana
Bulgarski
Hrvatski
Srpski
Slovencina
Slovenscina
Lietuviu
Latviesu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
إصلاح تواريخ ترحيل BitTitan MigrationWiz في Google Workspace
لماذا يفسد ترحيل BitTitan تواريخ البريد في Google Workspace
يرفع BitTitan MigrationWiz الرسائل إلى Google Workspace عبر Gmail API أو IMAP. أثناء الرفع، تسجل بنية البريد في Google الطابع الزمني للإدراج كـ INTERNALDATE للرسالة. يضيف BitTitan أيضا رأس Received مؤرخا بتاريخ الترحيل. يبقى رأس Date الأصلي داخل نص الرسالة سليما، لكن INTERNALDATE يضيع ويستبدل بالطابع الزمني للترحيل.
المثير أن Google Workspace يتعامل مع هذا بشكل مختلف عن المنصات الأخرى. تقرأ واجهة Gmail على الويب رأس Date للعرض، فتبدو الرسائل صحيحة التاريخ عند مشاهدتها في المتصفح. لكن IMAP INTERNALDATE مضبوط بشكل دائم على تاريخ الترحيل. أي عميل IMAP يتصل بحساب Google Workspace هذا - سواء Outlook أو Thunderbird أو Apple Mail - يقرأ INTERNALDATE ويعرض تاريخ الترحيل بدلا من التاريخ الأصلي.
ينتج عن هذا انقسام محير. نفس الرسالة تظهر بالتاريخ الصحيح في Gmail على الويب لكن بالتاريخ الخاطئ في Outlook المتصل بنفس الحساب. يتلقى مسؤولو تقنية المعلومات بلاغات متناقضة. "رسائلي سليمة." "رسائلي كلها خاطئة." كلا المستخدمين على حق - لأنهما يستخدمان عملاء مختلفين.
تخيل أنك رحلت 85 صندوق بريد من Exchange المحلي إلى Google Workspace باستخدام MigrationWiz. نصف فريقك يستخدم واجهة Gmail على الويب ولا يلاحظ أي مشكلة. النصف الآخر يستخدم Outlook عبر IMAP ويفتح 85 بلاغ دعم في صباح واحد. يستغرق تشخيص المشكلة ساعات لأنها غير مرئية في لوحة تحكم MigrationWiz وفي لوحة إدارة Gmail.
كيف يؤثر ذلك على مستخدمي Google Workspace
تضرب مشكلة التاريخ المزدوج بأقصى قوة في المؤسسات التي يصل فيها المستخدمون إلى البريد عبر عملاء متعددين. Gmail على الويب يبدو سليما. Outlook يبدو معطلا. Apple Mail يبدو معطلا. عملاء IMAP على الهاتف يبدون معطلين. واجهة الويب وحدها هي التي تخفي المشكلة.
لكن الأمر أعمق من مجرد العرض. يشير Google Vault (حل الامتثال والأرشفة المستخدم للحجز القانوني واكتشاف المستندات الإلكتروني) إلى INTERNALDATE في بعض العمليات. قد تعيد عمليات البحث القانونية المستندة إلى التاريخ نتائج غير دقيقة. أدوات النسخ الاحتياطي التي تتصل عبر IMAP من جهات خارجية تؤرشف تاريخ الترحيل كتاريخ للرسالة مما ينشئ أخطاء دائمة في سجلات النسخ الاحتياطي. حتى أمر IMAP SEARCH DATE في Gmail نفسه يستخدم INTERNALDATE بدلا من رأس Date.
يعالج Redate.io هذا من خلال خط معالجة متعدد المراحل لتحليل الرؤوس يصحح INTERNALDATE ورؤوس الترحيل دون المساس بمحتوى الرسالة أو المرفقات. تبقى تجربة Gmail على الويب (التي كانت تعرض التواريخ بشكل صحيح أصلا) كما هي، بينما تبدأ عملاء IMAP وVault وأدوات النسخ الاحتياطي في قراءة التاريخ الصحيح. تضمن مطابقة أنماط بصمات أدوات الترحيل استهداف رؤوس BitTitan المحقونة فقط.
الأسئلة الشائعة
لماذا تظهر الرسائل بتاريخ صحيح في Gmail لكن خاطئ في Outlook بعد ترحيل BitTitan؟
يستخدم عميل Gmail على الويب رأس Date من الرسالة الأصلية الذي يحافظ عليه BitTitan. يقرأ Outlook قيمة IMAP INTERNALDATE التي تستبدل أثناء الترحيل. يصحح Redate.io INTERNALDATE حتى تعرض جميع العملاء التاريخ الأصلي بشكل متسق.
هل يتطلب Redate.io كلمات مرور المستخدمين الفرديين في Google Workspace؟
لا. يتصل Redate.io من خلال تفويض على مستوى النطاق في Google Workspace باستخدام حساب خدمة. يمكن للمسؤولين إصلاح التواريخ عبر جميع صناديق البريد دون جمع بيانات اعتماد فردية.
هل سيغير إصلاح INTERNALDATE طريقة ظهور الرسائل في واجهة Gmail على الويب؟
لا. تعرض واجهة Gmail على الويب بالفعل رأس Date الصحيح. يصحح Redate.io INTERNALDATE حتى تعرض عملاء IMAP مثل Outlook وApple Mail أيضا التاريخ الأصلي. تبقى تجربة Gmail على الويب متطابقة.
هل يمكن لـ Redate.io إصلاح صناديق البريد التي تستخدم Outlook فقط أم يجب معالجة الجميع؟
يمكن لـ Redate.io استهداف صناديق بريد محددة. يختار المسؤولون الحسابات المراد معالجتها، لذا يمكن إصلاح صناديق البريد التي يعتمد مستخدموها على عملاء IMAP مثل Outlook أو Thunderbird فقط.