ウィザードの先へ：Exchange ハイブリッドの5つのレイヤーを極める

By Mirko Peters · 2026-08-11

ウィザードの先へ：Exchange ハイブリッドの5つのレイヤーを極める ポッドキャスターとITプロフェッショナルの皆さん、おかえりなさい！Exchange ハイブリッド環境を構築または管理するとき、ハイブリッド構成ウィザード（HCW）だけに頼ってしまうのは簡単です。ウィザードを実行し、ステータスが緑になるのを見て、クラウドへの移行は完了したと思い込んでしまいます。しかし、経験豊富な管理者なら誰でも言うように、緑のウィザードが示すのは、初期スクリプトが正常に完了したということだけです。日々の運用の実態を検証するものではありません……

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

ポッドキャスターとITプロフェッショナルの皆さん、おかえりなさい！Exchange ハイブリッド環境を構築または管理するとき、ハイブリッド構成ウィザード（HCW）だけに頼ってしまうのは簡単です。ウィザードを実行し、ステータスが緑になるのを見て、クラウドへの移行は完了したと思い込んでしまいます。しかし、経験豊富な管理者なら誰でも言うように、緑のウィザードが示すのは、初期スクリプトが正常に完了したということだけです。日々の運用の実態を検証するものではありません。

最新のポッドキャストエピソード「Maintain Hybrid Exchange Beyond the Configuration Wizard」では、ウィザードだけに頼ることがなぜ、サイレントなメールフローの障害、空き時間情報の不具合、そしてユーザーにとって不快な体験につながるのかを詳しく掘り下げています。ハイブリッド環境を本当に使いこなすには、インフラを正常に保つ5つの重要なレイヤーを理解し、管理する必要があります。

TL;DR

ハイブリッドが機能するのは、5つのレイヤーが整合している場合だけです。ディレクトリ同期、OAuth/フェデレーションの信頼、DNS、ファイアウォール、EOP/コネクタがその5つです。緑のウィザードは実際の状態を検証しません。検証するのは事前チェックと継続的なチェックです。

隠れた相互依存関係（概要）

• ディレクトリ → クラウド: 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: のプライマリアドレスとエイリアスがあること
• X.500 の返信アドレス用に legacyExchangeDN が保持されていること

OAuth とフェデレーション

オンプレミスの Exchange 管理シェルで、次のコマンドを実行します。

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（またはスマートホスト）を一貫して指していること
• 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 オフロードは無効にしてください。
• 可能な限り、EXO のトラフィックは TLS インスペクションから除外してください。
• リバース プロキシがヘッダーを保持し、大きな POST（MRS）をサポートしていることを確認してください。

EOP / コネクタ

• 受信コネクタ：オンプレミスのパブリック IP アドレスからの接続を対象とし、TLS を必須にします。
• 送信：インターネットまたはスマート ホスト宛てとし、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)

空き時間情報（双方向）

• クラウドからオンプレミス：EXO のメールボックスで会議を作成し、オンプレミスのユーザーの空き時間情報を確認します。
• オンプレミスからクラウド：逆方向のテストを行います。一方向のみ成功する場合は、フェデレーション トラストと OAuth を再確認してください。

Autodiscover と Outlook

• 新しいプロファイルの作成（社内ネットワークと社外ネットワークの両方）
• Outlook での /SPA と最新の認証のプロンプトが繰り返し表示されず、正常に完了することを確認します（ループしないこと）。

メッセージの運用チェック

• 外部にメールを送信し、SPF=pass、DKIM=pass、DMARC ポリシーとの整合性を確認します。
• EXO および（ある場合は）オンプレミスのゲートウェイで、メッセージ トレースを使用して追跡します。

3) DNS とファイアウォールのクイックリファレンス

ファイアウォール（パブリック → オンプレミスの CAS/MBX）

