חמש השכבות של Exchange Hybrid מעבר לאשף

By Mirko Peters · 2026-08-11

חמש השכבות של Exchange Hybrid מעבר לאשף. ברוכים השבים, פודקאסטרים ואנשי IT! כשאתם מגדירים או מנהלים סביבת Exchange Hybrid, קל להסתמך לגמרי על אשף ההגדרה של Hybrid (HCW). מריצים אותו, רואים את הסטטוס הופך לירוק, ומניחים שהמסע שלכם לענן הסתיים. אבל כמו שכל מנהל מנוסה יגיד לכם, אשף ירוק אומר רק שהסקריפט הראשוני הסתיים בהצלחה. הוא לא בודק את המציאות היומיומית שלכם.

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

ברוכים השבים, פודקאסטרים ואנשי IT! כשאתם מגדירים או מנהלים סביבת Exchange Hybrid, קל להסתמך לגמרי על אשף ההגדרה של Hybrid (HCW). מריצים אותו, רואים את הסטטוס הופך לירוק, ומניחים שהמסע שלכם לענן הסתיים. אבל כמו שכל מנהל מנוסה יגיד לכם, אשף ירוק אומר רק שהסקריפט הראשוני הסתיים בהצלחה. הוא לא מאמת את המציאות היומיומית שלכם.

בפרק האחרון של הפודקאסט שלנו, Maintain Hybrid Exchange Beyond the Configuration Wizard, אנחנו צוללים לעומק ומסבירים מדוע הסתמכות בלעדית על האשף היא מתכון לכשלים שקטים בזרימת הדואר, לקלנדרים עם מידע שגוי על זמינות (free/busy) ולחוויית משתמש מתסכלת. כדי לשלוט באמת בסביבת ההיברידית שלכם, צריך להבין ולנהל את חמש השכבות הקריטיות ששומרות על התשתית שלכם בריאה.

עיקרי הדברים

היברידיות עובדת רק כשחמש השכבות נשארות מסונכרנות: סנכרון ספריות, אמון OAuth/federation, DNS, חומות אש, וEOP/connectors. אשף ירוק לא מאמת את המציאות שלכם, בדיקות מקדימות ובדיקות רציפות כן.

התלויות הנסתרות (במבט מהיר)

• ספרייה → ענן: Azure AD Connect חייב לסנכרן את mail, proxyAddresses, legacyExchangeDN, msExchMailboxGuid, בזמן ובאופן עקבי.
• אמון: אישורי Federation ו-OAuth ורישומי אפליקציות תומכים ב-free/busy, EWS, העברות תיבות דואר.
• DNS: Autodiscover, MX, SPF, DKIM, ו-SRV/CNAME (אם בשימוש) חייבים להיות תקינים פנימית וחיצונית.
• חומת אש/NAT/SSL: נקודות הקצה של MRSProxy, EWS, OAB, Autodiscover ו-Federation דורשות פרסום עקבי וחריגים בבדיקות הבקרה.
• EOP/Connectors: connectors נכנסים ויוצאים, TLS, ויישור של SPF/DKIM/DMARC קובעים את אספקת הדואר ואת המוניטין.

1) בדיקות מקדימות (לפני הרצת HCW או מעבר משמעותי)

ספרייה ותכונות (Directory & Attributes)

בצעו בדיקה דגימתית של תכונות קריטיות למשתמש יעד באמצעות 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 ו-Federation (OAuth & Federation)

הריצו את הפקודות הבאות מקומית (on-prem) ב-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/Federation
• 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 (או לשרת ה-smart host שלכם) באופן עקבי
• 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, במידת הצורך)
• מטא-נתונים של הפדרציה, אם מתארחים מקומית

רמזים:

• נטרלו SSL offload ששובר שרשראות תעודות לקוח.
• החריגו את תעבורת EXO מבדיקת TLS, ככל שניתן.
• ודאו שה-reverse proxy משמר כותרות ותומך ב-POST גדולים (MRS).

EOP / קונקטורים

• קונקטור נכנס: מכתובות ה-IP הציבוריות המקומיות שלכם; נדרש TLS.
• יוצא: לאינטרנט או ל-smart host; מדיניות ה-TLS תואמת.
• דומיינים מקובלים: 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 (בשני הכיוונים)

