y2blog

Postfix + Dovecot で組んだメールシステムをクラウドメールサービスへ移行してみる

１年ほど前の記事で、Linux上にPostfix/Dovecotで組んだメールシステムをAWSのクラウドサービス（AWS WorkMail）へ移行する方法について紹介したが、WorkMailの将来性を考えると、個人用とは言え、メインのメールシステムをWorkMail上に移行するのは躊躇してしまう．

ここ１年ほど、MSのビジネス用のOffic 365（現在はMicrosoft 365と改名）サービスを契約して独自ドメインで運用しているので、個人用のメールシステムについても、このビジネス用のOffice 365環境（テナント）へ移行してみることにした．

同様なサービスとして Google Workspace（旧Google Suite）があるが、どちらも似たようなサービスなので、どちらを選択するかはスタンドアローンベースのOfficeアプリを使いたければ、Office 365 “Business Standard” プランを選んでおけば良いだろう．WEBアプリベースで全て済むのであれば、MSの余計なお節介機能が満載のOfficeアプリよりもGoogle Workspaceの方が使い勝手が良さそうだ．

今回は既存の “Business Standard” プランのライセンスが既にあるので、既存のライセンスとは別に”Business Basic” 540円/月（年間サブスクリプション契約）を追加購入（評価用のライセンスも利用可能）し、テナント上にメール専用のユーザを追加し、メールボックスを割り当てることにする．