• TCP 443 で /autodiscover/*、/ews/*、/mrsproxy.svc、/oab/* を許可します。
• 送信元：Microsoft 365 のエンドポイント（一覧を維持できない場合は任意）
• これらのパスでは TLS インターセプトを行わず、SNI と完全な証明書チェーンを通過させてください。

4) 正常性の監視（退屈なくらい安定させる）

毎日 / 毎時

• Azure AD Connect：Get-ADSyncScheduler で次回の実行が正常であることを確認し、ポータルの正常性が緑であることを確認します。
• 証明書の有効期限：IIS / SMTP / 認証 / フェデレーションの証明書について、30 日、15 日、7 日前にアラートを設定します。
• メッセージ トレースの異常：配信の遅延やバウンスの急増を監視します。
• スケジュール タスクによる 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) よくある障害と対処（症状 → 最も早い確認手順）

空き時間情報が一方向でのみ失敗する

1. Test-FederationTrust を実行し、フェデレーション証明書の NotAfter を確認します。
2. Get-AuthConfig の拇印が有効な証明書と一致することを確認します。証明書をローテーションした場合は、Set-AuthConfig -PublishCertificate を再実行してください。
3. 両方向で /ews/* を許可し、TLS インスペクションを行わないようにします。

メールボックスの移動が 10～20% で停止する

1. オンプレミスの URL に対して Test-MigrationServerAvailability を実行します。
2. MRSProxy が有効であることを確認します（Get-WebServicesVirtualDirectory | fl MRSProxyEnabled,ExternalUrl）。
3. リバース プロキシのヘッダーとタイムアウトを確認し、443 の詳細インスペクションを確認します。
4. AAD Connect の同期が最新であり、必要な属性が存在することを確認します。

Outlook のプロファイルがループする / プロンプトが繰り返し表示される

1. Resolve-DnsName autodiscover.contoso.com（内部・外部とも）が意図どおりに名前解決されること
2. Modern Auth は有効になっていますか？クライアントのバージョン、レジストリ、条件付きアクセス ポリシーを確認してください
3. 内部と外部で Autodiscover の接続先が混在していませんか？スプリットブレインを解消してください

ランダムな NDR やスパムフォルダーへの振り分け

1. SPF がすべての送信元を含んでいるか確認する。nslookup -type=txt contoso.com
2. DKIM が有効で、セレクターが正しいこと。DMARC が From: のドメインと整合していること
3. EOP コネクタの TLS 設定が一致しているか確認し、メッセージ トレースで配信結果を確認する

6) 変更とライフサイクルのガードレール

• 証明書カレンダー: 認証、フェデレーション、IIS、SMTP の証明書について、担当者と更新手順書を用意する
• 構成ドリフトのチェック: EXO コネクタ、承認済みドメイン、トランスポート ルールを四半期ごとにエクスポートして差分を確認する
• DNS の監査: メール ルーティングやプロジェクトの変更後に、内部および外部のゾーンを確認する
• AAD Connect: サービス アカウント、スケジューラー、アップグレードの頻度を文書化し、ステージング サーバーでテストしておく
• ロールバックのメモ: Autodiscover や MX を一時的に元に戻す方法と、移行バッチを安全に一時停止する方法

本番移行前チェックリスト（1 ページ版）

• パイロット ユーザーについて、mail、proxyAddresses、legacyExchangeDN、msExchMailboxGuid が同期され、検証済みであること
• Test-OAuthConnectivity と Test-FederationTrust が 成功 すること
• Autodiscover、MX、SPF、DKIM、DMARC が正しく設定されていること（内部・外部）
• MRSProxy と EWS が公開されており、ファイアウォールの TLS インスペクションがバイパスされていること
• EOP コネクタがテスト済みで、TLS が意図どおりに適用されていること
• AAD Connect が正常で、差分同期が想定された SLA 内に完了すること
• 証明書の残り有効期間が 60 日を超えており、監視が設定されていること
• 合成テストがスケジュールされており、ヘルプデスクの手順書が準備されていること

結びの考え方

HCW はエンドポイントを接続するものであり、データ、信頼関係、経路を検証するものではありません。ハイブリッド環境は生きたシステムとして扱ってください。属性を検証し、信頼関係を更新し、DNS を監視し、経路を整理しておく。そうすることで、「見えないウェブ」をユーザーに意識させずに済みます。

このような実践的な手順書をもっと読みたいですか？
M365 Show – Microsoft 365 Digital Workplace Daily のフルアクセスは m365.show/subscribe から