Zenn
🐜

Google Workspaceのお引越し手順を公開するぜ

2022/01/24に公開
Google Workspace
tech

Ubieには、Ubie Discovery(UD)、Ubie Customer Science(UCS)といくつか組織があるのですが、歴史的経緯で、それぞれ別々のGoogle Workspace環境を構築して使っていました。しかし、両組織が密に連携して仕事を進めていくにあたって、Workspaceが分かれていることによるデメリットが大きくなってきたため、UCSのGoogle WorkspaceをUDに統合することになりました。たとえば、Meetが組織外になるとか、カレンダー連携がやたら面倒とか、Driveでの共有が組織外扱いになるとか、まあ色々あります。
環境としては、移動対象のテナントに75ユーザ/20グループが存在する程度の規模感です。

統合作業は、皆が年末休みに入った12/28に一人で実施して、ダウンタイムなしでほぼ2hで終わりました。他の諸々の作業入れても半日かかってないです。

この記事では、ダウンタイムなしで、ドメインを変更せずにGoogle Workspaceのテナント引っ越しを行う方法を記載します。

Googleテナント引っ越しの課題 - メールのダウンタイム

Google Workspaceのテナント間のお引越しについては、Googleさんは、あまり良いツールを提供していません。同じサービスの中でテナントを引っ越すだけなのに、メールの移行は、IMAPでだらだら流し込むData Migration Serviceしかないし、G Driveはテナント間でOwnerを変更する機能もない状態。Groupに至っては、exportの機能しかなくて、importするには、Web APIを使ったコードを書かないといけない。
中でも、お引越しにおける最大の課題は、ドメインの引き継ぎです。Google Workspace内部のテナントで利用されているドメインは、そのドメインを使っているテナントがドメインをテナントから削除しない限り、他のテナントで使うことができません。
Google Workspaceを使っている組織は、Gmailをドメインの主要なメールサーバとして使っていると思うので、この「ドメインを削除しないとお引越しできない」という点が最大のネックです。ドメインを削除してしまうと、移行が完了するまでの間に届くメールは、Gmailに届いた段階で配送先不明で送り返されます。したがって、Google Workspaceのテナントを引っ越す際には、メールのダウンタイムをいかにして避けるかが最大の課題になります。マニュアルによると最大24hとか書かれてますし、Chromeのライセンスが原因で移行が大変になるケースもある[1]ようですし、備えあれば憂いなし、ということで。

Ubieがこの予測不能なダウンタイムを避けるために取った作戦は、「お引越し対象のドメインのMXをあらかじめO365に向けてしまう」という作戦です。

Google WSのお引越しにExchange Onlineを活用する

Google Workspaceを運用している組織であっても、Microsoft Officeを併用せざるを得ず、Office 365の環境を併用して運用しているところが多いと思います。Ubieも例外なく、Office 365とGoogle Workspaceの両方を運用しています[2]。
Office 365については、おそらくTeams Exploratoryという、Teamsのライセンスが評価版として付与されているケースが多いと思います。弊社のようにSlackを使っている組織には、はっきり言って無用の長物なのですが、太っ腹なMicrosoftさんは、このTeams ExploratoryにExchange Online(Plan1)相当を一緒にセットしてくれているのです。今回の75ユーザくらいの小さな環境の場合、Exchangeのメールボックスが移行対象メンバーを補うくらいにはタダで使える状態になっている、ということですね。これを活用しない手はありません。

弊社の作戦はこうです。

  1. 移行の1week前に、UCSのドメインのMXレコードのTTLを短くしておく (300 = 5分とかに)
  2. 移行対象のユーザ/Group用のメールボックスをExchange Onlineに用意しておく (ユーザはExchange Online Plan1をアサイン、GroupはShared Mailboxで)
  3. 移行作業開始前に、MXをExchange Onineに変更する。届いたメールはEOPのMail Flow RuleでUCSのGmailに転送している状態。
  4. Exchangeのメールボックスで転送ルールを有効化する。
  5. ドメインをUCSのGoogle Workspaceから削除する前に、EOPのMail Flow Ruleを無効化して、届いたメールが全て新環境のUDのGoogle Workspaceに転送される状態にする
  6. 移行完了後、UCSのドメインのMXをGmailに戻す

