اگر هنوز Exchange Server 2016 یا 2019 را روی سرورهای خودتان اجرا میکنید، آخرین تور ایمنی در پایان اکتبر ۲۰۲۶ (اواخر مهر و اوایل آبان ۱۴۰۵) برداشته میشود. پشتیبانی اصلی این دو نسخه از ۱۴ اکتبر ۲۰۲۵ تمام شده. چیزی که از آن موقع بعضی سرورها را بهروز نگه داشته، یک برنامهی پولی به اسم Extended Security Update یا ESU بوده، و مایکروسافت صریح گفته که این برنامه دیگر تمدید نمیشود.
این نوشته برای مدیر فنیای است که باید در همین چند هفته یک مسیر را انتخاب کند: تاریخها دقیقاً چه معنایی دارند، سه گزینهی واقعی کداماند، و مهاجرت به ایمیل متنباز خودمیزبان در عمل چه شکلی دارد. برای بخش آخر به پروژهای تکیه میکنیم که خودمان انجام دادهایم. یک توضیح صادقانه از همین اول: پروژهی ما یک دانشگاه را از IceWarp جدا کرد، نه از Exchange. بیشتر درسها قابل انتقال است، بعضی نه، و جایش را میگوییم.
تاریخها، از زبان خود مایکروسافت
- ۱۴ اکتبر ۲۰۲۵: پایان پشتیبانی Exchange 2016 و 2019. بدون قرارداد ESU دیگر رفع باگ، وصلهی امنیتی، بهروزرسانی منطقهی زمانی و پشتیبانی فنی وجود ندارد (Microsoft Learn).
- دورهی اول ESU: اکتبر ۲۰۲۵ تا آوریل ۲۰۲۶.
- دورهی دوم ESU: از ابتدای مه ۲۰۲۶ تا پایان اکتبر ۲۰۲۶. قرارداد جداگانهای است؛ اگر دورهی اول را خریده باشید هم باید دوباره بخرید. فقط از طریق تیم حساب مایکروسافت و با قرارداد Enterprise Agreement فروخته میشود و جزو Volume Licensing یا Software Assurance نیست (وبلاگ تیم Exchange).
- بعد از اکتبر ۲۰۲۶: به نقل از خود مایکروسافت، با پایان اکتبر ۲۰۲۶ هیچ بهروزرسانی دیگری برای Exchange 2016/2019 منتشر نمیشود، حتی برای کسانی که ESU دورهی دوم دارند، و برنامه هم تمدید نخواهد شد (یادآوری تیم Exchange).
دو نکته در پرسشوپاسخ دورهی دوم راحت از چشم میافتد. وصلههای ESU فقط بهصورت خصوصی به مشتریان پولی داده میشود، و مایکروسافت گفته تعهدی به انتشار هیچ وصلهای در دورهی دوم ندارد. یعنی حتی این پل پولی هم فقط وقتی کمک میکند که مایکروسافت آسیبپذیریای را آنقدر جدی بداند که برایش وصله بدهد.
برای سازمانهای ایرانی هم یک واقعیت دیگر هست: خرید ESU از طریق قرارداد Enterprise با مایکروسافت عملاً در دسترس نیست. پس برای بیشتر سرورهای Exchange داخل کشور، پایان پشتیبانی همان ۱۴ اکتبر ۲۰۲۵ بوده است.
سرور Exchange که به اینترنت وصل است و وصله نمیگیرد، ریسک بزرگی است؛ Exchange در چند سال اخیر یکی از پرحملهترین محصولات سروری بوده. برنامهتان را طوری بچینید که تا آبان، سرور یا از اینترنت جدا شده باشد یا دیگر Exchange 2016/2019 نباشد.
سه مسیری که واقعاً وجود دارد
۱. ارتقای درجا به Exchange Server Subscription Edition (SE)
مسیر رسمی مایکروسافت برای ماندن روی سرور خودتان. روی Exchange میمانید، تیم فنی همان مهارتها را به کار میگیرد و Outlook همهی قابلیتهای فعلی را حفظ میکند. هزینهاش در مدل مجوز است: SE اشتراکی است و مدل «یکبار بخر و ده سال استفاده کن» دیگر وجود ندارد.
۲. انتقال به Microsoft 365 یا Exchange Online
چیزی که بیشتر نتایج جستوجو پیشنهاد میکنند و برای خیلی از سازمانها هم جواب درست است: کس دیگری سرور را وصله میکند، شما برای هر کاربر، برای همیشه، پول میدهید و ایمیلها در ابر مایکروسافت نگه داشته میشوند. برای سازمانهای داخل ایران، به دلیل تحریم و پرداخت ارزی، این مسیر معمولاً عملی نیست.
۳. خروج کامل از پشتهی ایمیل مایکروسافت به سمت متنباز خودمیزبان
گزینهای که اغلب راهنماها فقط در یک خط اسمش را میآورند. برای این شرایط منطقی است:
- تعداد صندوقها آنقدر زیاد است که قیمتگذاری به ازای هر کاربر به رقم سالانهی بزرگی میرسد.
- الزام جدی به حاکمیت داده دارید؛ یعنی ایمیل باید داخل کشور یا روی سختافزار خودتان بماند.
- اشتراک دلاری، علاوه بر قیمت، ریسک ارز و تحریم دارد که مدیر مالی کنترلی رویش ندارد.
اگر هیچکدام از اینها دربارهی شما صدق نمیکند، مسیر ۱ یا ۲ احتمالاً سادهتر است. بقیهی این نوشته دربارهی مسیر ۳ است، چون تجربهی دستاول ما آنجاست.
کاری که واقعاً کردیم: جدا کردن ۱۰ هزار صندوق از یک سامانهی تجاری
دانشگاه لرستان ایمیلش را روی IceWarp اجرا میکرد؛ یک سامانهی تجاری ایمیل و همکاری که روی سرور خود سازمان نصب میشود. هزینهی مجوز آن برای ۱۰ هزار صندوق حدود ۷۰ هزار دلار در سال بود. کل سیستم را به Stalwart Mail Server منتقل کردیم که متنباز است، و هزینهی زیرساخت در همان مقیاس حالا کمتر از ۴ هزار دلار در سال است. جزئیات هزینه در مطالعهی موردی هزینه آمده و دلیلهای انتخاب ایمیل خودمیزبان در ۲۰۲۶ در این نوشتهی قبلی؛ اینجا تکرارشان نمیکنیم.
استقرار عمداً ساده است: یک سرور، 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 سریعتر است؛ دلیلش را اینجا نوشتهایم.
چه چیزهایی منتقل نمیشود (این بخش را دو بار بخوانید)
- Exchange ActiveSync: نسخهی Community از Stalwart پروتکل EAS را پیاده نکرده است. در برنامهی پروژهی خودمان ActiveSync خارج از محدوده بود، با این یادداشت که اگر آزمایش اولیه نشان دهد کاربران به آن وابستهاند، موتور ایمیل را بازنگری کنیم. اگر گوشیها و Outlook سازمان شما امروز به ActiveSync تکیه دارند، اول همین را آزمایش کنید؛ نگذارید روز مهاجرت کشفش کنید.
- قابلیتهایی از Outlook که فقط روی MAPI/EWS هست: Outlook روی IMAP تجربهی متفاوتی از Outlook روی Exchange است. تفویض صندوق مشترک، public folderها، و رفتار free/busy و اتاقهای جلسه معمولاً همانجاییاند که کم میآید. قبل از اینکه به کسی قول مهاجرت «بدون تفاوت» بدهید، فهرست قابلیتهایی را که کاربران واقعاً استفاده میکنند جمع کنید.
- بخشی از راحتیهای مدیریتی: در نسخهی Community، بخشی از مدیریت تنظیمات و متریکهای داخلی پشت مجوز Enterprise است. ما بخش متریک را با Prometheus و Grafana جایگزین کردیم. برای اینجور کارهای تکمیلی وقت بگذارید.
- کسی که ساعت ۳ صبح بیدار میشود: در خودمیزبانی، تحویلپذیری ایمیل، فیلتر اسپم، گواهی TLS و پشتیبانگیری مسئولیت خودتان است.
روشهای مهاجرتی که نجاتمان داد
تاریخچهی ایمیل را مقدس بدانید. قانون ما این بود که هیچ صندوقی بدون پشتیبان دست نخورد و منبع هیچوقت تغییر نکند. تاریخچه با ابزارهای مبتنی بر فایل منتقل شد و بعد یک همگامسازی هفتگی افزایشی اجرا میشد که فقط اضافه میکند و هیچوقت حذف نمیکند؛ اینطوری پیامی که روی سیستم قدیم اشتباهی پاک شده، نسخهی روی سیستم جدید را از بین نمیبرد.
با Message-ID راستیآزمایی کنید، نه با شمردن فایلها. پوشهای که در دو طرف تعداد فایل برابر دارد هنوز ممکن است پیامهایی را کم داشته باشد و از بعضی دیگر دو نسخه. Message-IDهای یکتا چیزی است که نشان میدهد تاریخچه سالم رسیده.
اول یک واحد را آزمایشی منتقل کنید. این مهمترین توصیهی ماست. انتقال یک گروه کوچک، اشتباههای DNS و DKIM را وقتی بیرون آورد که فقط چند صندوق درگیر بودند. هیچکدام عجیب نبودند؛ از آن مشکلاتی بودند که فقط وقتی ایمیل واقعی از رکوردهای جدید رد میشود دیده میشوند، و خیلی بهتر است با بیست کاربر پیدا شوند تا با ده هزار نفر.
DNS و اعتبار ارسال را قبل از مهاجرت اصلی درست کنید. SPF، DKIM، DMARC و رکورد PTR درست برای IP ارسالکننده همه لازماند. اگر سرور جدید از IP بدون سابقه ایمیل میفرستد، باید آن را تدریجی گرم کنید؛ IP سردی که ناگهان حجم ایمیل یک دانشگاه را بفرستد، از طرف سرویسدهندههای بزرگ محدود یا به پوشهی اسپم فرستاده میشود.
به بازیابی ورود فکر کنید. روی سرور ایمیل خودتان، «لینک بازیابی را ایمیل میکنیم» یک دور باطل است. ما ورود با رمز یکبارمصرف پیامکی و احراز هویت دومرحلهای اضافه کردیم و در این مقیاس، اثرش روی پذیرش روز اول از هر قابلیت وبمیل بیشتر بود. یک اعلان پیامکی اختیاری هم برای ایمیلهای جدید گذاشتیم، برای کارکنانی که مدام صندوقشان را چک نمیکنند.
اگر پنج هفته وقت دارید، نه پنج ماه
مهاجرت چند هزار صندوق به یک پلتفرم دیگر کاری نیست که بشود قبل از ۳۱ اکتبر با عجله تمامش کرد. اگر به موقع نمیرسید، ترتیب درست این است:
- اول خود سرورهای Exchange را امن کنید: ارتقای درجا به Exchange SE، یا ESU دورهی دوم اگر از قبل دارید، یا دستکم برداشتن OWA و بقیهی درگاههای Exchange از اینترنت عمومی.
- سیاهه بگیرید: تعداد و حجم صندوقها، اینکه چه کسانی از ActiveSync استفاده میکنند، کدام صندوقهای مشترک و public folderها مهماند و کدام برنامهها ایمیلشان را از طریق Exchange میفرستند.
- پلتفرم جدید را کنار قبلی راه بیندازید و یک واحد آزمایشی را منتقل کنید.
- مشکلاتی را که آزمایش نشان داد رفع کنید، بعد واحد به واحد مهاجرت کنید و در تمام این مدت همگامسازی افزایشی روشن باشد.
- رکوردهای MX را فقط وقتی عوض کنید که واحد آزمایشی مدتی بدون مشکل کار کرده باشد.
چه در نهایت به Exchange SE برسید، چه به Microsoft 365، چه به سرورهای خودتان، خود مهلت قابل مذاکره نیست. رها کردن یک سرور Exchange بیوصله روی اینترنت در آبان ۱۴۰۵ تنها گزینهای است که قطعاً غلط است.
روایت کامل پروژهی دانشگاه لرستان، از جمله اینکه ۱۰ هزار کاربر واقعی چه چیزهایی را متوجه شدند و چه چیزهایی را نه، اینجاست.