• ענן → מקומי: יצירת פגישה מתיבת EXO ובדיקת הזמינות של המשתמש המקומי.
• מקומי → ענן: הבדיקה ההפוכה. אם הבעיה רק בכיוון אחד, בדקו מחדש את אמון הפדרציה ואת OAuth.

Autodiscover ו-Outlook

• יצירת פרופיל חדש (ברשת הפנימית והחיצונית)
• בקשות /SPA ו-Modern Auth של Outlook נשארות שקטות (ללא לולאות)

היגיינת הודעות

• שלחו דואר חיצוני; ודאו 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
• מעקב אחר חריגות ב-Message Trace: זינוקים בדחיות והחזרות
• בדיקות סינתטיות של 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: טביעת האצבע (thumbprint) תואמת לתעודה תקפה; הריצו מחדש את Set-AuthConfig -PublishCertificate אם התעודה הוחלפה
3. חומת האש מאפשרת /ews/* בשני הכיוונים; ללא בדיקת TLS

העברות תיבות דואר נתקעות (10–20%)

1. Test-MigrationServerAvailability אל כתובת ה-URL המקומית
2. MRSProxy מופעל (Get-WebServicesVirtualDirectory | fl MRSProxyEnabled,ExternalUrl)
3. כותרות ו-timeouts של ה-reverse proxy; בדקו בדיקת חבילות עמוקה בפורט 443
4. AAD Connect עודכן; המאפיינים קיימים

לולאות / בקשות חוזרות בפרופיל Outlook

1. Resolve-DnsName autodiscover.contoso.com (פנימי + חיצוני) נפתרים כצפוי
2. האם Modern Auth נאכף? בדקו את גרסת הלקוח, הרישום ומדיניות הגישה המותנית (CA)
3. יעדי Autodiscover שונים בין הפנים לחוץ? תקנו את מצב ה-split-brain

הודעות NDR אקראיות / מיקום שגוי בתיבת הספאם

1. SPF כולל את כל השולחים; nslookup -type=txt contoso.com
2. DKIM מופעל ומזהי ה-selector תקפים; DMARC מיושר עם דומיין ה-From:
3. התאמת TLS במחברי EOP; בדקו את סטטוס ההודעה ב-message trace

6) מסגרת לשינויים ולמחזור חיים

• לוח זמנים לתעודות: תעודות Auth/Federation/IIS/SMTP עם בעלים ו-runbook לחידוש
• בדיקות סחף תצורה: ייצוא והשוואה רבעונית של מחברי EXO, דומיינים מקובלים וכללי הובלה
• ביקורות DNS: אזורים פנימיים וחיצוניים לאחר כל שינוי בניתוב דואר או בפרויקט
• AAD Connect: חשבון השירות, מתזמן ותדירות השדרוגים מתועדים; שרת staging נבדק
• הערות לחזרה לאחור: איך להפנות זמנית מחדש את Autodiscover/MX; איך להשהות באופן בטוח אצוות הגירה

רשימת בדיקה חד-עמודית לפני ה-GoLive

• mail, proxyAddresses, legacyExchangeDN, msExchMailboxGuid מסונכרנים ומאומתים עבור משתמשי הפיילוט
• Test-OAuthConnectivity ו-Test-FederationTrust עם תוצאה Success
• Autodiscover/MX/SPF/DKIM/DMARC תקינים (פנימי/חיצוני)
• MRSProxy ו-EWS מפורסמים; עקיפת בדיקת TLS של חומת האש בוצעה
• מחברי EOP נבדקו; TLS נאכף כמתוכנן
• AAD Connect תקין; סנכרון דלתא מסתיים בתוך ה-SLA הצפוי
• תעודות עם יותר מ-60 ימים שנותרו; ניטור פעיל
• בדיקות סינתטיות מתוזמנות; runbook של שולחן העזרה מוכן

מחשבה לסיום

ה-HCW מחבר את נקודות הקצה, אבל אינו מאמת את הנתונים, האמון או הנתיב. התייחסו להיברידי כאל מערכת חיה: אמתו מאפיינים, חדשו אמון, עקבו אחר ה-DNS, ושמרו על נתיבים נקיים, כך ש"הרשת הבלתי נראית" שלכם תישאר בלתי נראית למשתמשים.

רוצים עוד playbooks כמו זה?
קבלו גישה מלאה ל-M365 Show – Microsoft 365 Digital Workplace Daily → m365.show/subscribe