ちなみに、4のExchangeのメールボックスでの転送ルールを2の段階とか先にやらない理由は、メールボックスに設定する転送ルールは、なんとEOPのMail Flow Rule(手順3で設定)より優先度が高く実行されてしまうから。EOPの方が先にメールを受信するから、先に動いてほしいのだけど、Exchange Onineの場合はどうもEOPのルールを先に処理させることができない仕様のようです。

事前準備

この方法を取るために、お引越し先となるUDのGoogle Workspaceには、一時的なドメインを付与して移行先となるアカウントを事前に用意しておきます。たとえば、お引越しするドメインがexample.comだったとして、お引越し先のGoogle Workspaceには、ucs.example.netのようにどこにも使われていない一時的なドメインでアカウントを作っておく、という感じです。
また、お引越し元の環境でも、別のドメインをsecondaryに登録しておく必要があります。これは、移行完了後に前の環境にアクセスするのに必要なドメインになります。たとえば、test.example.comのようにサブドメインを登録しておく、という方法でも大丈夫です。

O365→Gmailへの転送方法

O365(Exchange Online Protection: EOP)からGmailにメールを転送するルールは、ConnectorとMail Flow Ruleを組み合わせて設定します。

  1. EOPからGmailに転送するためのコネクターを作ります[3]。
    • Mail Flow Rule (旧Transport Rule)があるときだけ使う設定にします。
    • Google WSのMXとして記載されているサーバを登録する (まあ3つもあれば十分か)
    • TLS必須とする
  2. 作成したConnectorに送信するMail Flow Ruleを設定します。
    • 移行対象のドメイン宛のメールを対象にします。(この例ではexample.com)
    • ActionにConnectorを指定します。

なお、この方法にはGmail側でSPF/DKIMの検証が失敗する、という課題があります。
EOPが受けてGmailに転送しているため、SPF/DKIMの検証がGmail側で実施できません。つまり、転送されたメールが、spam判定されるリスクが高い、という問題があります。
ホワイトリスト(Inbound Gateway)を設定して、Gmail側でこの検証をスキップすることも考えられますが、O365が転送に利用するIPアドレスレンジは絞れないのと、そのIPレンジは、他のテナントでも使われるIPなので、ホワイトリストに書くのは非推奨です。

つまり、EOP -> Googleの転送は最小限にしないといけないので、弊社の場合は、移行作業中だけのごく短い時間のみ、この転送ルールが使われているような状態で移行しました。

Exchange OnlineのmailboxからGmailへの転送

Exchange OnineのMailboxからのGmailへの転送は、MailboxのForwarding機能を使います。これは、EOPのMail Flow Ruleでは、envelopアドレスを書き換えて転送することができないためです。
手順4の作業は、移行対象のアカウントそれぞれについて、CSVファイルを用意しておいて、Powershellで一気にやります。CSVファイルforwarding.csvには、IdentityとForwardingAddressという2つのカラムを用意しています。

$ Connect-ExchangeOnline -UsePrincipalName <adminのアカウント>
$ import-csv -Encoding default .\forwarding.csv |
foreach-object { set-mailbox -Identity $_.Identity
 -ForwardingAddress $_.ForwardingAddress }

この設定変更により、たとえば、Exchange Onlineのメールボックスにmasato@example.com宛に届くメールが、masato@ucs.example.netに転送されて、新環境のUDのGmailに届く、という動きになります。Envelopアドレスだけを書き換えるので、メーラーでメールを読むユーザの見た目には一切影響がありません。

転送設定が有効になっていることは以下のコマンドで確認できます。

Get-Mailbox | where {$null -ne $_.ForwardingAddress} | FT Identity,ForwardingAddress

データ移行についての弊社の方針

