إتقان الطبقات الخمس لبيئة Exchange الهجينة فيما وراء المعالج

By Mirko Peters · 2026-08-11

إتقان الطبقات الخمس لبيئة Exchange الهجينة فيما وراء المعالج مرحبًا بعودتكم، أيها المختصون في البودكاست وتقنية المعلومات! عند إعداد بيئة Exchange هجينة أو إدارتها، يسهل الاعتماد كليًا على معالج تكوين Exchange الهجين (HCW). تشغّله، وتراقب تحوّل الحالة إلى اللون الأخضر، وتفترض أن رحلتك إلى السحابة قد اكتملت. لكن كما سيخبرك أي مسؤول متمرس، فإن المعالج الأخضر لا يدل إلا على أن النص البرمجي الأولي قد ا

Automatically translated with AI from the original post. Read the English original

مرحبًا بعودتكم، أيها المختصون في البودكاست وتقنية المعلومات! عند إعداد بيئة Exchange هجينة أو إدارتها، يسهل الاعتماد كليًا على معالج تكوين Exchange الهجين (HCW). تشغّله، وتراقب تحوّل الحالة إلى اللون الأخضر، وتفترض أن رحلتك إلى السحابة قد اكتملت. لكن كما سيخبرك أي مسؤول متمرس، فإن المعالج الأخضر لا يدل إلا على أن النص البرمجي الأولي قد انتهى بنجاح. إنه لا يتحقق من واقع عملك اليومي.

في أحدث حلقة لنا من البودكاست، Maintain Hybrid Exchange Beyond the Configuration Wizard، نتعمق في الأسباب التي تجعل الاعتماد على المعالج وحده وصفةً لإخفاقات صامتة في تدفق البريد، وتعطّل تقاويم المعلومات عن التوفر، وتجارب مستخدم محبطة. ولإتقان بيئتك الهجينة حقًا، عليك فهم الطبقات الحرجة الخمس التي تحافظ على سلامة بنيتك التحتية وإدارتها.

ملخص سريع

تعمل البيئة الهجينة فقط عندما تبقى الطبقات الخمس متوافقة: مزامنة الدليل، وثقة OAuth/الاتحاد، وDNS، وجدران الحماية، وEOP/الموصلات. المعالج الأخضر لا يتحقق من واقعك، بل الفحوصات المسبقة والفحوصات المستمرة هي التي تفعل ذلك.

الترابطات الخفية (نظرة سريعة)

• الدليل ← السحابة: يجب أن تزامن Azure AD Connect mail وproxyAddresses وlegacyExchangeDN وmsExchMailboxGuid، في الوقت المحدد وفي كل مرة.
• الثقة: شهادات الاتحاد وOAuth وتسجيلات التطبيقات تدعم معلومات التوفر وEWS ونقل صناديق البريد.
• DNS: يجب أن تكون سجلات Autodiscover وMX وSPF وDKIM وSRV/CNAME (إن استُخدمت) صحيحة داخليًا وخارجيًا.
• جدار الحماية/NAT/SSL: تحتاج نقاط نهاية MRSProxy وEWS وOAB وAutodiscover والاتحاد إلى نشر متسق واستثناءات فحص مناسبة.
• EOP/الموصلات: تحكم موصلات الوارد والصادر، وTLS، ومواءمة SPF/DKIM/DMARC في التسليم والسمعة.

1) الفحوصات المسبقة (قبل تشغيل HCW أو أي عملية انتقال كبيرة)

الدليل والسمات

تحقّق من السمات الحرجة لمستخدم مستهدف باستخدام PowerShell:

Get-ADUser upn@contoso.com -Properties mail,proxyAddresses,legacyExchangeDN,msExchMailboxGuid | Select-Object SamAccountName,mail,legacyExchangeDN, @{n='Proxy';e={$_.proxyAddresses -join ';'}}, @{n='GUIDPresent';e={([string]::IsNullOrEmpty($_.msExchMailboxGuid) -eq $false)}}
Get-ADSyncScheduler
Start-ADSyncSyncCycle -PolicyType Delta

يجب أن تكون صحيحة:

• msExchMailboxGuid موجودة (للمستخدمين المنقولين)
• proxyAddresses تحتوي على عنوان SMTP: الأساسي الصحيح والأسماء المستعارة
• legacyExchangeDN محفوظة لعناوين الرد X.500

OAuth والاتحاد

شغّل هذه الأوامر محليًا في Exchange Management Shell:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox user@contoso.com -Verbose
Get-FederationTrust | fl *Domain*,TokenIssuerUri,OrgCertificate
Test-FederationTrust -Verbose
Get-AuthConfig | fl CurrentCertificateThumbprint,ServiceName,IssuerIdentifier,Realm
Get-ExchangeCertificate | ? {$_.Services -match 'SMTP|IIS'} | fl Thumbprint,NotAfter,Services,Subject

