2025年1月7日 / 最終更新日時 : 2025年3月5日 officeの杜 Google

Google Workspace MigrateでMicrosoft365からお引越し - サーバー構築編

前回の記事ではGoogle Workspace Migrateを使ってMicrosoft365からのお引越しの事前準備についてまとめました。これだけでも相当ハードルがありますが、それでも移行をすると覚悟決めることが出来ましたら、いよいよ実際の移行作業を行います。

本エントリーは、実際にGWMを使っての移行用のサーバ構築を行います。Compute Engineを利用してサーバーを構築することになります。

目次

今回利用するツール

最低でも4台、Compute Engine上にVMを立てて、Windows Server 2019以上の環境を構築する必要性があります。規模が大きい場合にはTerraformを使ってVMを一括で立てると環境構築時間の短縮に繋がります。

本エントリーではGCP側、GWS側を行ったり来たりしますので、１つずつ丁寧に追って移行作業を行いましょう。

Google Workspace MigrateでMicrosoft365からお引越し - 事前準備編

事前準備

2024年8月に大きな変更がMicrosoft365側で生じており、これまでの手順とはかなり違う手順となっていて自分は大ハマリしました。これまでのアカウントベースからClient ID/Secretベースに切り替わってる為、Azure Portal上でも作業が発生します。

Microsoft365側準備

Exchange Online

管理者アカウントの準備

Exchange管理センターに於いて、以降に利用する管理者アカウントに対してGWM用の権限を付与する必要があります。以下の手順で付与を実行します。

  1. Exchange管理センターを開く

  2. 左サイドバーより、役割=>管理者の役割を開く

  3. 役割グループを追加するをクリックする

  4. 基本設定での名前は、GWM用管理者ロールとでも入力して、次へをクリックする

  5. アクセス許可を追加では、以下の4つの権限を検索してチェックを入れて、次へをクリックする。ApplicationImpersonationについては廃止されてるので追加しない

  6. 管理者の割当にて管理者の割当に使うメアドを指定する。Sharepoint同様、Microsoft365の特権管理者等で良い。次へをクリックする。

  7. 役割グループの追加をクリックする

  8. 完了が出たらクリック（稀にエラーになる場合はもう一度7.をクリックする）

また、重要なことですが、この管理者アカウントにもメールボックスがついている必要がありますので、メールボックスなしだとエラーになります（The Admin email is invalid or has no mailbox associated with itというエラー）

図：役割の追加を行う

図：メールボックスが無いとエラーになる

アプリの登録

GWM Version 2.4.18以降、これまでのExchangeの特権アカウント方式ではなく、Azure Portal上で作成するClient ID/Secret方式に変更になっています。こちらが最新版のAzure Portal上でClient ID / Secretを作成する手順になります。(この変更はM365側で2024年8月にこの変更があっての対応となっています。)

また、テナントのIDも必要となるため、3つの値を事前に用意する必要があります。

  1. アプリの登録にて登録を開始する

  2. 新規登録をクリックする

  3. 適当なアプリ名称をまず入れます。

  4. この組織ディレクトリのみに含まれるアカウント (xxxxxのみ - シングル テナント)を選択する

  5. リダイレクトURIは空っぽのまま登録をクリックする

  6. 作成したアプリの中にはいってみる

  7. 次に左サイドバーのAPIのアクセス許可をクリックする

  8. アクセス許可の追加をクリックする

  9. 所属する組織で使用してるAPIタブをクリックする

  10. 検索窓で、Office365 Exchange Onlineと検索すると出てくるのでクリックする

  11. アプリケーションの許可をクリックする

  12. full_access_as_appにチェックをいれて、アクセス許可の追加をクリックする

  13. 元の画面に戻ったら、xxxxに管理者の同意を与えますをクリックする（要管理者権限）。状態が緑色のアイコンになります。

  14. 左サイドバーより、「証明書とシークレット」をクリック

  15. 「新しいクライアントシークレット」をクリックする

  16. 今回は6ヶ月の期限を選択するのでそれをクリック。後で不要になったら失効すれば即座に使えなくなります。追加をクリックする。移行期間に合わせて期限を切ると良いでしょう。

  17. これで値に「クライアントシークレット」が生成されて手に入りました。このシークレットはこの時だけしか表示されないので、注意してください（シークレットIDではないので注意）

  18. 次に左サイドバーの概要をクリックする

  19. 画面にアプリケーション (クライアント) IDが表示されてるので、控えておく（これがクライアントIDとなる）

  20. 同じく、ディレクトリ (テナント) IDが表示されてるので、控えておく（これがテナントIDとなる）

これで、Exchangeで接続してGWMで移行する為に必要なMicrosoft側の情報を集めることができました。Google Workspace Migrateの公式トップページからは、今回の手順のドキュメントではない古い手順のドキュメントへのリンクしか存在しないので要注意です。

図：Client IDとTenant IDの取得

図：API許可の追加画面

移行ユーザの一覧の取得

移行対象ユーザの一覧としては通常のユーザおよび共有メールボックスのアドレスの2つが必要です。Entra IDからでも出せなくはないですが、ここはわかりやすくExchange管理センターから一括でCSVで出力するのがベストでしょう。

  1. Exchange管理センターを開く
  2. 左サイドバーの受信者→メールボックスを開く
  3. 右パネルに一覧が出てくる。受信者の種類がSharedMailboxが共有メールボックスのアドレスで、UserMailboxが通常のユーザです。
  4. メールボックスのエクスポートをクリックする
  5. すべてのメールボックスをエクスポートするをクリックする
  6. CSVファイルがダウンロードされる
  7. ExcelやLibreOfficeなどで開いてみると一覧が出てくる