データ移行がテナントをまたぐとめちゃくちゃ大変、ということで、弊社は以下の方針でやりました。もっと良い方法があるかもですが、スピードを優先しています。

  • Gmailのデータは、Data Migration Serviceを使って移行
  • GDriveのMyDriveのデータは各自で移動
    • これがなかなか難物で、UCSの共有ドライブに本人専用の共有ドライブを作り、新環境のUDのアカウントを招待。そこにMydriveのデータを移動して、さらにUCSの共有ドライブから、新環境のUDのアカウントのMyDriveに移動、という多段の移動をしないといけません。
    • この移行に際しては、フォルダ単位での移動を許すため、管理者の権限をユーザに一時的に付与する必要があります。(Admin RolesのMove any file or folder into shared drivesの権限が必要)
  • Calendarは移行せず、新しい環境で作り直してもらう
    • テナントの移行を行うと、MeetのIDの変更だったり、会議室リソースの予約し直しが必要だったりするので、新しく作り直してもらうように依頼
    • 個人のカレンダーの移行については、旧環境のカレンダーの閲覧権限を新環境のユーザに許可したり、新環境のセカンダリーカレンダーにimportする方法を案内
  • Google Groupは、オーナーにデータをexportしてもらい、GroupsMigration API[4]を使って新環境にimport
  • Keepのデータなど、その他の多くのデータは、自力で頑張ってもらう方針 (Google Takeoutを使う等)

移行全体の手順

Ubieが移行の際行った手順を全部公開するぜ。まずは、移行作業日前日までの流れ。

  1. UDのGoogle WSに、移行対象となるUCSユーザのアカウントを作成 (ドメインは一次ドメインのucs.example.netのようなドメイン)
  2. UCS用のGoogle Groupsをお引越し先のUDのGoogle Workspace内部に作成 (ドメインは一次ドメインのucs.example.netのようなドメイン)
  3. 移行アナウンスを作成して案内 (移行の2week前)
  4. UCS用の会議室リソースをお引越し先のUDのGoogle Workspace内に作成
  5. ユーザにアナウンスして、Data Migration Serviceによる移行を実施 (移行作業の1w前)
  6. Exchange Onlineのメールボックスを用意 (移行対象ユーザとGroup分)
  7. Google Domainsにて、移行対象ドメインのMXのTTLを300に設定 (12/24に実施)
  8. 作業前日夜間にUCSのドメインのMXをEOPに変更、メール転送が動いている状態を確認 (12/27に実施)

続いて、移行作業実施日の作業の流れ。

  1. (UCS O365) PowershellでUDのGoogle WSのアドレスに転送するForwardingAddress設定を実行する (上に書いたPowershellのコード)
  2. (UCS O365) UCSドメイン宛のメールがUDのGoogleのメールボックスに転送されていることを確認
  3. (UCS O365) Azure ADのfederationを停止 (ドメイン切り替えが自動同期されるのを防ぐ)
    • Powershellで、connect-msolserviceでAzure ADに接続し、set-msoldomainauthenticationコマンドレットで切り替えます。
  4. (UCS Google WS) Web AppのAuto provisioningを無効化
    • ドメイン変更の影響伝搬を避けるため、念の為Auto Provisioningを無効化します。
  5. (UCS Google WS) まずは作業を一緒に行う相棒の管理者アカウントで、作業者である私のアカウントについてexample.comのドメインから、サブドメインのtest.example.comへprimary domainを切り替える作業を行います。自分で自分のアカウントのprimary domain変更はやりたくないので。
  6. (UCS Google WS) 切り替えてもらったtest.example.comのアカウントで環境に入り直して、Google WSのテナントのPrimary DomainをSecondaryのtest.example.comに切り替える。
    • この時点では、既存のアカウントはまだ切り替わっていない。テナントのprimaryが変わっただけ。

  7. (UCS Google WS) 全ユーザのprimary domainを切り替え&alias削除します。これは、お引越し対象のドメインexample.comを持ったユーザが一人でもいると、ドメインをテナントから削除できないからです。
    • 今回は75ユーザいるので、あらかじめGASを書いておいて、一気に切り替えました。
    • なお、GASでprimary emailを変更すると、お引越し対象のドメインをAliasとして足されてしまうので、これもスクリプトで同時に消すように実装しました。なお、追加されるまで若干のタイムラグあるので、1secくらいdelayを入れるのがおすすめ。
  8. (UCS Gogle WS) 続いて、全グループのprimary domain切り替えとalias削除を行います。
    • 今回は20グループくらいでしたが、やはりGASを書いておいて、一気に切り替えました。
    • ドメイン変更時にAliasが足されてしまうのはユーザ同様なので、delayを入れてから削除するスクリプトにしています。
  9. (UCS Google WS) example.comを使っているユーザとgroupがいなくなったので、ここでsecondary domainになっているexample.comを消します！ (aliasとかで残っていなければあっけなく消えます)
  10. (UD Google WS) 新環境となるUD側にexample.comを追加します。Google Domainsを使っている場合だからかもしれませんが、弊社の場合は削除後一瞬で登録できました。
    • 以下のSlackのスクショの手順16がUCSテナントからドメインを削除する手順でした。(テナント移行に関しては、Google Domainsにしておくのが一番の幸せなのかもしれない。)
  11. (UD Google WS) UDの新環境では、ucs.example.netのような一次ドメインでユーザが登録されているので、GASを使って一気にexample.comに変更します。
    • 一次ドメインのメールは、変更後にAliasとして追加されます。今回はこのまま維持します。(O365からメールが転送されるので)
  12. (UD Google WS) UDの新環境にて、UCSのGroupについて、同じ用にドメインをucs.example.netのような一次ドメインから、example.comに変更します。これもGASで一気にやります。
  13. これで、旧環境のドメイン宛のメールが、新環境で受信可能な状態になっているので、いよいよDNSサーバにて、MXをO365からGoogleに戻します。
  14. (UD Google WS) メールが新環境のGmailに配送されるか試験します。