يجب أن تكون صحيحة:

• شهادات صالحة وغير منتهية مرتبطة بـ IIS/SMTP ومستخدمة بواسطة AuthConfig/الاتحاد
• نجاح Test-OAuthConnectivity

Autodiscover وDNS (داخليًا وخارجيًا)

Resolve-DnsName autodiscover.contoso.com -Type CNAME,A
Resolve-DnsName contoso.com -Type MX
Resolve-DnsName contoso.com -Type TXT # check SPF/DMARC/DKIM selectors

يجب أن تكون صحيحة:

• تشير Autodiscover إلى الوجهة المقصودة (عادةً EXO عند بدء المرحلة التجريبية)
• يشير MX إلى EOP (أو الخادم الذكي الخاص بك) بشكل متسق
• يجب أن يشمل سجل SPF جميع المرسلين (EOP وأي بوابات إرسال): على سبيل المثال، v=spf1 include:spf.protection.outlook.com include:yourgateway ~all
• نشر محددات DKIM (في حال تفعيلها)، وتتوافق سياسة DMARC مع الواقع الفعلي

الجدار الناري / النشر

نشر الخدمات عبر HTTPS/443 باستخدام شهادات حقيقية للمسارات التالية:

• https://mail.contoso.com/ews/* (EWS)
• https://mail.contoso.com/mrsproxy.svc (MRSProxy)
• https://autodiscover.contoso.com/autodiscover/* (Autodiscover)
• https://mail.contoso.com/oab/* (OAB، عند الحاجة)
• بيانات وصف الاتحاد (Federation metadata) في حال استضافتها محليًا

نصائح:

• تعطيل SSL offload إذا كان يكسر سلاسل شهادات العملاء.
• استثناء حركة مرور Exchange Online من فحص TLS كلما أمكن ذلك.
• التأكد من أن الوكيل العكسي يحافظ على الترويسات (headers) ويدعم طلبات POST الكبيرة (MRS).

EOP / الموصلات

• موصل الوارد (Inbound connector): من عناوين IP العامة الخاصة بالخوادم المحلية؛ مع اشتراط TLS.
• موصل الصادر (Outbound): نحو الإنترنت أو الخادم الوسيط (smart host)؛ وتتطابق سياسات TLS معه.
• النطاقات المقبولة (Accepted domains): مرجعية (Authoritative) أو ترحيل داخلي (Internal Relay) حسب التصميم.

2) اختبارات التحقق (بعد HCW وقبل المستخدمين)

نقل صناديق البريد و EWS

Test-MigrationServerAvailability -ExchangeRemoteMove -RemoteServer mail.contoso.com -Credentials (Get-Credential) -Authentication Basic -Autodiscover
Test-WebServicesConnectivity -ClientAccessServer mail.contoso.com -TrustAnySSLCertificate:$false -MailboxCredential (Get-Credential)

توفر المعلومات (Free/Busy) في الاتجاهين

• من السحابة إلى المحلي: أنشئ اجتماعًا من صندوق بريد في Exchange Online، ثم تحقق من توفر المستخدم المحلي.
• من المحلي إلى السحابة: نفّذ الاختبار العكسي. إذا كان الاتجاه واحدًا فقط، فأعد التحقق من ثقة الاتحاد (federation trust) وOAuth.

Autodiscover و Outlook

• إنشاء ملف تعريف جديد (على الشبكة الداخلية والخارجية)
• يجب أن تظهر مطالبات Outlook /SPA وModern Auth بشكل صامت دون حلقات متكررة

نظافة الرسائل

• أرسل بريدًا من خارج المؤسسة؛ وتحقق من SPF=pass وDKIM=pass وتوافق سياسة DMARC
• تتبع الرسائل عبر Message Trace في EXO وأي بوابات محلية

3) ورقة مرجعية سريعة لـ DNS والجدار الناري

الجدار الناري (من العام إلى CAS/MBX المحلي)