共有メールボックスを除外したい場合にはこの一覧からSharedMailboxのレコードだけ削除しておけば良いでしょう。

図：メールボックスのリストを取得

図：ユーザ一覧のCSV

Sharepoint Online

認証情報の作成

GWMにてMicrosoft365のSharepoint側からデータを引き抜き、Google Workspace側へと転送する為に必要な作業が「Client IDとSecretの取得」になります。以下の手順で発行しますが、Azure Portalで発行するわけじゃない点に注意。ただ、2026年に以下の手法でのクライアントID/シークレット取得であるACSが廃止されるらしい。故に、Entra IDからのアプリの登録による手法を使う必要性があるようです。

  1. 以下のURLにアクセスして、移行元のアカウントでログインする

  2. クライアントIDとシークレット横の生成ボタンをクリックする

  3. ソレ以外の情報を入力する

  4. 作成ボタンをクリックする

  5. 生成されたクライアントIDとシークレットをメモしておく（後で利用します）

  6. OKをクリックして閉じる

  7. 次にSharepoint管理センターの以下のアドレスにアクセスします。

  8. アプリ権限の付与というページが出てくるので、アプリIDにクライアントIDの値を入れて参照をクリック

  9. 次に権限の要求XML欄には以下の値を記述する

  10. 作成をクリックする

  11. 信頼しますか？というメッセージが出るので、信頼するをクリックする

これで、Sharepointにアプリとして登録されましたが、この登録済みアプリを確認したい場合があります。その場合は以下の手順でアクセスして確認したり削除することが可能です。

  1. 以下のURLにアクセスする

  2. アプリのアクセス許可にある開くをクリックする

  3. 登録したアプリ一覧が出てくる。✗をクリックするとアプリが削除される

  4. また、以下のURLでも確認できる

  5.  これにて完了

 

図：確認画面の入口

Sharepointのファイルの整理

GWMによってSharepointのファイルはGoogle Driveの共有ドライブへと移行されます。しかし、Sharepointと異なりGoogle Driveの共有ドライブには以下の縛りがあるため、移行前にSharepoint側で事前にファイルの整理をしておく必要性があります。

  1. 共有ドライブはディレクトリ構造が最大100階層までの制限があるため、Sharepoint側でソレ以上の階層がある場合には、別のサイトを作って分散や隔離をして100階層以下の状態にする必要があります。

  2. 共有ドライブは1ドライブ最大50万ファイルの制限があるため、Sharepoint側でソレ以上のファイルが格納されてる場合には、別のサイトを作って分離して50万ファイル以下にする必要があります。

  3. 共有ドライブはドライブにアクセス権限を付けた場合、下位のディレクトリに対しても権限が必ず継承され外せません。故に下位ディレクトリに別の独立した権限を付けてるものについては、別のサイトを作って分離するか？移行後に別のドライブを作成して移動し、別の個別の権限を付与する必要があります。

  4. 1ファイル2GB以上のファイルについては、GWMが未対応であるため別のサイトに分離しておき、rcloneなどを使って移行が必要です。

エラーの原因となるため（403エラーがログに残る）、事前に上記の制限をクリアするようにファイルの整理整頓が必要になります。ファイル数の確認方法はこちらの手法が使えます。

※Sharepointのディレクトリ構造可視化ツールがほしい。エクスポートしたExcelデータを元に出来るか？

共有ドライブ内のフォルダに限定アクセス権限を付ける機能を検証

Sharepointサイト一覧の取得

GWMに於いてSharepoint上のファイルをGoogle Driveに移動させる場合には、移行対象となるSharepointサイトの一覧情報が必要になります。これを移行時の設定値として登録が必要になります。これを元に個別にブリッジを作成します。

  1. Microsoft365管理センターを開く

  2. 左サイドバーの下の方にある管理センターセクション内の「sharepoint」をクリックする

  3. Sharepoint管理センターが開かれる

  4. 左サイドバーのサイト⇒アクティブなサイトをクリックする

  5. 現在生きているサイトの一覧が出てくるので、上部にある「エクスポート」をクリックする

  6. CSV形式でサイト情報の一覧がダウンロードされる

  7. CSVファイルをExcel等で開いた際に、URLの列にある値がサイトのURLとなります（例：https://ドメイン.sharepoint.com/sites/サイト名）

図：サイトリストの取得

図：URLのリストを作る

Google側準備

GCPプロジェクトの作成

新規にGCPにプロジェクトを作成します。検証用と本番用はわけて作成するようにしましょう。以下の手順でGCPにプロジェクトを作成します。この時、GWSとリンクしてるGCPテナントで行うようにしましょう。GCPとGWSテナントを別々に作ってしまうと、後で面倒なことになります。

  1. GCPにログインする（課金可能な特権管理者のアカウントにて）

  2. 左上の「≡」をクリックし、IAMと管理⇒リソースの管理を開く

  3. 上部にあるプロジェクトの作成をクリックする

  4. プロジェクト名を入れて、組織が複数あるならば選択し作成をクリックする

  5. 右上の通知のプロジェクトを選択をクリックする

  6. 続けて、左サイドバーを開いてAPIとサービス⇒ライブラリをクリックする

  7. 以下のAPIを検索窓から探してすべて有効化する

  8. これでプロジェクトの作成と利用するAPIの有効化が終了しました。