あとはユーザのアクセプタンステストをして移行は完了です。
このあとは、移行中にメール転送で使っていた旧UCSのO365環境のメール転送ルールを切ったり、O365のドメインを切り替え後のtest.example.comに変更し[5]、旧環境のアカウントでSSOで入れるようにFederationを切り替えたり、といった後片付けをやれば終わりです。

弊社の場合、GASをあらかじめ全部準備しておいたので、ここまで一人で2h程度でお引越しできました。

あとは、Data Migration Serviceでユーザのメールをお引越ししてあげて、年末を迎える前に、メールデータは全て移行が完了しました。
実際には、アナウンスを見てない人がいたりして、年明け業務開始時にメールを移行してあげる作業をやったり、といった少し反省すべき点が出ましたが、何とかメールは取りこぼさず、ダウンタイムなく切り替え作業を終えました。

Google Groupを移行するGoのコードとか、上で使ったGASのコードとかは、はっきり言って初心者丸出しなので、まあ要望ありそうならどこかで出します。

最後に

Google Workspaceのお引越ししないとな〜というとき、弊社の経験がお役に立てれば幸いです。

ちなみに、弊社では、統合されたGoogle Workspace内をさらに便利にかつ安全にしつつ、TerraformでOUやGoogle Groupを管理したり、OPA/Regoでポリシー書いて監視したり等々、情シスもShift Leftの活動に皆で取り組んでいます。会社の人数も180人近くなってきて、いよいよ兼務では回せなくなってきました (自分の本職はInformation Securityなのだ)。

情シスのJDを公開してしばらく経つのですが、なかなか人を集められない(泣)。誰か助けて、ということで、こんな面白い活動やっているUbieの情シスに、少しでも興味持った方連絡ください。

Meetyも開けているので、お気軽にコンタクトしてください。この記事の詳細聞きたい、というのでもかまいません。

脚注

  1. ペパボテックブログの「Google Workspaceのプライマリドメインを変更しました」の記事。これを読んで、うちの手順も共有すると良さそうか、と思ったのがこれを書くきっかけ。 ↩︎

  2. Office 365: GoogleをメインのIdPに使う構成方法という記事も書いてます。 ↩︎

  3. Connectorは、メールの転送を行って検証に成功した宛先しかRouteに追加できないので注意。 ↩︎

  4. 自分は、Goでコマンドラインプログラムを作って、ローカルに保存したmboxファイルを読み込みながらWebAPIで流し込むプログラムを作って対応した。これが、パラレルで放り込めない仕様なので、5GBとかあるグループは、数日がかりだった... なんかいい方法ないかな。 ↩︎

  5. O365ですが、今回のように最初使っていたドメインがexample.comで、移行後のドメインがこのサブドメインのtest.example.comとなっている場合、親ドメインのexample.comドメインが登録された状態だと親ドメインを削除できない、という仕様になっています。なので、test.example.comを追加したあと、example.comを消す、という操作を受け付けてくれないので、example.comを消して、test.example.comを追加する、という順番でやらないといけません。したがって、既存のアカウントのドメインを全部一度onmicrosoft.comドメインに退避して、親ドメインのexample.comを消して、その後test.example.comを登録して、ユーザアカウントのドメインを付け替える、という作業が必要です。意外と面倒。 ↩︎

Discussion