Office365のIMAP移行を試す話

2018年10月19日

Postfix + Devecot環境のメールシステムからOffice365への移行をすることになった。Office365のIMAP移行というのはよー分からん、ということで、試しにGmailのテストアカウントからOffice365への移行を行うことにした。

prius.hateblo.jp

環境

Office365の新規テナント契約

  • exoadmin@tokyoppp01.onmicrosoft.com
  • よく使われる8文字

テスト用Gmailアカウントの取得

  • tokyoppp01@gmail.com
  • よく使われる8文字 + 自分用7文字の5～大文字

IMAP移行バッチの作成

以下のマニュアルを参考に、移行バッチの作成を行う。

注意点は以下。

  • 2016/7/19時点では、新管理ポータルはプレビュー版なので、GUIからやる時は旧ポータルを使用する
  • おそらく、一度移行エンドポイントを作成後(今回の場合、GmailへのIMAP接続)は、2回目移行の利用でそれを利用できるので手順が異なる
  • 移行バッチには最大同期数の制限(100?)があるらしいので、抵触しないようにする
  • とはいえ、100以上のユーザーを同時に同期状態にするとネットワーク負荷が高くなりそうなので、順次移行を検討するのがよい。
  • 例：ユーザー数1,000人の場合、50人単位で移行バッチを実行し、同期が終了したら元メールシステムに転送設定を入れ、IMAP移行バッチ自体は解除する、など。
  • その他、移行できるアイテム数と1アイテムあたりの容量に制限があるので注意

結果

ほとんど空っぽなテストユーザーのデータが3分ほどで同期状態となった。この後は、24時間に1回くらいの頻度で差分同期が走るらしい。
つまり、これは大事なことなのだが常に元のメールシステムのデータが正であるということ。

実際の現場では

  1. 同期バッチ完了
  2. 元メールシステム→新メールシステムへの転送開始
  3. 24時間後の同期完了
  4. 同期状態解除

の順番でないとと、漏れるメールが発生する。3が終わってから4するのが大事。

こう考えると、移行バッチはユーザー1名1名単位で実装るのがよいか。1バッチ中の人数が多ければ細かい転送設定制御ができず、ネットワークトラフィックに無理が出てしまう…。

コマンドライン

以下の様なものが用意されているらしい。

  • Complete-MigrationBatch
  • Get-MigrationBatch
  • Get-MigrationConfig
  • Get-MigrationEndpoint
  • Get-MigrationStatistics
  • Get-MigrationUser
  • Get-MigrationUserStatistics
  • New-MigrationBatch
  • New-MigrationEndpoint
  • Remove-MigrationBatch
  • Remove-MigrationEndpoint
  • Remove-MigrationUser
  • Set-MigrationBatch
  • Set-MigrationEndpoint
  • Start-MigrationBatch
  • Stop-MigrationBatch
  • Test-MigrationServerAvailability

New,Remove,Set,Start,Stopは手動でやるとして、Get系はエビデンスを取得するために使えそう。あとはTestか。

追加検証

GB単位のGmailアカウントはどれくらいで移行できるんだろう?と興味があったので今やってます。

Posted by tera