尚これらAPIですが上限引上げ申請をしてみましたが、リジェクトされました。理由は利用状況に応じて自動的に上限は引き上げられるとのこと。

図：個別APIを有効化する

図：移行用の新規プロジェクトの作成

サービスアカウントの作成

作成上の注意点

2024年より、新規のGoogle Cloudテナント作成時におけるデフォルトの組織ポリシー変更が発生しており、検証環境を作ってもらったはいいけれど、いざサービスアカウントを作成しようとすると作成権限が無いとして作れないといったケースが発生しています。

対象になるポリシーは「Disable service account key creation」であり、デフォルトで有効化されてしまっています。テナント作成担当者に伝えて、このポリシーをfalseにしてもらう必要があります。

他にも別のドメインのユーザをテナントのIAMに追加するものもできなくなっているので、他のドメインユーザをプロジェクトに参画させる場合には解除が必要です。

作成手順

GWM側で利用するサービスアカウントを用意する必要があります。このアカウントは1本でオッケー(terraformもGWMも共用)。但し、共有ドライブ書き込みで利用するGWSのアカウントは20ドライブ当たり1アカウントくらいの見込みで事前にGoogle Workspaceの管理コンソール上で作っておく必要があります（CIPかGWSのライセンス割当も必要）。

以下の手順でGCP上でサービスアカウントを作成します。

  1. GCP画面の左サイドバーより、IAMと管理⇒サービスアカウントを開く

  2. 上部にあるサービスアカウントの作成をクリックする

  3. 適当なサービスアカウント名、説明文を入れて作成して続行をクリックする

  4. このサービス アカウントにプロジェクトへのアクセスを許可するでは、ロールは「編集者」をつける

  5. ほかは省略するので、完了をクリックして終わらせる

  6. 一覧に作ったサービスアカウントが出てくるので、アカウント名をクリックする

  7. 詳細が開かれるのでこの時表示されてる「一意の ID」をメモしておく

  8. 上部タブの「キー」をクリックして、鍵を追加⇒新しい鍵を作成をクリックする

  9. キーのタイプはJSONを選び、作成をクリックする

  10. JSONファイルがダウンロードされるので大切にキープしておく

作成したサービスアカウントおよびJSONキーは後ほど利用することになります。

図：サービスアカウントを作成中

図：一意のIDが重要です

OAuth同意画面の設定

GCPとGWSが同じドメイン内の場合

つづいて、GCPのOAuth同意画面の設定をする必要があります。

  1. 左サイドバーよりAPIとサービス⇒OAuth同意画面を開きます。

  2. User Typeは「内部」にチェックを入れて、作成をクリックする

  3. アプリ登録の編集画面が出てきますので、アプリ名は適当に入力、サポートメールは自身のメアドを選択する

  4. デベロッパーの連絡先情報にも同じくメアドを入力し、保存して次へをクリック

  5. スコープは追加せず保存して次へをクリック

  6. ダッシュボードに戻るをクリックする

これで完了です。

図：内部を選択します

GCPとGWSが違うドメインの場合

前述でGCPとGWSを別々にテナントを作ってしまうと面倒なことになる・・・と記述しましたが、まさにコレがそのケース。リンクしていないのでGCP側からしたらGWSが外部テナントになってしまいます。よってここでの設定を内部にしても通信が出来ません。

GWMにログイン時に確認をクリックすると、「エラーが発生しました。Googleで確認できたことは以上です」とだけ出て、ログイン自体できない現象に遭遇。しらべて見ると、OAuth同意画面にて以下のような設定をしてあげると通過できるようになりました。

  • ユーザの種類は内部ではなく「外部」にする必要がある
  • また、その際の選択肢としてはテストではなく「本番環境」にする必要がある。

テストではGWSの特権管理者のユーザを追加しても同じエラーに遭遇します。エラー内容はChromeのDeveloper Consoleで確認可能です。

図：意味不明なエラー

図：外部で本番環境にする必要がある

OAuthクライアントIDを作成する

続けて、同じAPIとサービスの「認証情報」をクリックして作業を開始する。

  1. 上部にある「認証情報を作成」をクリックし、OAuthクライアントIDをクリックする

  2. アプリケーションの種類は「ウェブアプリケーション」を指定

  3. 承認済みの JavaScript 生成元のURIを追加をクリック

  4. 「http://localhost:5131」を指定する

  5. 下の方にある作成をクリック

  6. Client IDが生成されるのでこれをコピーしてメモっておく

また、この時、GWMのセットアップ画面でログインしたのに「真っ白なポップアップ」が出て、エラーを見てみると、「The given origin is not allowed for the given client ID」的なエラーが出ていました。この場合の解決法はこちらにあるように、OAuthクライアントIDの承認済みJavaScript生成元には

「ポート番号を抜いたhttp://localhost」も追加する

ことで回避することが可能です。エラー内容はChromeのDeveloper Consoleで確認可能です。故にはじめから、2つの生成元URLを追加しておくと良いでしょう。

図：Client IDを作成出来ました

図：Client ID作成中の画面

ドメイン全体の委任

