إذا كنت ما زلت تشغّل Exchange Server 2016 أو 2019 على أجهزتك الخاصة، فآخر شبكة أمان ستختفي في نهاية أكتوبر 2026. الدعم الأساسي والممتد انتهيا بالفعل في 14 أكتوبر 2025. وما أبقى بعض الخوادم محدَّثة منذ ذلك الحين هو برنامج مدفوع للتحديثات الأمنية الممتدة (ESU)، وقد قالت Microsoft بوضوح إنه لن يُمدَّد مرة أخرى.
هذه المقالة موجّهة إلى مسؤول الأنظمة الذي عليه أن يختار طريقًا خلال الأسابيع القليلة القادمة. تشرح ما تعنيه هذه التواريخ فعلًا، والخيارات الواقعية الثلاثة، وكيف يبدو الانتقال إلى بريد مفتوح المصدر ذاتي الاستضافة على أرض الواقع. وفي الجزء الأخير نعتمد على هجرة نفّذناها بأنفسنا. وتنبيه صريح منذ البداية: مشروعنا نقل جامعة من IceWarp، لا من Exchange. معظم ما تعلّمناه ينطبق هنا، وبعضه لا ينطبق، وسنقول أين.
التواريخ، من Microsoft مباشرة
- 14 أكتوبر 2025: نهاية دعم Exchange 2016 و2019. لا إصلاحات للأخطاء، ولا إصلاحات أمنية، ولا تحديثات للمناطق الزمنية، ولا دعم فني لمن ليس لديه عقد ESU (Microsoft Learn).
- الفترة الأولى من ESU: من أكتوبر 2025 حتى أبريل 2026.
- الفترة الثانية من ESU: من بداية مايو 2026 حتى نهاية أكتوبر 2026. وهي عقد منفصل: إذا اشتريت الفترة الأولى، فعليك شراء الفترة الثانية من جديد. تُباع عبر فريق حسابك لدى Microsoft، وتتطلب اتفاقية Enterprise Agreement، وليست مشمولة في Volume Licensing ولا في Software Assurance (مدونة فريق Exchange).
- بعد أكتوبر 2026: بحسب Microsoft، لن تصدر أي تحديثات أخرى لـ Exchange 2016/2019 بعد انتهاء أكتوبر 2026، حتى لو كان لديك عقد ESU للفترة الثانية، ولن يكون هناك أي تمديد آخر للجدول الزمني لبرنامج ESU (تذكير فريق Exchange).
وفي الأسئلة الشائعة للفترة الثانية تفصيلتان يسهل تفويتهما. تحديثات ESU تُشارَك بشكل خاص مع العملاء الدافعين فقط، وMicrosoft تقول إنها لا تلتزم بإصدار أي تحديث أمني خلال الفترة الثانية أصلًا. أي أن الجسر المدفوع نفسه لا يعطيك إصلاحات إلا إذا قرّرت Microsoft أن ثغرة ما خطيرة بما يكفي لإصدار إصلاح لها.
خادم Exchange مكشوف على الإنترنت ولا يتلقى تحديثات هو عبء خطير. فقد كان Exchange من أكثر منتجات الخوادم استهدافًا في السنوات الأخيرة. خطّط على أساس أن الخادم يجب أن يكون خارج الإنترنت، أو خارج Exchange 2016/2019، بحلول نوفمبر.
الطرق الثلاث الموجودة فعلًا
1. الترقية في المكان إلى Exchange Server Subscription Edition (SE)
هذا هو المسار المحلي الذي تقدّمه Microsoft نفسها. تبقى على Exchange، ويحتفظ مسؤولوك بخبراتهم، ويحتفظ Outlook بكل ميزاته الحالية. الثمن هو الترخيص: SE منتج باشتراك، فانتهى نموذج "اشترِه مرة وشغّله عشر سنوات". إذا كانت مشكلتك هي الموعد النهائي فقط، فهذه الخطوة الأقل مخاطرة، ولا يجب أن يثنيك عنها أي شيء مما يلي.
2. الانتقال إلى Microsoft 365 / Exchange Online
هذا ما توصي به معظم نتائج البحث حول هذا الموضوع، وهو الجواب الصحيح لكثير من المؤسسات. هناك من يحدّث الخوادم بدلًا منك، وأنت تدفع لكل مستخدم، إلى الأبد، ويعيش بريدك في سحابة Microsoft.
3. ترك منظومة البريد من Microsoft والانتقال إلى مصدر مفتوح ذاتي الاستضافة
هذا هو الخيار الذي تذكره معظم الأدلة في سطر واحد ثم تتجاوزه. وهو منطقي لنوع محدد من المؤسسات:
- لديك عدد من صناديق البريد يجعل التسعير لكل مستخدم رقمًا سنويًا كبيرًا.
- لديك متطلب صارم لموقع البيانات، أي أن البريد يجب أن يبقى داخل البلد أو على أجهزة تتحكّم بها، كما تشترط بعض الجهات الحكومية والتنظيمية.
إذا لم ينطبق عليك أيٌّ من ذلك، فالطريق الأول أو الثاني أبسط على الأرجح. بقية هذه المقالة عن الطريق الثالث، لأن تجربتنا المباشرة فيه.
ما فعلناه فعلًا: 10,000 صندوق بريد خارج منظومة تجارية
كانت جامعة حكومية تشغّل بريدها على IceWarp، وهي منظومة تجارية محلية للبريد والتعاون، وتدفع نحو 70,000 دولار سنويًا كتراخيص لـ 10,000 صندوق بريد. نقلنا كل ذلك إلى Stalwart Mail Server مفتوح المصدر. تكلفة البنية التحتية على الحجم نفسه أصبحت أقل من 4,000 دولار سنويًا. التفصيل الكامل للتكاليف موجود في دراسة الحالة الخاصة بالتكلفة، وأسباب استمرار المؤسسات في اختيار الاستضافة الذاتية في 2026 موجودة في هذه المقالة السابقة. لن نكرّر أيًّا منهما هنا.
النشر ممل عن قصد. يعمل على خادم واحد: Stalwart Community (مثبَّت على خط الإصدار v0.16) مع PostgreSQL كمخزن بيانات، وMinIO لتخزين الملفات، وNATS، وكلها في Docker، مع نسخة احتياطية يومية تُختبر استعادتها. تأتي الحسابات من LDAP/Active Directory الموجود لدى الجامعة بدل إنشائها واحدًا واحدًا. وهذه النقطة الأخيرة مهمة جدًا إذا كنت تغادر Exchange، لأن دليلك موجود أصلًا في AD.
ما الذي ينتقل معك من عالم Exchange
- الدليل. يستطيع Stalwart قراءة الحسابات من LDAP/AD. يبقى المستخدمون والمجموعات وكلمات المرور في مكانها.
- عملاء البريد عبر البروتوكولات القياسية. IMAP وSMTP وPOP3 تعمل مع Outlook وThunderbird وApple Mail وتطبيقات الهاتف. وكان التوافق مع Outlook وThunderbird والهواتف أحد معايير القبول الصريحة لدينا.
- التقويمات وجهات الاتصال. CalDAV وCardDAV مدعومان، فللتقويمات ودفاتر العناوين مكان قياسي.
- بريد سريع عبر الويب. يتحدّث Stalwart بروتوكول JMAP، وهو بروتوكول حديث مصمَّم لعملاء الويب. بنينا عليه بريدنا عبر الويب، وهو أسرع بشكل ملحوظ من البريد عبر الويب المبني على IMAP. وكتبنا عن السبب في هذه المقالة عن JMAP.
ما الذي لا ينتقل معك (اقرأ هذا الجزء مرتين)
- Exchange ActiveSync. لا يطبّق Stalwart Community بروتوكول EAS. في خطة مشروعنا كان ActiveSync خارج النطاق، مع ملاحظة أننا سنعيد النظر في محرّك البريد إذا أظهرت التجربة الأولية أن المستخدمين يعتمدون عليه. إذا كانت هواتفك وإعدادات Outlook لديك تعتمد على ActiveSync اليوم، فاختبر هذا أولًا، ولا تكتشفه يوم الانتقال.
- ميزات Outlook الموجودة فقط عبر MAPI/EWS. Outlook عبر IMAP تجربة مختلفة عن Outlook مع Exchange. تفويض صناديق البريد المشتركة، والمجلدات العامة، وسلوك معلومات التوفّر وقاعات الاجتماعات هي الفجوات المعتادة. اجمع الميزات التي يعتمد عليها مستخدموك فعلًا قبل أن تعد أحدًا بانتقال مطابق.
- بعض وسائل الراحة الإدارية. في إصدار Community، جزء من إدارة الإعدادات والمقاييس المدمجة موجود خلف ترخيص Enterprise من Stalwart. استبدلنا جانب المقاييس بـ Prometheus وGrafana. خصّص وقتًا لهذا النوع من أعمال الربط.
- هاتف المناوبة. الاستضافة الذاتية تعني أنك مسؤول عن وصول الرسائل، وتصفية البريد المزعج، وشهادات TLS، والنسخ الاحتياطية. لن يصلح أحد غيرك المشكلة في الثالثة فجرًا.
تفاصيل الهجرة التي أنقذتنا
تعامل مع أرشيف البريد كشيء مقدّس. كانت قاعدتنا ألّا يُلمس أي صندوق بريد دون نسخة احتياطية، وألّا يُعدَّل المصدر أبدًا. نُسخ الأرشيف بأدوات تصدير قائمة على الملفات، ثم بمزامنة تزايدية أسبوعية تضيف فقط ولا تحذف أبدًا. وبهذا لا يمكن لرسالة حُذفت بالخطأ في النظام القديم أن تمحو نسختها في النظام الجديد.
تحقّق بمعرّف الرسالة (Message-ID)، لا بعدد الملفات. المجلد الذي يحتوي العدد نفسه من الملفات في الطرفين قد تنقصه رسائل وتتكرّر فيه أخرى. معرّفات Message-ID الفريدة هي ما يخبرك أن الأرشيف وصل سليمًا.
ابدأ بقسم واحد تجريبي. هذا هو الدرس الذي نؤكد عليه أكثر من غيره. نقل مجموعة صغيرة أولًا كشف أخطاء DNS وDKIM بينما كانت بضعة صناديق فقط متأثرة. لم تكن أيٌّ من المشكلات غريبة؛ كانت من النوع الذي لا تلاحظه إلا عندما يمرّ بريد حقيقي عبر السجلات الجديدة، واكتشافها مع عشرين مستخدمًا أفضل بكثير من اكتشافها مع عشرة آلاف.
اضبط DNS والسمعة قبل الانتقال الكبير. يجب أن تكون سجلات SPF وDKIM وDMARC وسجل PTR صحيح لعنوان IP المُرسِل كلها في مكانها. وإذا كان خادمك الجديد يرسل من عنوان IP بلا تاريخ، فتوقّع أن تحتاج إلى تسخينه تدريجيًا. عنوان IP بارد يبدأ فجأة بإرسال بريد جامعة كاملة سيُبطَّأ أو يُرمى في البريد المزعج لدى المزوّدين الكبار.
فكّر في استعادة الدخول. على خادم بريدك الخاص، عبارة "سنرسل لك رابط إعادة التعيين بالبريد" حلقة مفرغة. أضفنا تسجيل الدخول برمز مرور لمرة واحدة عبر الرسائل النصية مع المصادقة الثنائية، وعلى هذا الحجم كان تأثيره على تبنّي النظام في اليوم الأول أكبر من أي ميزة في البريد عبر الويب. وأضفنا أيضًا تنبيهًا اختياريًا من البريد إلى الرسائل النصية للموظفين الذين لا يجلسون أمام صندوق الوارد طوال اليوم.
إذا كان لديك خمسة أسابيع، لا خمسة أشهر
هجرة بضعة آلاف من صناديق البريد بين منصّتين مختلفتين ليست شيئًا يُستعجل قبل 31 أكتوبر. إذا لم تستطع الانتهاء في الوقت، فالترتيب الصادق للخطوات هو:
- أمّن خوادم Exchange أولًا. أي ترقية في المكان إلى Exchange SE، أو ESU للفترة الثانية إذا كان لديك، أو على الأقل إخراج OWA ونقاط Exchange الأخرى من الإنترنت العام.
- أجرِ جردًا: عدد صناديق البريد، والحجم الإجمالي، ومن يستخدم ActiveSync، وأي صناديق مشتركة ومجلدات عامة مهمة، وأي تطبيقات تمرّر البريد عبر Exchange.
- أنشئ المنصة الجديدة بجانب القديمة، وانقل قسمًا تجريبيًا واحدًا.
- أصلح ما تكشفه التجربة، ثم انقل قسمًا بعد قسم مع تشغيل المزامنة التزايدية طوال الوقت.
- غيّر سجلات MX فقط بعد أن تعمل التجربة دون مشكلات لفترة.
سواء انتهيت إلى Exchange SE أو Microsoft 365 أو خوادمك الخاصة، فالموعد النهائي نفسه غير قابل للتفاوض. ترك خادم Exchange غير محدَّث على الإنترنت في نوفمبر 2026 هو الخيار الوحيد الخاطئ بوضوح.
بعد الانتقال، أول اختبار حقيقي للخادم الجديد هو التسليم، لذا راجع ما الذي يجب فحصه عند ظهور خطأ Outlook 550 5.7.515 قبل تعديل DNS.
