Connect Exchange Online to Dynamics 365 Customer Engagement (on-premises) は、Outlookユーザーが使うExchange Onlineメールボックスと、オンプレミス版Dynamics 365 Customer Engagementをサーバー側同期で連携するための設定です。結論から言うと、2026年5月時点では「新しく設定すればよい機能」ではなく、EWS廃止に備えて、既存連携の棚卸し・延命可否・Dynamics 365 onlineへの移行判断を急ぐべき領域になっています。
特に重要なのは、この連携がExchange Web Services（EWS）を使ってExchange Onlineと通信する点です。Microsoft Learnの英語版では、Exchange OnlineのEWSは2027年4月に削除予定であり、2025年10月1日以降はこの機能への新規更新や新規テナント接続が行われないと説明されています。Dynamics CRM Customer Engagement v8.0は2026年5月25日にExchange Online連携のサポート終了、v9.0も2027年4月1日にサポート終了となるため、管理者は「今の設定が動いているか」だけでなく「いつまで安全に使えるか」を確認する必要があります。(Microsoft Learn)
Outlookの「Connect Exchange Online to Dynamics 365 Customer Engagement (on-premises)」で何が変わるのか
今回のポイントは、Outlookアプリそのものの設定変更ではありません。実際の影響は、Outlookユーザーが利用しているExchange Onlineメールボックスと、Dynamics 365 Customer Engagement (on-premises) のメール、予定、連絡先、タスク同期に出ます。
Microsoftの公式手順は、Dynamics 365 Customer Engagement (on-premises) とExchange Onlineの間でサーバーベース認証を構成するものです。メールサーバープロファイル、テナントID、証明書、Entra IDアプリ、メールボックス承認、テストと有効化までを順番に設定します。手順自体は従来のサーバー側同期の構成に見えますが、2026年時点ではEWS廃止スケジュールを前提に読む必要があります。(Microsoft Learn)
| 確認項目 | これまでの見方 | 2026年時点での見方 |
|---|---|---|
| 接続方式 | Dynamics 365 on-premises とExchange Onlineをサーバー側同期で接続する | EWS依存のため、将来の廃止リスクを前提に評価する |
| 新規導入 | 手順に沿って構成する | 2025年10月1日以降、新規テナント接続は期待できない |
| 既存環境 | 証明書やメールボックス設定を維持する | サポート期限、EWS使用状況、移行計画を同時に確認する |
| 長期方針 | Exchange Online連携を継続利用する | Dynamics 365 onlineへの移行、または対応可能なExchange Server on-premises構成を検討する |
| 開発者対応 | 個別エラーの修正が中心 | EWS利用アプリの棚卸しとMicrosoft Graph等への移行検討が必要 |
重要なのは、「メールが送受信できているから問題ない」と判断しないことです。EWSの廃止は段階的な運用変更ではなく、最終的にはExchange Online側でEWSが使えなくなる変更です。MicrosoftのEWS廃止ページでも、2026年10月からグローバルに無効化が始まり、2027年4月に完全無効化される予定が示されています。(Microsoft Learn)
影響を受ける対象者
影響を受けるのは、主に次のような環境です。
- Dynamics 365 Customer Engagement (on-premises) とExchange Onlineを連携している組織
- 「Exchange Online (Hybrid)」の電子メールサーバープロファイルを使っている環境
- サーバー側同期で受信メール、送信メール、予定、連絡先、タスクを同期しているユーザー
- Dynamics 365のメールボックス承認、Test & Enable Mailboxes、Email Server Profileを管理している管理者
- EWSを使う独自アプリ、アドイン、連携ツールを保守している開発者やSIer
一方、Dynamics 365 Customer Engagement (on-premises) とオンプレミス版Exchange Serverを接続している場合は、今回のExchange Online EWS廃止とは別の観点で確認します。Microsoftは、Exchange Onlineではなくサポート対象のオンプレミス版Exchange Serverを使う代替案も案内しています。(Microsoft Learn)
管理者が最初に確認すべき影響範囲
Outlook連携のトラブルは、ユーザーから見ると「メールがDynamics 365に取り込まれない」「予定が同期されない」「取引先担当者が反映されない」といった形で現れます。しかし、原因はOutlookクライアントではなく、Dynamics 365側のサーバー側同期、証明書、Exchange OnlineテナントID、メールボックス承認、EWSアクセスにあることが少なくありません。
| 影響範囲 | 確認する場所 | 見るべきポイント |
|---|---|---|
| 受信メール | Dynamics 365のメールボックス | Incoming Email Statusが成功しているか |
| 送信メール | Dynamics 365のメールボックス | Outgoing Email Statusが成功しているか |
| 予定・連絡先・タスク | 同期方法の設定 | Server-Side Synchronizationになっているか |
| メールサーバープロファイル | Email Server Profiles | Exchange Online (Hybrid) が使われているか |
| テナントID | S2STenantId、プロファイル設定 | Exchange OnlineテナントIDが正しく設定されているか |
| 証明書 | Dynamics 365サーバー、非同期処理サービス | 秘密鍵の読み取り権限があるか |
| EWS利用 | Microsoft 365管理センター | EWS usage reportでアプリ別利用状況を確認する |
Microsoftの手順では、メールボックスをテストすると、受信メール、送信メール、予定・連絡先・タスクの状態がメールボックスレコードに表示され、エラー時はメールボックスやプロファイル所有者のアラートに表示されます。運用確認では、単にプロファイルを保存するだけでなく、対象メールボックスを選んで「Test & Enable Mailboxes」まで実施することが重要です。(Microsoft Learn)
サーバーベース認証を設定する前提条件
Connect Exchange Online to Dynamics 365 Customer Engagement (on-premises) の設定では、管理者権限と証明書の準備が失敗しやすいポイントです。特にオンプレミスのDynamics 365サーバーを複数台で構成している場合、1台だけに証明書を入れても同期が安定しないことがあります。
| 項目 | 必要な内容 | 実務上の注意点 |
|---|---|---|
| Dynamics 365権限 | System Administratorセキュリティロール | メールボックス設定変更にはMailboxエンティティの読み取り・書き込み権限も確認する |
| Exchange Online権限 | Office 365 Global Administrator | PowerShellやテナント設定作業に必要 |
| 証明書 | 信頼された証明機関のX509証明書 | 評価では自己署名も可能だが、本番では更新管理しやすい証明書を使う |
| 非同期処理サービス | 証明書の秘密鍵読み取り権限 | CRM Async Serviceの実行アカウントに権限を付ける |
| Exchange Online側 | テナントIDに対するアクセス有効化 | 必要に応じてExchange Online管理者がサポートに依頼する |
Microsoft Learnでは、サーバー間認証に使う証明書が存在しない、または無効な場合に「Failed Authentication」が返る可能性があると説明されています。証明書エラーはウィザードやPowerShellの後半で発覚すると切り戻しが面倒になるため、事前に証明書ストア、秘密鍵、サービスアカウント権限、証明書期限を確認しておきましょう。(Microsoft Learn)
実際の設定手順で押さえるべき流れ
公式手順では、作業を指定された順序で実行し、PowerShellコマンドなどでエラーが出た場合は、次の手順に進む前に解決するよう求めています。これは形式的な注意ではありません。証明書、Entra IDアプリ、テナントID、メールサーバープロファイルは依存関係があるため、途中の失敗を放置すると、後続のメールボックステストで原因特定が難しくなります。(Microsoft Learn)
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | 現行環境のバージョンと同期方式を棚卸しする | v8.0、v9.0、Exchange Online (Hybrid) 利用有無を曖昧にしない |
| 2 | 証明書を準備する | PFXのパスワード、KeySpec、秘密鍵権限を確認する |
| 3 | CertificateReconfiguration.ps1を実行する | サービスアカウント名や証明書の指定ミスに注意する |
| 4 | Entra IDアプリを作成する | 必要なAPIアクセス許可と管理者同意を確認する |
| 5 | ConfigureCrmServerSideSync.ps1を実行する | 組織名、テナントID、Client ID、Client Secretの取り違えに注意する |
| 6 | S2STenantIdを設定する | Dynamics 365組織名とExchange OnlineテナントIDを正しく対応させる |
| 7 | Exchange Online (Hybrid) のメールサーバープロファイルを作成する | 既定のテナントID、自動検出、処理開始日時を慎重に設定する |
| 8 | 既定のメール処理と同期方法を設定する | 受信、送信、予定・連絡先・タスクの同期方法を確認する |
| 9 | メールボックスを承認する | ユーザー、キューの承認漏れをなくす |
| 10 | メールボックスをテストして有効化する | 失敗時はアラートとステータスを確認してから再実行する |
Entra IDアプリについては、Microsoft Learnの英語版でApplication.ReadWrite.All、Organization.Read.All、User.ReadのAPIアクセス許可を付与する手順が示されています。また、この新しいアプリはセットアップと新しいAPIアクセス許可のために必要で、すべてのセットアップ手順が完了したら削除できると説明されています。運用上は、削除前に設定が完了していること、監査ログや変更記録にClient IDなどを残していることを確認してから扱いを決めるのが安全です。(Microsoft Learn)
メールサーバープロファイルで注意すべき設定
Exchange Online (Hybrid) のメールサーバープロファイルでは、見落としやすい設定がいくつかあります。特に「Process Email From」は、同期対象になるメールの開始日時に関わるため、既存メールの再処理や想定外の取り込みを避けるために慎重に決めるべき項目です。
| 設定項目 | 推奨される考え方 | 注意点 |
|---|---|---|
| Name | 環境名と用途が分かる名前にする | 例：EXO-Hybrid-Prod、EXO-Hybrid-Test |
| Use Default Tenant ID | PowerShellで設定したIDを使う | 手動入力は転記ミスの原因になる |
| Auto Discover Server Location | 基本はYes | Noにする場合は受信・送信URLを正確に管理する |
| Process Email From | 切り替え日時を明確に決める | 過去日付にすると以前のメール取得が発生する可能性がある |
| Minimum Polling Intervals | 業務要件と負荷のバランスで決める | 短くしすぎるとExchange Online側の呼び出しが増える |
| Move Failed Emails to Undeliverable Folder | 運用ルールに合わせて判断する | 有効化すると追跡失敗メールが配信不能フォルダーに移動される |
メールサーバープロファイルの作成後は、必ず「Test Connection」を実行します。接続テストで問題が出た場合は、テスト結果ダイアログの内容を使って診断します。ここで証明書、テナントID、権限、Exchange Online側アクセス許可を切り分けると、メールボックス単位のテストに進んだ後の混乱を減らせます。(Microsoft Learn)
EWS使用状況レポートで移行リスクを見える化する
Dynamics 365 Customer Engagement (on-premises) との連携だけを見ていると、同じテナント内で他のアプリがEWSを使っていることに気づきにくくなります。Microsoft 365管理センターにはEWS usage reportがあり、組織内でEWSを呼び出しているアプリごとのSOAP Action、成功呼び出し数、最終アクティビティ日を確認できます。(Microsoft Learn)
確認手順は、Microsoft 365管理センターで「Reports」から「Usage」を開き、「Exchange」のレポートページで「EWS usage」タブを選択する流れです。レポートは直近7日、30日、90日でフィルターでき、データは日次ではなく週次で収集・集計されます。CSVエクスポートも可能なので、アプリ所有者、ベンダー、利用部門ごとに移行タスクを割り振る際に役立ちます。(Microsoft Learn)
開発者は、EWS usage reportに出てきたApplication IDをMicrosoft Entra IDのエンタープライズアプリケーションと照合し、どのアプリがどの操作を実行しているかを確認します。Microsoftは、EWS依存の移行分析を支援するためにEWS Usage Reports、EWS Analyzer tool、AI支援のコード分析・リファクタリングチュートリアルを案内しています。(Microsoft Learn)
移行・延命・切り替えの判断基準
2026年時点で取るべき方針は、環境の状態によって変わります。すべての組織がすぐに同じ移行をできるわけではありませんが、「何もしない」は最もリスクが高い選択です。
| 環境の状態 | 推奨判断 | 理由 |
|---|---|---|
| Dynamics CRM Customer Engagement v8.0でExchange Online連携している | 早急に移行計画を確定する | 2026年5月25日にサポート終了予定 |
| Dynamics 365 Customer Engagement v9.0で既存連携がある | 2026年10月までに移行または延命策を判断する | 2027年4月1日にサポート終了予定 |
| 新規テナントで同連携を導入したい | 原則として長期設計に採用しない | 2025年10月1日以降、新規テナント接続は行われない |
| サーバー側同期が業務の中核 | Dynamics 365 online移行を優先検討する | Microsoftがサーバー側同期継続にはDynamics 365 online移行を推奨している |
| オンプレミス維持が必須 | Exchange Server on-premises構成を検討する | Exchange Online EWS廃止の影響を避けられる可能性がある |
| 独自アプリがEWSを使っている | Microsoft Graph等への移行計画を作る | Exchange OnlineのEWSは完全無効化が予定されている |
Microsoft Learnでは、サーバー側同期機能が必要な場合はDynamics 365 (online) への移行を推奨し、代替案としてサポート対象のオンプレミス版Exchange Serverを使う選択肢も示しています。2026年10月1日は移行またはEWS延命の判断期限として扱い、2027年4月1日は最終期限として逆算するのが現実的です。(Microsoft Learn)
日本語版ドキュメントだけを見て判断しない
日本語圏の管理者が特に注意したいのは、Microsoft Learnの日本語版と英語版で更新タイミングが異なる場合があることです。該当ページの日本語版は、サーバーベース認証の基本手順を説明していますが、英語版にあるEWS廃止に関する警告や重要日程が同じタイミングで反映されていない場合があります。日本語版のページは最終更新日が2025年3月19日、英語版は2026年5月20日と表示されているため、期限や廃止情報は英語版も確認して判断するのが安全です。(Microsoft Learn)
手順の画面名や日本語UIの確認には日本語版が便利ですが、サポート期限、非推奨化、廃止日、移行先の推奨といった運用判断は、英語版の最新情報を基準にしましょう。
展開時に失敗しやすいポイント
この連携でよくある失敗は、技術的には小さく見えても、切り分けに時間がかかるものです。特に次の点は事前チェックリストに入れておくべきです。
| 失敗例 | 起きること | 対策 |
|---|---|---|
| 証明書の秘密鍵権限が不足している | サーバー間認証で失敗する | CRM Async Serviceのアカウントに読み取り権限を付与する |
| 一部サーバーに証明書が入っていない | 同期が不安定になる | 非同期処理サービスを実行する全サーバーを確認する |
| テナントIDを手入力して誤る | Exchange Onlineに接続できない | PowerShellでS2STenantIdを設定し、プロファイルは既定IDを使う |
| メールボックス承認を忘れる | メール処理が始まらない | ユーザーとキューを対象にApprove Emailを実行する |
| Process Email Fromを過去にしすぎる | 古いメールの取り込みや処理負荷が増える | 切り替え日時を業務側と合意してから設定する |
| Test Connectionだけで完了したと思う | 個別メールボックスの同期不備を見逃す | Test & Enable Mailboxesまで実行する |
| EWS利用アプリを棚卸ししない | 廃止時に別システムが止まる | Microsoft 365管理センターのEWS usage reportを確認する |
証明書の秘密鍵読み取り権限を付与した後は、Microsoft Dynamics CRM Asynchronous Processing Serviceとメンテナンス用サービスの再起動も必要です。権限を変えただけで同期が回復しない場合は、サービス再起動の有無を確認してください。(Microsoft Learn)
管理者と開発者が今すぐ取るべき行動
まず、Dynamics 365 Customer Engagement (on-premises) のバージョン、Exchange Online (Hybrid) プロファイルの有無、サーバー側同期の対象メールボックス数を洗い出します。次に、Microsoft 365管理センターのEWS usage reportで、Dynamics 365以外のEWS利用アプリも含めて一覧化します。
そのうえで、次の順番で対応すると無駄がありません。
- Dynamics 365 on-premisesのバージョンとサポート期限を確認する
- Exchange Online (Hybrid) のメールサーバープロファイルを棚卸しする
- 受信、送信、予定、連絡先、タスクの同期対象を確認する
- 証明書、秘密鍵権限、非同期処理サービスの状態を確認する
- メールボックス承認とTest & Enable Mailboxesの結果を記録する
- EWS usage reportをCSVで出力し、アプリ所有者を特定する
- 2026年10月までに、移行・延命・オンプレミスExchange利用の方針を決める
- 2027年4月1日までにEWS依存を解消できる計画に落とし込む
今回の変更は、Outlook利用者に突然設定作業を求めるものではありません。しかし、Exchange OnlineメールボックスとDynamics 365 Customer Engagement (on-premises) の同期が業務に組み込まれている場合、管理者の準備不足はユーザーのメール追跡、予定同期、顧客対応履歴に直結します。
「Connect Exchange Online to Dynamics 365 Customer Engagement (on-premises)」は、今後も同じように使い続ける前提ではなく、EWS廃止までの残り期間で安全に移行するための確認対象です。まずは現在の同期方式とEWS利用状況を見える化し、移行先と期限を決めるところから着手しましょう。
コメント