Google Workspaceの管理コンソール側でも作業が必要です。GCP側で有効化したAPIについてドメインの委任をする必要があります。Sharepoint, Exchange Online共通です。

  1. 管理コンソールを開く

  2. 左サイドバーからセキュリティ⇒アクセスとデータ管理⇒APIの制御を開く

  3. ドメイン全体の委任にある「ドメイン全体の委任の管理」をクリックする

  4. 新しく追加をクリックする

  5. 前述の項目でメモっておいた「一意のID」をクライアントIDに入力する（これはサービスアカウントの一意のIDであって、OAuthのクライアントIDではないので注意）

  6. OAuthスコープには以下の項目をカンマ区切りで追加しておく（こちらのドキュメントは間違い）

  7. 承認をクリックする

  8. 詳細を表示から中身は後で確認や書換が可能です。

なお、ドメイン全体の委任については危険性も指摘されているので、全作業完了後にはサービスアカウント含めて全部削除しておくことを推奨します。

図：ドメイン全体の委任を設定

図：設定していないとエラーになってしまう

サーバー構築

構築に掛かる時間

PlatformおよびDB2台と、Node Serverを40台構築する場合、手作業で行うとなると

  • Compute Engine上で各種サーバを構築する（ノード40台で1週間：2,3人日程度）
  • 構築したサーバに対してパラメータを設定する（1週間程度：3,4人日程度）

合計で2週間程度あればサーバの構築やパラメータ登録は完了できます（合計：5〜7人日程度）。あくまでも１人で設定する場合です。GWMで利用する各種パラメータ用のCSVやリストの準備まで含んでいます。

Terraformで一括作成

概要

前回の記事でもTerraformを使ったサーバ構築の準備について記述しています。前述の構築に掛かる時間ですが、Terraformを使うことで丸１日掛かっていたような作業が4時間程度で完結できるようになるのが、Terraformの凄い所。ディスクサイズやVMのテンプレートの選択ミスもなくなるので、検証時や本番時で大きな時間ロスを防げます。

ノードサーバはイメージ取得したものから複製してVMを構築できるので、予めノード用のツールをインストール済みのものからディスクイメージ作成→Terraformで40台連続生成をすれば一気に構築が可能です。

TerraformでCompute Engineのデプロイを自動化する - 基礎編

事前準備

GWMで構成するCompute Engineのサーバは1プロジェクト最大で43台。Platform, MySQL, CouchDBは手動で構築しても良いのですが、問題はNode。

Nodeを40台構築して個別にRDPで入ってセットアップ・・・はあまりにも大変なので、予め以下のような作業をしておきディスクイメージを取っておきます。

  1. 普通に指定のスペック（今回はn2-highmem-4を選択）にて、VMを立てる
  2. RDPで入ってセットアップや各種設定（Defender無効化やWindows Update無効化など）をしておく。
  3. 作成したVMは稼働中なので停止する
  4. Compute Engineのイメージにて、作成したVMからディスクイメージを作成する。この時のイメージの名前を控えておく。
  5. 作成したVMは削除してしまって問題ない。

図：イメージを作成して残しておく

実際のスクリプト

GWMで利用するスクリプトはPlatform, MySQL, CouchDBについては指定のスペックとディスクサイズを指定して普通に作成しますが、Nodeについてはイメージからコピーして一気に40台作成します。

スクリプトで作成後、Platform, MySQL, CouchDBについてはRDPで入って個別にセットアップを行います。

main.tf

Terraformでメインで動くスクリプトです。2025年3月時点での要求スペックに基づく指定をしてあります。VPCを利用しない場合は#でコメントアウトします。

variable.tf

main.tfで利用する各種変数を格納しています。サービスアカウントのJSONファイルはmain.tfやvariable.tfと同じディレクトリに格納しておきます。使っている環境に応じてここは書き換えが必要です。前述で作成したNodeのVMのイメージ名についてもここで記述しておきます。

以下のベースIPアドレスはVPC利用時のものなので、VPCを利用しない場合は変更が必要です。

サーバ構成

実際に手動なりTerraformなりでCompute Engine上にVMを構築するに当たって、どんなスペックで指定したらよいか？については公式ドキュメントに掲載されています。注意すべきはDBのSSDディスク容量はオブジェクト数に応じて変動することになるので、ここを低くしすぎるとログが収まりきらないであったり、過剰だとコストが跳ね上がることになります。

  • Platform：1台
  • ノードサーバ：40台（1プロジェクト40台がマックスになります）
  • MySQLサーバ：1台
  • CouchDBサーバ：1台

速度などを考えるとリージョンはNortheastが良いかも。しかしなるべくM365のリージョンに近い場所を指定したほうが良いかも。ただしこの件については特に要件には記載無し。

Compute Engineの仮想環境でのコンテナ作成時にWindows Server 2019等を選べるため、OS自体のセットアップは不要（ADなども使えて、GCP利用料金に全て込みなので、いちいちハードウェアやWindows Serverの調達が要らないのがクラウドの良いポイント：稟請とかすごく面倒だし）。

RDPで外部IPに対して接続して作業を行います。各サーバ用の構築用インストーラが用意されてる為、これをコピペするとアップロード出来ます。

※なお、Microsoft365からのデータはノードサーバを経由するのではなく直接的にMicrosoft365⇒Google Workspaceに移行するのでrcloneよりかはダウンロードが無い分早く完了する。

