مقالات
آموزش رفع مشکل قطعی اکسچنج سرور پس از آپدیت ویندوز سرور | راهنمای کامل خطای RPC
به‌روزرسانی‌های امنیتی ویندوز سرور همواره برای ارتقای امنیت و پایداری زیرساخت ضروری هستند؛ اما در مواردی نصب پچ‌های جدید سیستم‌عامل می‌تواند سرویس‌های حیاتی سازمان مانند Microsoft Exchange Server را با اختلالات پیش‌بینی‌نشده و توقف کامل مواجه کند. در جدیدترین گزارش‌های فنی و تاییدیه رسمی مایکروسافت، مشخص شده است که بسته‌های امنیتی اخیر ویندوز سرور بدون دستکاری مستقیم سرویس اکسچنج، بستر ارتباطی پروتکل RPC را محدود کرده و باعث از کار افتادن سرویس‌های پیام‌رسانی سازمانی و وب‌میل می‌شوند.
در این مقاله تخصصی، به بررسی ریشه‌ای این آسیب‌پذیری، شناسایی علائم خرابی و ارائه راهکار عملیاتی مایکروسافت جهت بازیابی پایدار زیرساخت می‌پردازیم.
علائم بروز اختلال در سرورهای اکسچنج
اگر سرورهای ویندوز میزبان اکسچنج را به‌روزرسانی کرده باشید، معمولاً سرویس در ساعات اولیه پس از ریبوت به‌درستی کار می‌کند؛ اما با افزایش بار کاری و ترافیک کاربران در طول ساعات اداری، نشانه‌های زیر به مرور ظاهر می‌شوند:
- عدم دسترسی به پنل‌های کاربری و مدیریتی (OWA / ECP): کاربران هنگام تلاش برای باز کردن وب‌میل یا کنسول مدیریت با خطای زیر مواجه می‌شوند:
MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142) - ثبت مکرر Event ID 1006: در لاگ‌های Application سرور در بخش Event Viewer، رخدادهای متعددی با شناسه ۱۰۰۶ مرتبط با عدم اتصال به دیتابیس‌ها یا سرویس
MSExchangeIS (Information Store)ثبت می‌شود. - توقف یا تأخیر شدید ارسال ایمیل (Mail Flow Breakdown): ایمیل‌ها در صف ارسال (Queue) تجمع کرده و ترافیک جابه‌جایی پیام میان سرورهای Edge Transport و Mailbox متوقف می‌شود.
- ناهماهنگی و عدم پایداری در کلاسترهای DAG: نودهای عضو کلاستر Database Availability Group امکان حفظ پایدار ارتباطات RPC را از دست داده و کلاستر دچار وضعیت Unhealthy می‌شود.
کدام نسخه‌ها و بسته‌های به‌روزرسانی درگیر هستند؟
این ناسازگاری ناشی از بسته‌های تجمعی (Cumulative Updates) سیستم‌عامل ویندوز سرور است و تمام نسخه‌های محلی اکسچنج را به شرح جدول زیر درگیر می‌کند:
| نسخه سیستم‌عامل ویندوز سرور | شماره بسته به‌روزرسانی (KB) | نسخه‌های تحت تاثیر Exchange Server |
|---|---|---|
| Windows Server 2025 | KB5126646 | Exchange Server 2019 / Subscription Edition (SE) |
| Windows Server 2022 | KB5126655 | Exchange Server 2016 / 2019 / SE |
| Windows Server 2019 | KB5126651 | Exchange Server 2016 / 2019 |
| Windows Server 2016 | KB5126868 | Exchange Server 2016 |
ریشه فنی مشکل (Root Cause Analysis)
هسته مرکزی این مشکل در نحوه مدیریت اتصالات درون‌برنامه‌ای پروتکل RPC نهفته است:
- ایجاد سقف برای Endpoint Lookup: مایکروسافت در آپدیت‌های اخیر جهت مقاوم‌سازی سیستم در برابر حملات تزریق و سرریز بافر، یک سقف سخت‌گیرانه برای تعداد کانتکست‌های هم‌زمان ذخیره‌شده در سرویس RPC Endpoint Mapper تعریف کرده است.
- محدودیت پیش‌فرض ۵۱۲ کانتکست: مقدار پیش‌فرض این سقف روی ۵۱۲ کانتکست تنظیم شده است.
- حجم ترافیک سنگین در Exchange: کامپوننت‌های حیاتی اکسچنج (به‌ویژه Information Store، Replication Service و Transport) حجم بسیار بالایی از سشن‌های MAPI/RPC هم‌زمان ایجاد می‌کنند.
- رد درخواست‌ها (Drop): با ورود سرور به پیک کاری، تعداد کانتکست‌ها از مرز ۵۱۲ عبور کرده و Endpoint Mapper تمام درخواست‌های جدید را رد (Drop) می‌کند که منجر به قطع ارتباط نرم‌افزار اکسچنج با سیستم‌عامل می‌شود.
آموزش گام‌به‌گام رفع مشکل (راهکار رسمی مایکروسافت)
هشدار امنیتی: مایکروسافت صراحتاً اعلام کرده است که از حذف (Uninstall) یا بازگردانی (Rollback) آپدیت‌های ویندوز خودداری کنید؛ زیرا سرورها را در برابر باگ‌های بحرانی آسیب‌پذیر می‌کند. راهکار استاندارد، افزایش سقف مجاز از طریق رجیستری سیستم‌عامل است.
مرحله ۱: اعمال تغییرات در رجیستری ویندوز
روی تمام سرورهای اکسچنج (شامل سرورهای Mailbox و Edge Transport)، محیط خط فرمان Command Prompt یا PowerShell را با دسترسی ادمین (Run as administrator) باز کنید و یکی از روش‌های زیر را اجرا نمایید:
اجرا در Command Prompt:
reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /fاجرا در محیط PowerShell:
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Rpc" -Name "EpmapSavedContextCap" -Value 65536 -PropertyType DWord -Forceبرای بررسی اعمال صحیح مقدار، می‌توانید دستور زیر را اجرا کنید:
reg query "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCapمرحله ۲: راه‌اندازی مجدد سرور (Reboot)
برای اینکه پشته RPC سیستم‌عامل پارامترهای جدید را بارگذاری کند، راه‌اندازی مجدد سرور الزامی است.
نکته حیاتی برای محیط‌های دارای DAG:
پیش از ریبوت، حتماً نود مورد نظر را در وضعیت Maintenance Mode قرار دهید تا دیتابیس‌های اکتیو به‌صورت امن به سرور دیگر منتقل شوند:
Set-ServerComponentState -Identity "ServerName" -Component ServerWideOffline -State InActive -Requester Maintenance
Redirect-Message -Server "ServerName" -Target "TargetServerFQDN"
Suspend-ClusterNode -Name "ServerName"پس از ریبوت سرور و اطمینان از بالا آمدن کامل سرویس‌های ویندوزی و اکسچنج، سرور را با دستورات زیر از حالت نگهداری خارج کنید:
Resume-ClusterNode -Name "ServerName"
Set-ServerComponentState -Identity "ServerName" -Component ServerWideOffline -State Active -Requester Maintenanceنکات کلیدی برای محیط‌های سازمانی با ترافیک بالا
- افزایش ظرفیت در لودهای بسیار سنگین: در سازمان‌های کلان با ده‌ها هزار کاربر، چنانچه مقدار
65536مجدداً به مرز اشباع نزدیک شد، مایکروسافت اجازه داده است این متغیر را به مقادیر بالاتر نظیر131072افزایش داده و سرور را ریبوت کنید. - پایش لاگ‌ها در Event Viewer: در روزهای کاری پس از اعمال تغییرات، لاگ‌های Application و رخداد
Event ID 1006و طول صف ارسال ایمیل‌ها را به‌صورت منظم مانیتور کنید.
پرسش‌های متداول (FAQ)
آیا حذف آپدیت امنیتی ویندوز توصیه می‌شود؟
خیر؛ حذف Cumulative Update لایه‌های محافظتی سیستم را غیرفعال کرده و زیرساخت را در معرض آسیب‌پذیری‌های امنیتی قرار می‌دهد. افزایش مقدار رجیستری روش پایدار و پیشنهادی تیم مهندسی Exchange است.
آیا اجرای این دستور روی سرورهای Domain Controller یا فایل‌سرورها نیز لازم است؟
خیر؛ این مشکل منحصراً به دلیل ماهیت پردازش‌های سنگین پروتکل RPC در سرورهای مایکروسافت اکسچنج رخ می‌دهد و نیازی به اعمال آن روی دامین‌کنترلرها یا سایر سرورهای شبکه نیست.
آیا اجرای فوری ریبوت در ساعات اداری الزامی است؟
در صورتی که ارتباط کاربران با دیتابیس‌ها و OWA قطع شده باشد، ریستارت برای احیای سرویس اجتناب‌ناپذیر است. در غیر این صورت، می‌توانید کلید رجیستری را هم‌اکنون ایجاد کرده و ریبوت نهایی را در پنجره نگهداری (Maintenance Window) خارج از ساعات اداری زمان‌بندی کنید.