• TCP 443 نحو /autodiscover/* و/ews/* و/mrsproxy.svc و/oab/*
• المصدر: نقاط نهاية Microsoft 365 (أو أي مصدر إذا تعذر عليك صيانة القوائم)
• لا يُجرى أي اعتراض لـ TLS على هذه المسارات؛ مع تمرير SNI وسلاسل الشهادات الكاملة

4) مراقبة الصحة (اجعلها روتينية وممِلّة)

يوميًا / كل ساعة

• Azure AD Connect: تأكد من أن Get-ADSyncScheduler يُظهر تشغيلًا تاليًا سليمًا؛ وأن حالة البوابة خضراء
• انتهاء الشهادات: نبّه قبل 30 و15 و7 أيام لشهادات IIS/SMTP/Auth/Federation
• شذوذ تتبع الرسائل: ارتفاعات في حالات التأجيل والارتداد (bounces)
• اختبارات EWS/OAuth الاصطناعية عبر المهام المجدولة

$u = "probe@contoso.com"
$result = Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox $u -ErrorAction SilentlyContinue
if(-not $result -or $result.Result -ne "Success"){ Write-EventLog -LogName Application -Source "HybridProbe" -EntryType Error -EventId 8001 -Message "OAuth/EWS probe failed for $u" }

5) الأعطال الشائعة والإصلاح (الأعراض ← أسرع الفحوصات)

فشل Free/Busy في اتجاه واحد

1. Test-FederationTrust وتحقق من NotAfter لشهادة الاتحاد
2. تطابق بصمة Get-AuthConfig مع شهادة صالحة؛ وأعد تشغيل Set-AuthConfig -PublishCertificate إذا تم تدوير الشهادة
3. تأكد أن الجدار الناري يسمح بـ /ews/* في الاتجاهين؛ ولا يوجد فحص TLS

تعليق نقل صناديق البريد (10–20%)

1. Test-MigrationServerAvailability نحو عنوان URL المحلي
2. تأكد من تفعيل MRSProxy (Get-WebServicesVirtualDirectory | fl MRSProxyEnabled,ExternalUrl)
3. ترويسات الوكيل العكسي والمهلات الزمنية؛ وتحقق من الفحص العميق للمنفذ 443
4. تأكد من اكتمال مزامنة AAD Connect ووجود السمات المطلوبة

حلقات أو مطالبات متكررة في ملف تعريف Outlook

1. Resolve-DnsName autodiscover.contoso.com (داخلياً وخارجياً) يُرجع النتائج المقصودة
2. هل تم فرض Modern Auth؟ تحقق من إصدار العميل وسجل النظام (Registry) وسياسات الوصول المشروط
3. هل توجد أهداف Autodiscover مختلفة بين الداخل والخارج؟ عالج حالة الانقسام (split-brain)

رسائل NDR عشوائية / وضع الرسائل في مجلد البريد المزعج

1. سجل SPF يتضمن جميع المرسلين؛ nslookup -type=txt contoso.com
2. تفعيل DKIM مع صحة المحددات (selectors)؛ ومواءمة DMARC مع نطاق الحقل From
3. مواءمة TLS لموصلات EOP؛ وتحقق من حالة التسليم في تتبع الرسائل (message trace)

6) ضوابط الحماية للتغيير ودورة الحياة

• تقويم الشهادات: شهادات Auth وFederation وIIS وSMTP مع مالكيها وكتيب إجراءات التجديد
• فحوصات انحراف الإعدادات: تصدير ومقارنة موصلات EXO والنطاقات المقبولة وقواعد النقل كل ربع سنة
• مراجعات DNS: المناطق الداخلية والخارجية بعد أي تغيير في توجيه البريد أو في أحد المشاريع
• AAD Connect: توثيق حساب الخدمة والجدولة وإيقاع الترقيات، واختبار خادم التجهيز (staging)
• ملاحظات التراجع: كيفية توجيه Autodiscover وMX مؤقتاً إلى الإعداد السابق، وكيفية إيقاف دفعات الترحيل مؤقتاً بأمان

قائمة مراجعة صفحة واحدة قبل الإطلاق (Pre-GoLive)

• تمت مزامنة المستخدمين التجريبيين والتحقق من mail وproxyAddresses وlegacyExchangeDN وmsExchMailboxGuid
• Test-OAuthConnectivity وTest-FederationTrust بحالة Success
• سجلات Autodiscover وMX وSPF وDKIM وDMARC صحيحة (داخلياً وخارجياً)
• MRSProxy وEWS منشوران، وتم تجاوز فحص TLS في الجدار الناري
• تم اختبار موصلات EOP وفرض TLS كما هو مقصود
• AAD Connect يعمل بصورة سليمة، وتكتمل المزامنة التدريجية (delta sync) ضمن اتفاقية مستوى الخدمة المتوقعة
• الشهادات متبقٍ عليها أكثر من 60 يوماً، والمراقبة قائمة
• اختبارات المحاكاة (Synthetic) مجدولة، وكتيب إجراءات الدعم الفني جاهز

الخلاصة الأخيرة

يقوم HCW بربط نقاط النهاية، لكنه لا يتحقق من البيانات أو الثقة أو المسار. تعامل مع الهجين كنظام حي: تحقق من السمات، وجدّد الثقة، وراقب DNS، وحافظ على نظافة المسارات، حتى تبقى “الشبكة غير المرئية” غير مرئية لمستخدميك.

هل تريد المزيد من الأدلة العملية مثل هذا؟
احصل على وصول كامل إلى M365 Show – Microsoft 365 Digital Workplace Daily ← m365.show/subscribe