サーバーのスペック

2025年1月時点での用意するサーバのスペックについては以下の様になってる模様。Terraformなどで一括作成する場合には

  • 共有要件
    • Windows Server 2016以上
    • .Net Framework 3.5以上が必要
    • Chromeブラウザが必要
  • Platform
    • 4コア, 16GBのRAM, 200GBのSSD
    • 1台必要
    • Compute Engine上では「n2-standard-4」以上が推奨
  • データベース
    • 4コア, 16GBのRAM
    • CouchDBとMySQLそれぞれ1台ずつ必要（プロジェクト規模によってはさらに1台ずつ用意して合計4台構成にする）
    • SSDディスク容量についてはMySQLがオブジェクト 1 億個につきおおよそ1TB、CouchDBが4,000 万個につきおおよそ 1TB。とりあえず2TB設定にして、必要に応じて拡張すると良い。
    • Compute Engine上では「n2-standard-16」以上が望ましい。16コア、64GBメモリの構成です。
  • ノードサーバ
    • 4コア, 32GBのRAM, 200GB以上のSSD
    • プロジェクト規模に応じて1プロジェクト当たり最大40台用意
    • Compute Engine上では「n2-highmem-4」以上が推奨

サーバーのシャットダウン

Compute Engine上のVMはRDPで中に入って、スタートメニュー等からシャットダウンを実行するようにしましょう。自動的にGCPのGUI上でも停止状態になります。

しかし、Compute Engine上から「停止」を実行した場合「強制停止」と同じ状況になることから、ケースによっては構築した内容が破損する場合があります。

実際にMySQLのサーバが不整合を起こし大変な状態になったことがあるため、DBサーバやPlatformに関しては内部からシャットダウンするほうが良いでしょう。ノードについてはそのままUIからの一括停止で問題ありません。

各種サーバのセットアップ

外部IPアドレスの固定化

検証時などでサーバをシャットダウンして間を開けてまた検証といった時に、デフォルトのままだとPlatformやMySQL、Couch DBの外部IPアドレスがその度に変わってしまい、RDPで接続しての作業時に毎回接続先を変える必要があります。

これでは不便なので、以下の手順でIPアドレスの予約をして固定化しましょう。

  1. Platformサーバなどをシャットダウンしておきます。

  2. 中の設定に入って編集をクリック

  3. 下の方にあるネットワークインターフェースをクリックして開きます。

  4. 外部IPv4アドレスの欄をクリックして、静的外部IPアドレスを予約をクリック

  5. 適当な名前を入れて予約をクリック

  6. IPアドレスが出てくるので、RDPなどの接続先は次回からこのIPで常に接続が出来ます。

図：外部IPは固定化しておきましょう

Windows Serverのベストプラクティス

Google日本語公式ページのベストプラクティスには記載が無いのですが、サーバパフォーマンスに重大な影響が与える為、Windows Serverに対して設定しておいたほうが良い項目といった追加の内容が英語版PDFに記載があります。なぜ日本語訳して掲載しないのか不明。また説明用の追加スライドも用意されています。

この内容によると以下の設定をWindows Serverに対して行うべしとあり、ノードサーバなどは台数が多いので予めセットしておいた内容をイメージを取って、Terraformで40台一括作成したほうが手間が省けるでしょう。

  • スキャンは可能な限り移行の直前に行う。スキャン実行をする事で移行のための最適化をGWM内で行っているので必ず実行するようにする。
  • SharepointやExchangeは個別のブリッジに分けて実行する。後でトラブルシューティングする際に混ざってるとやりにくい。
  • MySQLやCouchDBなどのデータベースのログが3TBに近づいてる場合、移行に支障が出る可能性があるのでプロジェクトを分けて実施することが望ましい（故にMySQLやCouchDBサーバをもう１つのGWMプロジェクト用に別に用意する必要がある）。
  • Microsoft Windows UpdateとWindowsのウイルス対策保護をオフにしておく。でないとGWM実行中に作動してパフォーマンスダウンの原因となる。
  • 新しいブリッジを作成するよりも、既存のブリッジで差分移行を実施するほうが効率的です。新しいブリッジを作成すると、ターゲット API に大きな負荷がかかり(Microsoft365側)、移行が遅くなる可能性があります。
  • 1プロジェクト当たりの移行対象ユーザは10,000を超えないようにしてください。超える場合は別プロジェクトに分ける必要があります。
  • DBサイズが大きくなるほどパフォーマンスが低下します。

RDPクライアントの準備

全サーバシステム要件によるとWindows Server 2019で構築することになっています。また、アーキテクチャの説明資料はこちらになります。用意したVMに対しては外部IPが自動で割り当てられるので

  • VMに対してWindowsログオンパスワードをセットする
  • VMの外部IPアドレスに対してRemote Desktopクライアントで接続してログオンする（macOSだとこちらから入手出来ます。）
  • Windowsの場合はMicrosoft Storeから入手することが可能です。

サーバ接続共通のVMインスタンスを起動してRDPで接続する手順です

  1. GCPの作成済みプロジェクトにログインする

  2. 左サイドバーより、Compute Engine⇒VMインスタンスを開く

  3. 個別に作成しておいたVMインスタンスの「︙」をクリック⇒開始/再開をクリックする

  4. 同じ画面で対象VMインスタンスのRDPの▼をクリック⇒Windowsパスワードの設定をクリック

  5. ユーザ名/ログインパスワードを入力して、設定をクリック。

  6. 次にRDPをクリックして、RDPファイルをダウンロードをクリック

  7. 6.のファイルをダブルクリックするとログイン画面が出るので、コンピュータには外部IPアドレス、ユーザー名には5.で設定したID/PWで入力

  8. 接続をクリックするとRDPにてCompute Engineのコンテナに接続します。

