Exchange Server（以後Exchange ）から Exchange Online（以後ExO）への移行をやったのですが、あまりにも前提条件が独特すぎて大変だったので記事にします。

二つのサポート外

現行ExchangeがExOの移行機能のサポート外

現行のExchangeがオンプレ環境ではなく、サービスを利用しており、そのサービスがExOの移行機能をサポートしていません。
ExOには以下のような移行機能・方式があるようですが、残念ながら使えません。

Exchange Onlineで移行パスを決定する

Exchangeはサービス化されており、直接Exchangeを触り情報を採取をすることはもちろんできず、情報採取コマンド発行を依頼するも拒否され、提供されるWebコンソールからのみ操作可能な状態。
また、そのサービスはマルチテナント（一つのテナントを複数のユーザー組織が利用している）環境です。

SMTP Match 状態がMSのサポート外

移行前後で同じメールドメインを利用するのですが、移行期間中はExchange とExOでインターネット上に同じドメインが存在します。
その状態をSMTP Matchと呼称するようですが、この状態をMSがサポート外です。
※SMTP Matchという言葉はMSサポート回答から引用していますが、あまり一般的な用語ではないかもしれません。

ExOはもちろん、OutlookやWindows OSについてもサポート外となり、手探りで移行方式を検討することになります。

しんどいポイント

色々とサポート外
- QCDへのインパクト大
Exchange が触れない
- ユーザー情報の参照・取得等、コマンドだったら簡単なこともWebコンソールでやらないといけない
  - 最終的にRPA（UIPath）を利用しました。
    - これはこれで大変でした…
ExO移行をした業務実績にならない
- 今年の実務実績が空白になると思うと、徒労感がすごい

方式・方針・Tipsなど

問題が盛りだくさんなので、いくつかピンポイントで。

全体方針

一括移行はせず、以下の流れで段階的な移行をしました。
※ExOの移行機能と名前被っていますが、ExOの機能ではないです。

各ユーザーのExO有効化
Exchange-ExO間のメール転送
ユーザーでのメールデータの移行
ユーザーでの接続先サーバ切替
スケジュール・アイテムの移行
MXレコード切替

Exchange-ExO間のメール転送

以下の理由により、事前（数か月前）からサーバ間のメール転送をするように設定しました。

移行期間中は新旧の環境利用しているユーザーが混在するため。
4～6の期間、外部・Exchangeから送信したメールが、ExOに受信されないので参照できなくなるため。
切替後の利便性としてもExOのメールボックスに直近のメールが格納されていたほうがよいため。

IPスロットリング

上記の設定を行うと、大量のメールが両方のサービスで受信され続けることになります。
その場合、ExOのIPスロットリングに抵触し、受信を拒否されることが懸念されました。

IP スロットリングについて

IPスロットリングの閾値についてはセキュリティ設定のため教えてもらえず、IPウォームアップとして、徐々に転送設定を行うユーザーを増やしていく方法で対応しました。

IPウォームアップについて

Plannerへの影響

トランスポートルールでリダイレクト設定をした際、Plannerでタスクのコメントに入力した内容が消える事象が発生。
Plannerは内部的にメールを利用しているようです。
※ExO→Exchange →ExOとメールそのものは戻ってくるのですが、オリジンではなくなるからか、Plannerのコメントは見えません。
※ExOのトランスポートルールで設定するリダイレクトは、メールの複製ではなくオリジンを転送します。
※Exchangeの転送機能は複製を転送する機能でした。

そのため、Planner利用が業務上必須なユーザーはトランスポートルールで除外設定としました。

メールデータの移行

サーバ間の移行は諦め、現行のメールデータはユーザーにローカル保存してもらう方式としました。
一度に全ユーザーにメール保存・切替を実施した場合、社内NWへの負荷などが懸念されたため、段階移行としました。

メール保存については問題は多岐にありますが、ユーザー個別の事象多数のため割愛します。

メール接続先の切替

Outlookの接続先はこのように決定されるとのことです。

再起動のシナリオを確認する
ローカルデータの環境設定を確認する
前回の既知の有効 (LKG) データを確認する
O365 を優先的に確認する
SCP データを確認する
ルートドメインを確認する
Autodiscover ドメイン
ローカルデータを確認する
HTTP リダイレクトを確認する
SRV データを確認する
O365 のフェールセーフを確認する

現行が10番で向け先を決めていることがわかったので、それより優先度の高い7番で向け先を変更する方式にしました。
7番のAutodiscover用にCNAMEレコードを登録するのですが、それだけだと全端末が一斉に切り替わってしまうので、端末のレジストリを修正してAutodiscoverを参照するかを制御します。

ですが、実際に切替テストをしたところ、切り替わらない事象発生。
この事象の調査の中でSMTP MatchでMSサポート外と言われて見放されるわけです。

もともとの想定であるAutodiscoverの利用は諦め、Outlookの接続先設定時に、365アカウントにデフォルト作成されるエイリアスドメイン(onmicrosoft.com)を指定する方式に変更。
レジストリ変更もハードルがそれなりにあったので、結果的にこの方式に傾いてよかったとは思います。

スケジュールの移行

個人やアイテム（会議室・備品など）のスケジュール移行に関しては、以下の課題がありました。

Exchangeの個人スケジュールをエクスポートし、ExOにインポートすると、編集権限がない（別ユーザー扱いのため）
会議依頼時に開催者の個人スケジュールが同期されない（開催者にはメールが送信されないため）
Exchangeのアイテムにメール転送設定を行えない

移行期間中、メール切替後のユーザーはOutlookからExOの予定表利用を諦め、ExchangeのOWA（Outlook Web Access）をブラウザから利用してもらい、メール移行終わってからやるという方式です。

最後に

記載した以外にも問題は盛りだくさんで、だいぶ端折って書きました。
まだまだ移行途中で、最終的にどうなるかはわかりません。

こんな独特な条件・制約でExchange移行をする人がいるかはわかりませんが、もし役にたったらうれしいです。

２つのサポート外環境でのExchange移行