“Exchange Online (plan 1）” という単独のサービスの方が、430円/月（年間サブスクリプション契約）と安いが、”Business Basic”プランには 1TBのOneDriveストレージが付与されているので、”Business Basic”を選択する方が得策だ．

Office365 Exchangeメールサービスへの移行に当たっての検討事項

Office365 Exchangeメールサービスに限らず、メールシステムを別なメールシステムに変更する際に検討しなければならない事として、
　・既存メールデータの移行方法
　・メール配送切り替えの手順（DNS設定変更や新旧メールスプールのデータ同期方法など）
　・Thunderbirdなどの既存メールクライアントからのアクセスが可能かどうか

が代表的な事項だろう．

先ずは既存メールサーバからメールデータを移行する方法について、MSのドキュメントを探してみることにする．“What you need to know about migrating your IMAP mailboxes to Microsoft 365 or Office 365” というドキュメントが用意されているので、このドキュメントの内容に一通り眺めておくと良いだろう．

このドキュメントによると、MSではOffice365サイト管理者の管理コンソール（Exchange Admin Console）を通じて、IMAPをサポートしているメールサーバからデータを移行するツールを提供しているが、移行可能なデータはユーザのinboxメールフォルダまたは他のメールフォルダーのみで、アドレス帳やカレンダー、タスクデータなどは移行対象外だそうだ．Exchangeと異なり、普通のメールサーバはこのようなデータは扱わないのでメールデータだけ移行できれば問題ないだろう．

その他の制限事項として、１ユーザあたりの移行可能なメール数は500,000通で、一通あたりの最大サイズは35MBということだ．馬鹿みたいな巨大サイズの添付ファイルが存在していれば制限に引っ掛かる可能性があるが、一般的なメールの運用であればこの制限は問題にはならないだろう．

移行の大まかな手順はこのドキュメントに記載されているので、この手順になるべく従って移行を実施していくことにする．移行元のメールサーバが Google Workspace の場合のドキュメントに関しては、“Migrate consumer Google Workspace (formerly G Suite) mailboxes to Microsoft 365 or Office 365” という記事に、具体的な操作画面を含めた詳しい手順が載っているので、こちらを参考にした方が分かり易いかもしれない．GoogleからOffice365へユーザを移行させたいということなのだろう．

関連するドキュメントへのリンクを幾つか挙げておく．

　“Tips for optimizing IMAP migrations in Exchange Online”

　“CSV files for IMAP migration batches in Exchange Online”

Step 0: 移行検証用の既存メールサーバのクローン環境の準備

この作業は本番移行作業を行う前に、本番環境への影響を避けるために用意するもので、この記事のために用意する一時的なPoC環境の作成だ．勿論この記事を公開する段階ではこのPoC環境は閉鎖している．

個人用のメールサーバシステムは、Vultr社のプライベートクラウドサービス上に構築してあるので、先ずはこのVPCサーバのクローンを作成する．クローンの作成は管理コンソール上から簡単な操作で行うことが可能で、今回はスナップショットを取り、そのスナップショットから新規にクローンサーバを構築している．

クローンサーバの構築が終わったら、本番環境と同じFirewall設定をこのクローンサーバに適用する．後は検証用のドメインのDNSサーバにこのクローンサーバに外部からアクセスさせるためのDNSレコードを記載する．今回は、このサイトのドメイン “y2tech.net” を一時的に利用することにした．本番環境のメールサーバにはサーバ証明書を組み込んで暗号化通信に対応させているが、勿論この証明書は別ドメインでは使えないので現在使用していない同じドメインの別なサーバ証明書を用意した．（検証環境ではあるが、本番移行環境と極力同じ条件で行わないと、いざ本番という時に上手く行かないことが多いので今回は敢えてサーバ証明書を用意した）

クローンされたメールサーバのドメイン関係の設定は本番環境の設定になっているので、検証用のドメインに合わせて書き換えておく．準備ができたら、新しいドメイン環境でメールのやり取りが正常に行えることを確認しておく．

Step 1: 移行用のExchangeメールサービス環境を整える

ここからが通常の本番移行用の作業ステップとなる．先ずは、Microsoft Office365 の管理コンソール(管理センター）で、メールユーザのアカウント作成、Exchangeメールライセンスの割り当て、移行元のドメイン（今回は検証用の “y2tech.net” ）をOffice 365ユーザテナントに登録する作業を行う．

登録するドメインがこのテナントユーザが所有しているものであることを証明するために、今回はドメインの権威DNS上に、Microsoftから指定された確認用のTXTレコードを配置する方法を選択した．

MSから指定されたDNSレコードの情報をDNSサーバに追記すれば、Office 365のExchange サービスを利用するための環境が整うことになる．MXの優先度やTTLなどは自分の環境に応じて適宜変更しておく．

※このMXレコードをDNSに登録した時点で、外部からのメール配送ルートが影響を受けてしまうので、新旧メールサーバ間のデータの同期方法を慎重に検討した上で、MXレコードの切り替えタイミングを決める必要がある．

ユーザドメインの登録を完了させるためには、追加したDNSレコードの内容が正しく反映されたことをMS側が確認した後、最終的にドメイン追加処理が完了する手順になっている．この段階で新しいMXレコードの情報がインターネットへ伝播されてしまっているので、 “abcdefg@y2tech.net” 宛てのメールは、新しいExchangeサーバである”xxxxxxx.mail.protection.outlook.com”へ届けられてしまうことになる．新しいMXレコードの情報がインターネット側へ完全に浸透するにはそれなりの時間を要するので、この間旧メールサーバ宛てに届いたメールは問題なく処理されるが、”xxxxxxx.mail.protection.outlook.com”へ届けられてしまったメールは、ユーザアカウントがまだ登録されていないので、ユーザ不在で送信元にバウンスされてしまう可能性がある．

『鶏が先か卵が先か』状態になってしまったので、DNSレコードを書き換える前にユーザ登録の方を先に済ませておくことにした．幸いなことに、ユーザドメインの認証（所有証明）が済んだ段階で、新しいユーザをこの新しいドメイン配下に作成することができるようなので、先に移行するユーザのメールアカウントを作成しておく．

Exchange サービスのライセンスも有しているのであれば、この時点でライセンスもユーザに割り当てておくと良いだろう．ライセンスを割り当てて置かなくても、とりあえずユーザのメールボックス（スプール）は確保されるのかもしれないが、確実に移行するには最初からユーザにライセンスを割り当てておいた方が良いと思われる．

移行用のユーザのアカウントとメールスプールが正式割り当てられたので、ここで先ほど未完了だったユーザドメインの登録作業を再開する．ユーザドメインの権威DNSサーバへ、指定されたDNSレコードを登録する．DNSレコードの登録が完了したら、ドメイン登録処理を完了させることができるようになる．

ここまでの作業で、移行するユーザのメールが新しいExchangeサービス環境へ届くようになるが、インターネットの隅々までにこの新しいMXレコードの情報が反映されるまでには暫く時間が掛かるので、旧メールサーバのログを逐次確認しながら、旧メールサーバ側へメールが配送されなくなった事を確認しておく．

新しく作成したExchangeメールアカウント宛てのメールが正しく受信されていることと、外部へメール送信ができることを確認できれば、新しいメールサーバの構築作業は完了だ．

---

STEP 2: 旧メールサーバ上に残っているメールデータを新環境へ移行する

Office 365のExchangeメールサービスでは、他のメールサーバからデータを移行するツールをExchange管理コンソールから呼び出して、メールデータの移行を行うことが可能だ．あまり複雑な移行はできないようだが、外部のIMAPメールサーバにあるユーザのメールスプールデータを単純にExchangeサーバ側に持ってくることが可能だ．

この移行ツールは対話形式で設定を行いながら移行作業を進めて行くように作られており、詳細な設定ができないようなので、PowerShellなどのコマンドライン操作に慣れているのであれば、そちらの方が便利かもしれない．とりあえず、手順に従って移行バッチ処理を作成し、実際に移行作業を行ってみる．

移行作業が完了したら、実際にメールデータの取りこぼしがないか確認しておくと良いだろう．

今回は個人用のメールデータの移行だったので、メールの数も4,000件程度（１時間程度）で済んだので、この程度の簡単な備え付け移行ツールで対応できたが、大きな組織のメールサーバの移行でこのツールが実用になるかどうかは何とも言えない．尤もこのような環境では、専門のSIerさんが移行作業を行うのが一般的なので、このツールが使えなくても大した問題ではないだろう．

長々と手順を紹介してきたが、既存のIMAPベースのメールサーバから Office 365 Exchange 環境への移行を実際にやってみると、思っていたより簡単に移行可能であることが判ったので、折りを見て本番環境のメールサーバをクラウド上のフルマネージド型のメールサービス（多分Google Workspace）へ移行することにしようと思う．