図：RDPで遠隔接続して作業します

IAPを使ってVMに接続する

前述まではVMに対して外部IPアドレスを持たせてRDPで接続し作業をしていました。しかし、外部に対してポートを開放することにもなりセキュアではないという点で懸念するケースもあるでしょう。そこで、Identity-Aware Proxyという仕組みを追加で構築して使い、外部IPを持たないVMに対してRDPにて接続するという方法を使ってみます。

Google Cloud側の準備も必要ですが、ここでは省略しています。

事前準備

Terraformでも使ってるであろうgcloudコマンドが必要です。Google Cloud CLIをインストールします。

  1. こちらのページにアクセスしてmacOS版をダウンロードする（M1はARM64, Apple M1 siliconを選択）
  2. ダブルクリックして解凍する
  3. ターミナルを起動して、2.の解凍先のフォルダまで移動しておく
  4. 中に入ってるinstall.shを実行する

    Do you want to help improve the Google Cloud CLIと問われるますが、「改善のために匿名の使用統計情報を送信するかどうか」なので、nでも問題ないです。
  5. Do you want to continue?と問われるので、Yと入力してEnterを実行
  6. Enter a path to an rc file to update, or leave blank to useと出ますが、blankのままEnterで問題ないです。
  7. Download and run Python 3.11 installer?と出るので、Yと入力してEnterを実行し、Pythonをインスコします。
  8. macOSのユーザパスワードを入力して続行します。
  9. 完了したら、一旦ターミナルは終了させておき、再度ターミナルを起動します（これをしないとgcloudコマンドが使えない）
  10. gcloud versionでバージョン表記が出たらオッケー

これでインストールが完了します。

もし、解凍先フォルダを他に移動してしまうとパスが通っていない状態なので、以下の作業をしなおしてパスを通し直す必要があります。

  1. 対象のフォルダをクリックした状態で、option + command + cでフルパスを取得できる

  2. ターミナルを起動する

  3. open ~/.zshrcを実行して設定ファイルを開く

  4. ファイルが開かれるので、中に記述されてるGoogle Cloud SDKやshell command completion for gcloudに記述されてるパスを書き直す

  5. 上書き保存する

  6. source ~/.zshrcで反映する

これで、gcloudコマンドが使えるようになります。

図：gcloud cliのインストールの様子

図：パスを通し直す場合

クライアント側の準備

クライアント側ではgcloudコマンドにて、gcloud initにてGoogle Cloudへは接続しておいてください。Terraformの項目内でgcloud initコマンドについては解説しています。

以下は同じくgcloudコマンドにてIAPが設定されてるGoogle Cloud環境内のCompute Engine VMに対してlocalhostでつなぐ為の手順になります。事前にVMにadminパスワード設定はしておいてください。

  1. ターミナルを起動する
  2. 以下のコマンドをまず実行する。

    myprojectnameには、接続先のGoogle Cloudのプロジェクト名を入れます。GCPのダッシュボードの右上プロジェクト情報に記載があります。
  3. 次に以下のコマンドを実行します。

    myprojectnameは前述と同じ。instancenameはCompute Engine上に構築したVMにつけた名前を指定します。また上記の場合、VM側3389版ポート（RDPで使うポート番号）をlocalhostの13389番へ転送しています。

    zoneはvmのリージョン指定ですので、同じリージョン名を指定すると良いでしょう。

  4. 以下のような内容が返ってくれば転送完了です。ターミナルはそのままにしておきましょう。

  5. 続けて、Microsoft Remote DesktopやWindows Appを起動します。
  6. Add PCで新しい設定を追加します。
  7. PC nameには、IPアドレスを入れますので「localhost:13389」と入力します。
  8. User AccountにはVMに設定したadminのアカウント/PWを登録しておきます。
  9. Addボタンをクリックして設定を追加
  10. 追加されたRDP設定をダブルクリックして接続
  11. certificateがどうたら出るので、Continueをクリックする
  12. すると外部IPアドレスをセットしていないVMであってもポート転送でlocalhostからRDPで接続が出来ます。

毎回、接続する場合は上記のコマンドを実行して待機させておく必要があるので、スクリプトを作っておきターミナルで簡単にポート転送出来るようにしておくと尚良いでしょう。

図：ポート転送させた様子

図：RDPの接続設定

DBサーバ

追加ディスク

OSが入ってるディスクに対してログを記録しても良いのですが、あえて分けて尚且つ後でディスクを拡張することも想定するならばVMに対して追加のディスクを追加し、各アプリからデータ保存先として追加ディスクを指定すると良いでしょう。

RDP接続時に追加ディスクが見えない場合にはディスクをフォーマットして例えばDドライブとして見えるようにしてからDドライブをデータ保管先として指定すると良いでしょう。

必要とされるディスク容量とコスト計算

他のサーバと異なり、MySQLおよびCouchDBはGWMのログが蓄積されます。結果としてログが膨大になり、初期のディスク容量では全然賄えず、ディスクサイズを拡大するといった羽目になるケースがあります。

公式ドキュメントに於いても、以下のような計算基準を用いています。M365側サービスの全オブジェクト総数を調べて以下のように計算します。

  • MySQL : 1億オブジェクト当たり1TB

  • CouchDB : 4000万オブジェクト当たり1TB

まずはこれでスタートし、不足した場合は順次拡張するといった形を取る必要があります。

MySQLサーバ

MySQLサーバからまずは構築する。作成済みのMySQL用のVMインスタンスを起動してから、ソフトウェアのインストール作業を行うことになる。公式の作業用リファレンスはこちら。

  1. MySQL用サーバにRDPで接続

  2. 仮想環境内で、こちらのページのMySQLインストーラをダウンロードして実行

  3. インストーラの指示にしたがってインストールを完了させる

  4. 途中、インストール先、データ保管先を問われるので指示に従ってセットする（追加ディスクの場合は注意）

  5. 途中、PFXファイルを用いてTLSが設定可能という項目が出るが、本資料では省略するため、そのまま「Next」をクリック

  6. 最後にDBのrootパスワード、User名とパスワードが出てくるのでメモしてコピっておく（これ重要です）

  7. Installで続行する

  8. 完了したら再起動を求められるのでFinishをそのままクリックする

  9. またMySQLが稼働してるかどうかはservice.mscの項目から実行中かどうかを確認できる

※7.にて、ユーザ名とパスワードを控え忘れたと言って、MySQLを一旦アンインストールして、再インストールしたところ、Platformサーバから何故か接続出来ないという問題が発生。この場合、VM自体から作り直したほうが良いです。

CouchDBサーバ

次にCouchDBサーバからまずは構築する。作成済みのCouchDB用のVMインスタンスを起動してから、ソフトウェアのインストール作業を行うことになる。公式の作業用リファレンスはこちら。

  1. CouchDB用のサーバにRDPにて接続

  2. 仮想環境内で、こちらのページのCouchDBインストーラをダウンロードして実行

  3. インストーラの指示にしたがってインストールを完了させる

  4. 途中、インストール先、データ保管先を問われるので指示に従ってセットする（追加ディスクの場合は注意）

  5. 途中、PFXファイルを用いてTLSが設定可能という項目が出るが、本資料では省略するため、そのまま「Next」をクリック

  6. .net Framework 3.5が同時にインストールされる

  7. 最後にDBのrootパスワード、User名とパスワードが出てくるのでメモしてコピっておく（これ重要です）

  8. Installで続行する

  9. 完了したら再起動を求められるのでFinishをそのままクリックする

  10. またCouchが稼働してるかどうかはservice.mscの項目から実行中かどうかを確認できる

Platformサーバ

サーバーインストール

もっとも重要なプラットフォームサーバを構築します。こちらが一番よく利用するサーバになります。

  1. Platform用のサーバにRDPにて接続

  2. 仮想環境内で、こちらのページのGoogle Workspace Migrate インストーラをダウンロードして実行（Zipを解凍すると、GoogleWorkspaceMigrate_Platform_Installer_x.xx.xx.exeというのが入ってる）

  3. インストーラの指示にしたがってインストールを完了させる

  4. 途中使用するポート番号を指定する場面が出る。ここでは「5131」を指定してNextをクリック

  5. 途中、前述で作成した「OAuthクライアントID」を入力するシーンがあるので、登録する

  6. 途中、前述で作成した「サービスアカウントのJSONファイル」を指定するシーンがあるので、アップロードして指定する。

  7. 途中、Google Workspaceの特権管理者のメアドを入力するシーンがあるので入力する

  8. Installで続行する

  9. 完了したら再起動を求められるのでFinishをそのままクリックする

  10. またPlatformが稼働してるかどうかはservice.mscの項目から実行中かどうかを確認できる

DBのサーバにインストールしようとすると警告がでるが、I Understand the risksにチェックを入れれば続行はできる。しかし、別に立てることを推奨してるので同一のサーバに同居しないように注意。

Chromeのインストール

Windows Server 2019の場合、IEしか搭載されておらず、またPlatform ServerのGUIはエラーが出て表示できない。また、Windows Server 2019内でChromeをダウンロードしようとしてもエラーが出て出来ないので、以下の手順でChromeをインストールする

  1. macOSの場合、ダウンロードページに行ってもmacOS用がダウンロードされてしまうので、Chrome拡張機能の、User Agent Switcher and Managerを入れて、Windows10に偽装しておく。

  2. こちらのページを開く

  3. ダウンロードをクリックするとインストーラが手に入る

  4. Platform ServerにRDPで接続し、コピペでインストーラを送り込む。

  5. RDP内でセットアップをして、完了させる

  6. http://localhost:5131/#/sign-inにアクセスしてログイン画面が出てきたらオッケー

図：別途Chromeのインストールが必須

ノードサーバ

実際の下僕として作業をするノードサーバ１台１台に対して、ノードサーバ用のソフトウェアをセットアップしていきます。

  1. Node用のサーバにRDPにて接続

  2. 仮想環境内で、こちらのページのGoogle Workspace Migrate インストーラをダウンロードして実行（Zipを解凍すると、GoogleWorkspaceMigrate_Node_Installer_x.xx.xx.exeというのが入ってる）

  3. インストーラの指示にしたがってインストールを完了させる

  4. 途中使用するポート番号を指定する場面が出る。ここでは「5131」を指定してNextをクリック

  5. 途中、アクセスキーの設定画面が出る。適当な文字列を用意して登録しこのキー名をメモしておく。（このキー名は全てのNodeで共通の値として設定しますので個別に登録しないように。自分はgwmという文字列にしました。）

  6. Installで続行する

  7. 最後のFinish画面で、２つのチェックボックスにチェックを入れる

  8. 完了したら再起動を求められるのでFinishをそのままクリックする

  9. またNodeが稼働してるかどうかはservice.mscの項目から実行中かどうかを確認できる

DBやプラットフォームサーバに同居することは出来ないので、必ずわけてインストールが必要です。

図：アクセスキーの設定だけ注意が必要

GWMのセットアップ

GWM利用上の注意点

サーバー起動時にサービスが起動していない

Platform Serverに色々設定をしてCompute Engine上でサーバを停止後、再度サーバを起動しRDPで接続してみると、肝心のGoogle Workspace Migrateのサービスが起動していません。

よって、そのままだとログインしたくともページが表示されませんので、必ずタスクバーのGWMのアイコンから「Start Google Workspace Migrate Service」をクリックして、しばらくしてからログインしましょう。

図：サービスが起動していないことがある

ユーザセッションが結構切れます

GWM上でこれから色々な設定を追加していきますが、その過程の中でScanなどで待機してるシーンがあります。GWMのツールなのですが、数分間何もユーザがアクションを起こさない状態が続くとセッションが切れて、再ログインをしないといけなくなるシーンがあります。

よって、Scanなどでなかなか進行しないで停滞してると感じた場合、後ろでは動いていて表側がセッション切れで画面更新されていないことが考えられます。また、CSVアップロードなどのシーンでも同様でセッション切れの場合は、再ログインしないとCSVアップロードは出来たかのように思えて、反映していないことがあります。

間を開けて作業をする場合には、一度ログインし直してから作業をしましょう。

変なメールを二次的に除外出来ない

データ移行サービスとは異なり、迷惑メールを除外といったような細かい要望に応えられるようなツールにはなっていません。よって基本的にはすべて移行です。

例外的にアーカイブメールを除外したり、指定期間内のデータの除外などはExclusionのフィルタ設定で行うことは出来ますが通常は使いません。但し、フィルタ設定にて迷惑メールフォルダや下書きなどのフォルダを除外することは可能です。

また、タスクやカレンダー、連絡先などのデータはサービスレベルで移行の可否を指定することは出来ます。

実際にGWMの設定を行う

ここまでで、様々なものの準備やサーバの準備が完了しました。ここからはGWM自体の設定を行っていきます。設定を行うには、これまで構築した全サーバが起動状態である必要があり、

  1. PlatformサーバにRDPで接続して中に入ります。

  2. ブラウザにて「https://localhost:5131」と入力してプラットフォームへアクセス

  3. Signin Googleのボタンが出るのでクリックして、通常は「Google Workspace側の特権管理者」でログインします（もしくはGoogle Workspace Migrateのロールを付けた管理者）。また、ドメイン全体の委任で追加時のアカウントとなります。

  4. Get Startedをクリックする

  5. 暗号鍵の作成を求められるため、任意のパスワードを入力し、「Configure key」を押下。その後、生成された暗号鍵のJSONファイルがダウンロードされるため保管する（EncryptionKey.jsonというファイル）

  6. データベース情報（MySQL, CouchDB）として、各サーバーの内部IPアドレスとポート番号、インストール時に保管した各サーバのユーザー名とパスワードを入力し「Continue」を押下

  7. ※ 6.のポート番号は 3306（MySQL）または 5984（CouchDB）

  8. ※ MySQLはRootパスワードと間違えないように注意

  9. ※ CouchDBにてTLSを使用している場合は公式ドキュメントを参照

  10. プロジェクト作成画面では適当に入力する

  11. Configure Callback Addressと出たら、http://<プラットフォームの内部 IP アドレスまたはホスト名>:<ポート>」形式で入力し、「Countinue」を押下

  12. 次の項目のServersではノードサーバを次々に登録していきます。+ボタンをクリックして、ノードサーバのIPアドレスとポート番号、アクセスキーを登録してゆきます（ここで全サーバを登録すること）

  13. 作成するプロジェクト名を任意の値で入力し「Create」を押下

これで、GWMに各サーバを紐つけることが完了しました。

ただし、12.で1件ずつノードを登録するのは苦痛なので、スプシで以下のような形でCSVを作成してアップすると楽に登録可能です。

  • Name, URL, Access Keyの３列で構成

  • NameはCompute Engineのサーバ名、URLはノードサーバの内部IP:ポート番号のhttpから始まるURL、Access Keyは取得しておいたアクセスキー

  • 記述したらエクスポートでcsvで出力。これをアップしまとめて登録する

また、紐付け作業が完了した場合、全サーバを起動状態にしていないとGWMは起動しないので自動でStopしてしまうので要注意。

図：DBサーバ設定

図：ノードサーバの登録

関連リンク

カテゴリー
Google、Microsoft365
タグ

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

Google

前の記事

Google Workspace MigrateでMicrosoft365からお引越し - 事前準備編
2025年1月6日
Google

次の記事

Google Workspace MigrateでMicrosoft365からお引越し - 引越実行編
2025年1月8日