Google Workspace MigrateでMicrosoft365からお引越し - 引越実行編

前回の段階で事前準備とCompute Engine上にサーバーの構築まで完了しました。今回は実際にこの環境を使っての「引っ越しの実行」と引越し後のトラブル解決という最終工程になります。

引越し後のトラブル解決は軽視されがちなのですが、100%完璧に移行が出来ますというツールではないですし、そもそもM365にあってGoogle Workspaceには無いという機能もあるため、ここのハンドリングをどうするのか？は重要な部分になります。

今回利用するツール

• Google Workspace Migrate
• Compute Engine

Google Workspace Migrateのサーバー接続用設定は前回終わっていますが、ここからはMicrosoft365側との連結や移行対象のExchangeユーザやサービス、Sharepointのサイトのリスト追加といった作業をし、いよいよ移行を実行します。

Microsoft365なので、Sharepoint OnlineおよびExchange Onlineからの移行となるのでオンプレのサーバからの移行ではないので注意が必要です。

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

移行作業上の注意事項

移行対象外

Microsoft365からGoogle Workspaceへ、GWMを使っての移行は全てが移行できるわけではありません。それぞれのサービスに於いて移行できるもの出来ないものは以下のリンク先で把握が必要です。

• Sharepoint Onlineにて移行できるもの出来ないもの
• Exchange Onlineにて移行できるもの出来ないもの

また、現在はSharepointのサイトページやリスト、Teamsのチャットログなども移行対象外です。また、他にも以下のようなM365独自サービスは移行対象外です

• Power AutomateおよびPower AppsなどのPowerシリーズ
• 各種Webサービス（Planner, Pages, Forms, Whiteboard, Visio, OneNoteなどなど）
• Office Script

移行作業中の注意点

• 移行中もSharepointファイルの更新は行えますが、更新タイミングによっては更新が反映されていないので、移行日にファイルの更新を行った場合は、差分が取込まれているか確認が必要
• 移行中にGoogle Driveのフォルダを移動させた場合、移行がエラーになるためNGです。
• 移行中のGoogle Drive側のファイル編集は、デグレートが発生する可能性があるためNGです。
• メールについても移行作業中はGmail側は操作はNGです。
• ただし、Outlook側で格納フォルダを別にしたであったり、なにか変更を加えた場合には、再実行でその内容が反映するので心配無用です。

M365側からのメール二重配信について

概要

GWMでのデータの移行に於いて忘れがちなのが、メールの二重配信設定。GWMで移行実行時に存在してるメールについてはGWMで移行されますが、移行完了までの間のメールについては移行されません。移行完了後に再度GWMを実行すれば差分を移行は出来ますが、いずれにせよその場合も再実行完了後までのメールは移行されないのでどうしても差分が出てしまう。

また再実行をすると再実行時までの積み上がった数カ月分のメールの移行となるので時間が掛かってしまう。ということで、移行実行前にMicrosoft365のExchange OnlineからGoogle Workspaceに対してメールの二重配信設定を全ユーザに対して行うことで

• 差分実行時の移行負荷を下げられる（重複してメールは移行されずスキップしてくれるようになります）
• GWMでの移行完了までの間のメールもGmail側に転送されるので差分というものがなくなります。

といった事が実現出来ます。よってメールの取りこぼしが無いようにGWMでの移行前に「メール転送」はセットしておきましょう。

注意事項

GWMでのメールの移行時にOutlookの迷惑メールフォルダにあるメールも転送されます。しかし、Gmail側の迷惑メールに入ってきてしまうので、移行期間が30日以上掛かる場合、この迷惑メールフォルダに移行されたメールというのは削除されてしまいます。このメールについては、移行完了後の「再実行」にて再度移行させることは可能です。

いずれにせよ30日で削除されるルールがありこれは解除出来ないので、事前に考慮しておくべき事項になります（そもそも迷惑メールに自動分類されたものなのでそれほど重要ではないと言えるけれど、M365側での誤判定も有り得るので）。

GWMでの通常のメール移行に対して、Google Workspace側でメールに対して迷惑メールフィルタが適用されて削除されるということはありません。

M365側の転送前事前準備

スパム対策ポリシー

現在のMicrosoft365のExchange Onlineでは転送設定してもM365側のポリシーによって転送がブロックされてしまいます。よって以下の手順でテナント全体のポリシーとして転送ブロックの解除が必要になります。

1. Microsoft Defenderを開く
2. 左サイドバーからメールとコラボレーションを開く
3. ポリシーとルールをクリックする
4. 右パネルより、脅威ポリシー→スパム対策を開く
5. ポリシーの作成をクリックして、Outboundを選択する
6. ウィザードが開始されるので、名前と説明を入れて次へをクリック
7. ここではドメイン全体に対して適用するので、ドメインに対して現行M365のOutlookとして使ってるドメインを入力して、次へクリックする。
8. 自動転送ルールが自動になってるので、ここをオンに変更して次へをクリック
9. 最後に作成をクリックして完了

図：ブロックされてしまった通知

図：ドメイン全体を指定する

図：作成された新ポリシー

リモートドメイン

通常この設定を弄る必要はないのですが、リモートドメイン設定に於いて自動転送がオフになっていると転送の障害になる可能性があるのでここをオンにしておきます。

1. Exchange管理センターを開く
2. 左サイドバーより、メールフロー→リモートドメインを開く
3. 通常はDefaultをクリックする
4. 右サイドバーが出てくるので、返信の種類を編集をクリックする
5. 自動応答に於いて自動転送を許可するにチェックを入れて保存をクリックする

図：リモートドメインの設定

M365側の転送設定方法

転送先アドレスについて

各ユーザ単位で個別に転送設定をする必要があります。しかしこの段階ではまだDNSのMXレコードがGoogle側を向いていないので、同一ドメインの場合このままではGmailにメールが届きません（Google側が違うドメインならば届きますが）。

Google Workspaceではこういったケース用の引っ越し用に「テストドメインエイリアス」というものが用意されており、例えば「hogehoge@company.jp.test-google-a.com」というのが有効化済みになっています。M365側から転送を仕掛ける場合にはhogehogeに個別のユーザ名、company.jpの部分が自社の正規のドメインとしてtest-google-a.com宛に送れば、対象のGmailのメールボックスに転送が可能です。

個別にセットする

Exchange管理センター上で１人１人個別に転送設定が必要です。CSVアップロードなどで一括で設定する箇所が見当たらなかったので、一括でセットしたい場合には次項の「PowerShellで一括セットする」必要があるのではないかと思います。

1. Exchange管理センターを開く
2. 左サイドバーから受信者→メールボックスを開く
3. 転送したいアカウントをチェックしてメールフローの設定→メールの転送をクリックする
4. 上部のスイッチをオンにする
5. 外部のメールアドレスに転送するに、Google Workspace側のテストドメインエイリアス宛のメアドを入力する
6. 転送先アドレスとメールボックスの両方にメッセージを配信しますにチェックを入れる
7. 保存をクリックする

これを人数分手作業でやる必要があるので、大人数の場合ちょっと現実的な作業では有りません。

図：メール転送個別設定

PowerShellで一括セットする

PowerShellを使ってExchange 管理シェルを利用した上記の個別ユーザの転送設定のセットが行えます。これをスクリプトを構築してループで回してあげれば全ユーザに対してメール転送を装備できると思われます。

こちらにサンプルコードが掲載されていますが、これは単一の転送セットの事例なのでこれを例えばExcelのファイルを読み取ってアドレスをセットしつつループで回して次々にセットするようなスクリプトに仕立て上げられれば、一括で転送設定が出来るのではないかと思います。

詳細なコマンドのドキュメントはこちらにあります。Identity引数ではなく-UserPrincipalNameでユーザプリンシパルネーム指定のほうが構築しやすいのではないかと思います。以下はuserlist.csvにIdentityとfwAddressの2列を用意したものをPowerShellで回しながら転送設定を流し込むスクリプトの事例です。fwAddress列がGWS側の転送先アドレスとなります。

Exchangeの移行

概要

メール、カレンダー、ToDoリスト、共有メールボックス、パブリックフォルダ、連絡先の6つを1塊としてExchange Onlineからの移行対象となります。移行元と移行先のドメインが異なっていてもドメインマッピングを使って移行することが可能です。

GWM上はClient ID/Secret方式に移行したとは言え、Exchange管理者アカウントも必要となるので事前に用意しておく必要性があります。公式の移行用のドキュメントはこちらに掲載されています。

メールの場合件数が多い為、時間が掛かりやすい傾向があるので（APIを叩く回数が多い為、オーバーヘッドが掛かる）、十分に検証してから移行実行をしましょう。

今回は純粋なメールとカレンダーのみを移行対象として進めていきます。

ユーザリストの作成

移行対象とするユーザのリストを構築します。といってもCSVで用意するだけの簡単なものです。タイトル列無しで、移行元のドメインのままのメアドを縦に列挙したCSVを用意するだけ。共有メールボックスも同じくメアドを列挙するだけです。

スプシで作成してそのままエクスポートでCSV形式で出力するだけです。これをGWMのユーザリスト画面でアップロードします。

1. 左上のNewをクリックして、Listを選択

2. Nameには適当に入力する

3. TypeはUsersを選択する

4. Upload CSV Fileをクリックして、作成したユーザの一覧のCSVを指定する

5. Createをクリックする

これで、移行するユーザを登録することができました。Connectionの作成でこのリストを指定します。

図：CSV作ってアップするだけ

コネクションの作成

移行元コネクション

移行元なので、Microsoft365側との接続を作成します。ここが2024年8月に大きく変更された点。設定用のドキュメントはこちらを参照する必要があります。Connectionを作成する際には事前準備にてAzure Portal上で用意した「管理者アドレス, Client ID, Secret, Tenant ID」の4つが必要になります。

1. 右上のNewをクリックして、Connectionを選択する

2. Nameは適当に入力し、TypeはExchange Onlineを選択する

3. Admin emailは前述で用意したM365側のExchangeのスコープを付けた管理者のメアドを入れる

4. AccountはAdd New Accountをクリックする

5. Client IDおよびSecret, Tenant IDを入力する

6. あらかじめ前述で作成しておいたユーザリストをListから選択する

7. Createをクリックする

ここで問題がなければ、M365と接続が出来ます。特にログオン画面や認証画面は出てきません。権限に問題がある場合は赤字でエラーが出たり、403エラーといった表記が出てきます。（The request failed. The remote server returned an error: (403) Forbidden.というエラー）

追加できたら、作成したコネクションの右隣にある「⋮」をクリックし、Treeviewをクリックし、期待したユーザと内容が出てくれば接続出来ています。

図：まずは移行元と接続をする必要がある

移行先コネクション

次は移行先であるGoogle Workspaceのテナントとの接続を作成します。

1. トップ画面に戻り、左サイドバー上部にある「New」をクリック⇒Connectionを選択する

2. Create Connectionにて、適当なNameを設定し、TypeではGoogle Workspaceを選択。

3. Admin emailはGoogle Workspaceの特権管理者のメールアドレスを入力する

4. AccountはAdd new accountを選択する

5. Service Certificateは前述までに入手しておいたサービスアカウントのJSONファイルを追加する

6. Createをクリックする

これで移行先のコネクションを用意することが出来ました。

図：これで2つコネクションが作れました

テンプレート設定

Exchange Onlineからデータを取得するにあたってのテンプレートを作成していきます。が、

1. 左サイドバーから「Settings templates」⇒ Show all templatesのチェックを入れる

2. DefaultのExchange Onlineの鉛筆マーククリックする。

3. 基本的には変更せずにデフォルトの設定のままで続行して完了させる。5つの設定項目に、それぞれオプション項目がぶら下がっています。

要件によっては、共有メールボックスやパブリックフォルダ等は移行しないといったことがあるので、この段階で調査して外しておく必要があります。

また、このテンプレート内にあるUser Mappingにて移行元と移行先のドメインが違う場合には、Domain Mappingでドメイン変換して移行させることが可能です。自分が使うとしたら・・・の変更点としては

• 移行元がonmicrosoft.comなのでドメインマッピングを利用。
• 共有メールボックスとパブリックフォルダ、ToDo、連絡先は移行しないので除外。
• アーカイブメールを移行するかしないか？といったオプションは存在する（Include mail in In-Place Archivesというオプション）。さらにこれに対するオプションとして、Create separate labels under an archive labelを使うことで、アーカイブに対してラベルがつくようだ

• また、Accelerate old messagesというオプションがあるが、これは指定日前の古いメールについて処理を高速化する一方、メールの二重配信設定をしてると重複してメールが存在しなおかつメールのスレッドが分断される可能性があるため、通常は使用しない。

• Excludeというフィルタをして特定の日付間のメールだけ移行という指定が可能です。

図：フィルタ設定はお好みで

図：ドメインマッピングは必要なケースで

スコープビューの作成

作成したコネクションの行にカーソルを持ってくると、「フィルタ」のマークのScoped Viewというアイコンが出てきます。これをクリックしてスコープビューを作成します。

まずはスコープビュー用のCSVファイルを作成します。

1. スプレッドシートを新規に作成する

2. ExchangeUserというタイトル列のみで作成し、M365の対象ユーザのメアドだけを列挙したCSVを作成する。

3. 右上の＋アイコンをクリックする

4. コピーしたCSVを指定する

5. Createをクリックする

6. 一覧がでてくるので、全部のユーザを選択して、右上の✔✔アイコンのValidateを実行し、Validityが緑色になったらオッケー。エラーのものはエラー内容を確認します。

エラーとして「doesn't have a valid license」みたいな内容が出たら対象のアカウントのM365ライセンスが有効化されていないので、ライセンス割当する必要があります。

図：Validateを忘れやすいので注意

スキャンの実行

続いて、スキャンを作成し実行します。以下の手順でスキャンを行います。

1. 右上のNewをクリックして、Scanをクリックします。

2. Scan Nameは適当にセットします。

3. Connectionでは、作成しておいたM365のコネクションを選択します。

4. Scan ScopeはFull Scanでオッケー

5. レポートタイプはデフォルトのままでオッケー

6. Createをクリックする

つづいて、作成したスキャンを元に以下の手順で実行します。

1. スキャン画面にて、「▶」をクリックしてスキャン開始する

2. Completedになったら完了。

3. FailuresやWarningがなければオッケーです。

図：スキャンして移行対象アカウントにおかしな点がないかチェック

マッピングの作成

ユーザマッピングの作成

次に、マッピングを作成します。以下の手順でマッピングを用意します。

まずはマッピング用のCSVファイルを作成します。

1. 1行目の列名は「Source ExchangeUser, Source ExchangeService, Target GUser, Target GService」の4列で設定したCSVを作成する。詳細はこちらのページに掲載されています。マッピングヘッダーの内容はこちら。

2. 対応する内容は、M365のユーザアカウント、M365のサービス名、GWS側アカウント、GWS側のサービス名で作成し、メール、メールアーカイブ、カレンダーなどそれぞれ1行ずつ作るので、この3つならが1ユーザ3行分のデータが必要です

3. 左上のNewをクリックして、Mappingを選択します。

4. Mappingsの右上の＋アイコンをクリックする

5. Nameは適当に入力する

6. Source Connectionは用意しておいたM365のコネクションを選択する。

7. Target Connectionは用意済みのGoogle Workspaceのコネクションを選択する。

8. 前述で作成したCSVをアップロードします。

9. 追加したら全ユーザを選択し、右上の✔✔アイコンのValidateを実行し、Validityが緑色になったらオッケー。エラーのものはエラー内容を確認します。

Scopeviewでエラーだったユーザはこちらでもエラーとなります。

図：1ユーザ複数行で構成されたCSVを作る

IDマッピングの作成

Exchange特有ですがIDマッピングというものがあります。これはもともとのメアドや共有権限をGWSで引き継ぐように変換するものになるので、例えばメアドが全然違う場合にメールの中のFrom Toなどを変換したい場合は追加するといったものになります。移行元と移行先が同一ドメインの場合は作成不要です。

1. 列名なしで、「移行元のメアド, 移行先のメアド」の2列でCSV作成します

2. 左上のNewをクリックして、Mappingを選択します。

3. 今度は、下のOther Mappingの横の＋ボタンをクリックします。

4. Nameは適当に入力します。

5. TypeはIdentitiesを選択します。（Roleもしたい場合はもう一度行います）

6. CSVは前述で作成したIDマッピングのCSVを指定します。

7. Createをクリックする

こちらはとくにValidateするような工程は無いようです。

図：IDマッピングは必要に応じて作成する

マッピング作成時のテクニック

Exchange Onlineの移行は1ノード1アカウントが担当して作業します（1台が同時に複数アカウントを処理はしない）。よって、メール数が多いグループとメール数が少ないグループでブリッジをわけて作成したほうが移行作業後半でノードサーバが遊んでる状態を作らない事に繋がります（平均稼働率が上がります）。

マッピングしたものからランダムにノードに対してキューが入る仕組みであるため、マッピングも同様に分けて作ってマッピングを登録したほうが望ましいです。こうすることで、先に重いグループがノードを占有し処理が始まり、後半終わった隙間に軽いグループが隙間に入ることで平均稼働率を上げることが出来ます。

ブリッジの作成と実行

いよいよ最後にブリッジを作成して移行作業の実施に取り掛かります。

1. 右上のNewをクリックして、Bridgeを選択します。

2. Nameは適当に入力します。

3. Source Connectionでは、M365 Exchange Onlineで作ったコネクションを指定します。

4. Target Connectionでは、Google Workspaceで作ったコネクションを指定します。

5. Setting TemplateはExchangeの前述までに作ったテンプレートを指定します。

6. Mappingは前述までに作成したマッピングを指定します。

7. Identity Mappingがある場合は別途指定します。

作成したら、左サイドバーの一番下にBridgeがありますので開いたら

1. ▶ボタンをクリックして「Run」を実行すると移行作業開始です

2. 移行が実行されて、Completedになったら完了です。（相当時間が掛かります）

3. エラーが等があれば再実行を実行して可能な限り移行を完了させましょう。

図：ブリッジの作成画面

図：ブリッジの実行画面

Sharepointの移行

概要

前述では個人個人のメールの移行について説明しました。ここからはSharepoint/OneDrive Businessの移行設定となります。Sharepointは共有ドライブに、OneDriveは個人のマイドライブにファイルが移行されます。

ファイル数が膨大であろうという点や共有ドライブを事前に用意・アクセスできるGWSアカウントを複数用意しておく必要性がある点に要注意です。

リスト作成

サイトのリスト

移行対象とするSharepointのサイトのリストを作成します。CSVファイルを用意して、次項のコネクションにて利用するために必要です。OneDriveも同じ要領になります。このURLについては、前回の記事の中でのSharepointサイト一覧の取得を参考にすると作りやすいです。上記のリンク先にPowerShellでの一覧リスト取得コマンドもあります。

1. CSVを作成する
2. CSVはタイトル列ナシで1列に対してURLを追記していくスタイルです。
3. Sharepointの場合にはサイトのURLを記述する。ただし、1行目はhttps://hogehoge.sharepoint.comを入れる（個別サイトのURLは2行目以降に）
4. OneDriveの場合にはユーザのマイファイル直下URLを入れておくと良い（例：https://hogehoge-my.sharepoint.com/my）

5. 左上のNewをクリックして、Listを選択

6. Nameには適当に入力する

7. TypeはLocationsを選択する

8. Upload CSV Fileをクリックして、作成したサイトの一覧のCSVを指定する

9. Createをクリックする

これで、移行するサイトの一覧を登録することができました。

図：サイトリストの作成事例

シャーディングユーザリスト

Exchangeには無いSharepoint独特のリストですが、シャーディングユーザリストを作成する必要があります。Google Driveは1日750GBの制限があるため、GWMもこの影響を受けます。よって750GBに到達したら次の別のユーザでもってアップしないとそこで止まってしまう。そのためのリストで、どれくらいのユーザアカウントが必要かというと

• ドライブに移行するファイル 40 万個ごとに1アカウント
• ノードあたり10アカウント

どちらか多い方をリストアップしておく必要があります。また、これらのユーザを全ての共有ドライブに対して管理者権限で追加しておく必要性もありますので要注意。

1. CSVを作成する
2. CSVはタイトル列ナシで1列に対してメアドを追記していくスタイルです。

3. 左上のNewをクリックして、Listを選択

4. Nameには適当に入力する

5. TypeはUsersを選択する

6. Upload CSV Fileをクリックして、作成したCSVを指定する

7. Createをクリックする

コネクションの作成

コネクションの作成は殆どExchange Onlineの時と変わりません。ただし、移行元コネクションで指定するリストはサイトのリストである点に注意。

移行元設定コネクション

移行元なので、Microsoft365側との接続を作成します。公式ドキュメントはこちらを参照。

1. 左サイドバー上部にある「New」をクリック⇒Connectionを選択する

2. Create Connectionにて、適当なNameを設定し、TypeではSharepoint Onlineを選択。

3. URLにはSharepointのベースURLを入れる（例：https://ドメイン名.sharepoint.com/)

4. 予め取得しておいたClient ID, Client Secret, 前述で作成しておいたサイトのリストを指定してCreateをクリックする

続けて、次項のスコープビューをセットします。

移行先コネクション

前述のConnectionでは移行元のSharepointの設定を作りました。今度は移行先であるGoogle WorkspaceのConnectionを作成します。

1. トップ画面に戻り、左サイドバー上部にある「New」をクリック⇒Connectionを選択する

2. Create Connectionにて、適当なNameを設定し、TypeではGoogle Workspaceを選択。

3. Admin emailは特権管理者のメールアドレスを入力する

4. AccountはAdd new accountを選択する

5. Service Certificateは前述までに入手しておいたサービスアカウントのJSONファイルを追加する

6. Createをクリックする

これで、GWS側の接続設定が完了しました。

テンプレート設定

ここでは、Sharepoint⇒Google Driveへの移行を指示する為のテンプレートを設定していきます。共有ドライブ向けとマイドライブ向けの2パターンがあるので要注意。テンプレートに関するドキュメントはこちらにあります。

以下は基本共有ドライブに対しての設定を想定して記述しています。

1. 左サイドバーから「Settings templates」⇒「Migrate to shared drives（共有ドライブの場合）」、「Migrate to My Drive（マイドライブ）」の鉛筆ボタンをクリックする

2. Migrate SharePoint to shared drivesにチェックボックスが並ぶので移行する要件に応じてチェックを入れていく

3. 「Filter SharePoint content」は除外する設定なので特に設定不要

4. 「User Mapping」は必要に応じて。通常はMap Usersのチェックは外す

5. Create new templateをクリックしてテンプレートを保存する。ダイアログが出たらCREATEをクリックする。

6. マイドライブ用設定も同様に行います。

設定テンプレートのオプションについてはこちらに一覧で記載があるので必要なものをチョイスしてチェックします。

図：Sharepointのテンプレートの事例

スコープビューの作成

前述で作成したConnectionに対して、色々とスコープを設定します。

1. トップ画面に戻り、左サイドバーのConnectionをクリックする

2. 作成済みコネクションの行の右端にある「スコープビュー」アイコンをクリックする

3. 画面右上の＋ボタンをクリックする

4. 適当な名称を入れてCreateをクリックする

5. スコープビューが作成されるので、その行の右端にあるEntrieアイコンをクリックする

6. 画面右上の＋ボタンをクリックする

7. ダイアログでは「Add entries manually」をクリックする

8. ツリービュー形式でSharepointのサイトの内容が出るので、必要なものにチェックを入れてNextをクリックする（通常はドキュメントのみでオッケー）

9. 確認画面が出たらAddをクリックする

10. 必要なサイト全てに対してこの設定を行っていく。

11. スコープビュー画面に戻ったら、作成したエントリにチェックを入れて、右上メニューのValidateである「✔」をクリックし、検証を開始する

12. 検証が完了したら、対象のエントリーのValidityが緑のチェックが入る

13. これも必要なエントリー分全て行う。

図：ScopeviewのValidityの実行

スキャンの実行

ここまできたら、対象のSharepointのファイルの中身についてスキャンを実行することになります。

1. トップ画面に戻り、左サイドバー上部のNewをクリック⇒Scanをクリックする

2. Scan Nameを適当に入力し、Connectionでは前述で作成したSharepointのものが出てくるので選択する

3. Scan ScopeはFullを選択し、Crawl Ruleはデフォルト値のまま。

4. Report Typesは必要なものすべてにチェックを入れてCreateをクリックする

5. 作成されたスキャンを持って、▶の開始ボタンをクリックする

6. スキャンが実行されるので完了するまで待つ（Completedになる）

これでファイルの状況が検出されます。

マッピングの作成

ドライブのマッピングの作成

まずはSharepoint→共有ドライブをマップするマッピングを作成します。共有ドライブか？マイドライブか？で分かれるのでそれぞれに対してどの共有ドライブに割り振るのか？を定義する必要があります。

1. CSVファイルを作成する
2. タイトル列に「Source SPLibrary, Target GUser, Target GSharedDrive」の3列を用意し、それぞれにSPLibraryにSharepointのライブラリまでのURL、Target GUserには書き込みを担当させるGWSアカウント、Target GSharedDriveには書き込み先共有ドライブのIDを入れる
3. CSVに対して必要な分だけ行を追加して上記のようなデータを追記していきます。

4. トップ画面に戻り、左サイドバー上部のNewをクリック⇒Mappingをクリックする

5. Nameに適当な名前を入力し、source connectionには移行元のSharepointのコネクションを指定する

6. target connectionには移行先のGoogle Workspaceのコネクションを指定する

7. Createをクリックする

8. 作成されたマッピングの行の右端にあるEntrieアイコンをクリックする

9. 次の画面の右上の＋ボタンをクリックする

10. マイドライブへの場合は、Add entries manuallyをクリックして以下の作業をします。

    1. 移行元コンテンツが表示されるので移行対象にチェックを入れてNextをクリックする

    2. 移行先選択では「MyDrive」にチェックを入れてNextをクリックする

    3. 確認画面では「Map content only」のスイッチをオンにしてAddをクリックする

11. 共有ドライブへの場合は、以下の手順を行います。

    1. 「import Entries to mapping」ではUpload CSV Fileをクリックします。

    2. CSVファイルを指定します。

    3. importボタンをクリック

12. マップが作成されたらそのエントリにチェックをいれて右上のValidateアイコン（チェックマーク）をクリックする

13. 検証が終わってステータスがValidityになったら完了。

14. これを必要な全移行パターン分行っていく。

マッピング作成についてはこちらのページに事例が掲載されてるので参考にしましょう。

IDマッピングの作成

IDマッピングは移行元ドメインと移行先ドメインが異なる場合に必要です。同一ユーザについてどのメアドがGWS側では対応するのか？を記述してあげないと、共有ドライブのアクセスメンバー割当に支障が出てしまいます。

1. CSVファイルを作成する
2. タイトル列ナシで、1列目がM365側メアド、2列目がGWS側メアドを登録
3. 必要なユーザ全員分を入れていきます。
4. 左サイドバー上部のNewをクリック⇒Other mappingをクリックする
5. TypeはIdentitiesを選択します。

6. CSVは前述で作成したIDマッピングのCSVを指定します。

7. Createをクリックする

図：IDマッピングの事例

ロールのマッピング

Sharepoint特有のマッピングでM365側の権限がGWS側ではどの権限に対応させるのか？を指示するものです。オプションなので必須ではないのですが、共有ドライブに対するアクセス権限に影響を与えます。CSVでも出来ますが一覧がどこにも見当たらないので、手動でUI上で指定しましょう。

1. 左サイドバー上部のNewをクリック⇒Other mappingをクリックする
2. 目的のロール マッピング名にカーソルを合わせ、エントリ アイコン  をクリックします
3. Add entries manuallyをクリックする
4. 移行元と移行先の値を入力します。さらに値を追加する場合は、追加アイコン  をクリックし、新しい値を入力します。
5. Addをクリックして、あとは必要な権限名分同じ様に追加していく

ブリッジの作成と実行

最後にブリッジを作成します。この作成が完了したらいよいよ移行作業の実施になります。

1. トップ画面に戻り、左サイドバー上部にある「New」をクリック⇒Bridgeを選択する

2. Nameは適当に入力し、Source ConnectionはSharepoint用Connectionを選択

3. Target ConnectionはGoogle Workspace用Connectionを選択

4. Settings Templateは前項で作成したテンプレートを指定する

5. Mappingは前述で作成したMappingを指定する

6. IDマッピングやロールのマッピングも指定します。
7. More optionsをクリックして、シャーディングユーザリストを指定します。

8. 他の項目は入力せずにCreateをクリックする

9. 作成したブリッジを開いて、▶ボタンをクリックして「Run」を実行すると移行作業開始です

10. 移行が実行されて、Completedになったら完了です。（相当時間が掛かります）

11. 移行先共有ドライブを開いてみて、移行元と同じようなレイアウトで移行できてるかを確認する

後日、もう一度この画面でRunを実行して差分アップデートを行わせることも可能です。ブリッジやマッピングはサイト毎に作成して実行すると後でエラー発生時のトラブルシューティングがやりやすい。

エラー対策や差分アップデート

ログ関係

GWMのログの確認

Google Workspace Migrateのセッティングを行っていて、エラーが出たりうまくいかないことは多々あります。これらのメッセージ類に関してはこちらのドキュメントにもあるように以下の場所にログが保存されています。

• Platform : C:\Program Files\Google Workspace Migrate\Google Workspace Migrate Platform\AppBridgeServiceHost.log

• Node : C:\Program Files\Google Workspace Migrate\Google Workspace Migrate Platform Node\AppBridgeServiceHost.log

新しいログは一番下に記述されています。

Partition LogとExecution Logについて

GWMのGUI上では移行完了後に各種ログが手に入ります。このうちPartition LogとExecution Logは以下の手順で入手可能です。ログに関するドキュメントはこちら。この作業を行うにはPlatformサーバとMySQLサーバが起動されてる必要性があります。

1. ブリッジがCompletedのステータスに有り完了してることを確認する

2. 右上の時計のアイコンをクリックしてブリッジログを表示する

3. サブメニューから各種ログの名前をクリックする（Partition logとExecution logはGWM自体の実行ログです）

4. 次の画面の右上のダウンロードをクリックするとログが手に入る。Download logs and detailsをクリックするとCSV形式で手に入ります。

5. このログはフィルタして特定のものに絞ってからダウンロードも可能です。行数が多すぎてログが見られないケースがあるので絞り込みしてからのログ閲覧を推奨（期間やソースタイプなどでフィルタ可能）。

6. ログはZIPで固められてるのでアーカイバで解凍するとCSV形式で手に入ります

あとはこのCSVを覗いて、個別に対応を決めていくことになります。できれば途中で１アカウントログインしてみて実際にデータが移行されてるか？確認するほうがベストでしょう。

ブリッジのTransaction Logについて

GWMの移行完了後にブリッジのTransaction Logをダウンロードしようとしたらアプリのセッション切れで何度やってもログがダウンロードできない現象に遭遇（Failed to generated log reportというエラー）。1000件程度ならばダウンロードできるものの、巨大なログになってる場合にはこの問題にぶつかります。

しかしこれに対して、Google側が2024年12月4日、v2.4.20.0にて別の手段としてコンソールから実行することでダウンロードできるようにする対応が成されました。

ただし、GWM上ではなくGWMがインストールされてるサーバー上でコマンドラインツールから叩くことでログを出力できるようになったようです（Path-to-log-toolというツールで色々事前準備は必要）。

エラー対策

対応策

エラーは偶発系（再実行でだいたい内部エラーは消える）が殆どです。ただしSharepointで言えば。、2GB, 750GBのリミットや共有ドライブ制限を超えたものはFailに残り続けるので、これらは個別に解消が必要です。

偶発系のエラーとはGWM実行時のMicrosoftやGoogle側、もしくは途中の経路のネットワーク絡みの一時的なエラーであり、場合によってはQuotaに関するものである場合もありますが、概ね再実行で解消出来ます。

エラー特定法

エラーが発生した場合は対象のファイルを特定する必要があります。ただ、大半は後述にあるように再実行で解消することが多い為、まずは再実行を試して尚エラーが出るものについて特定するようにすべきでしょう。

1. ブリッジログのTransaction Logを手に入れる

2. CSVファイルを開いてみる

3. Source Nameがエラーになったファイル名、Source LinkがエラーになったファイルのURLとなります（Sharepointの場合）。

4. Source Nameが該当するオブジェクトのメールタイトルとなっている（Exchangeの場合）。ただタイトルとメアドしかわからない。

5. Error Codeの列がエラーコードでこちらにエラーコードと内容が記述されてるので確認する。

6. CSVにエラーコードの記載が無いケースがある。

差分アップデート

概要

エラー発生時や並行稼働期間を設けて、Microsoft365から再度同期を掛けてアップデートをするといったシーンで利用します。MySQLサーバにファイル類の情報が記録されており、タイムスタンプの比較などをもって既に同一のファイルである場合はスキップ（差分アップデート）してくれます。

再実行時の注意点

前述のようにエラーが出てるものに対して再実行をして移行を試みるのが再実行なのですが、この時注意しなければならない点があります。

それはそのままでは「再実行は、初回実行時から再実行時までの間に増えたオブジェクトも移行対象になる」という点。メールなどの場合、GWMでの移行時は通常並行して相手サーバからGoogle Workspaceに対して「転送処理」を掛けているので、この再実行によって増えたオブジェクトはどうなるか？といったら、GWMが知らないオブジェクトであるため、「新規移行処理」の対象となってしまいます（ただし同じメールは1個に統合されるので重複してメールボックスに存在するといったことは発生しない）

結果、再実行の処理時間に大きく影響を与える為、とくにExchangeからの以降の場合には、再実行時には「ブリッジに日付フィルタを設定して初回実行時より前のメール」という指定をしてから再実行をすることで、初回実行時以降増えたものを除外することが可能です。

差分アップデートログの確認

一度エラーになったものを再度実行にて差分アップデートした場合などで、対象のファイルがきちんとアップロードされてるかどうかを確認する方法です。

1. Transaction Logを手に入れる

2. フィルタして特定のファイルだけを見つけて、行の右にある「︙」をクリック⇒Object transactionsをクリックする

3. 同一ブリッジ内での処理結果の履歴が見られる。上から順番にFailed⇒Completed⇒Skippedと遷移していく様子がわかる。Completedの時点で完了済みなので以降はSkippedとなる。

移行完了後の作業として

概要

移行完了後の作業もやることは盛りだくさんです。このエントリーではデータ移行についてだけ記していますが、以下のエントリーにて移行後に行うべきGoogle Workspaceの各種設定や設計についてもまとめています。引っ越してそのまま吊るしの状態で使えるほど甘いものではありません。

セキュリティ対策やユーザへの研修などなどこれらも見逃しがちな項目ですので事前の移行計画にしっかりと盛り込んでおきましょう。

Google Workspaceを新規に導入する時に押さえたいポイント

Teamsのチャットログの移行

Google Workspace Migrateには現在Teamsからのチャットの移行については機能が装備されていません。しかし、TeamsからGoogle Chatへの移行ツールについては別に用意されています。こちらはGoogle Workspaceの管理コンソール上から利用できるツールとなっている為、サーバを立てる必要はありません。

しかし弱点として

• Teamsにアップしたファイル類についてはSharepointの領域であるため移行されません（よって、Sharepointからのファイル移行は別にする必要があり、またチャット内のリンクも継承出来ません）
• チャンネルのチャットについて移行対象になりますが、個別の1:1のチャット等については移行対象外です。

Google Chat APIが用意されているので、Graph APIを利用すればTeamsの個別チャットの移行やSharepointのファイルを移行しつつチャンネルのチャットを移行するようなものは作れるかもしれませんが、自分で構築する必要があります。

TeamsからGoogle Chatへ移行するツールを検証してみた

VBA資産をどうするか？

情シスやSIerの方々が軽視しがちな「VBA資産」。現場の人間にとってはこれまで業務改善や補助で大いに活躍してきた重要な資産です。しかし、VBA→Google Apps Scriptの変換は対象の数やVBAコードの内容によってその移行難易度は大きく変わります。

またこれを実現するようなソリューションというのは正直存在してるとは言えませんでした。

しかし、2024年生成AIが大きく躍進した結果、GeminiやChatGPT、Claudeを土台にしてVBAからGASへのコード変換が割と実用的なレベルに来ました。マクロの記録で作成したようなレベルであればほぼ移行が可能です。ガッチリ作り込まれたVBAについてはまだまだ手直しが必要でしょうが、そこまで数は多くないハズ。

ということで、VBA→GAS（またExcelはスプシに）変換する仕組みをGeminiを使って構築してみました。Google Workspaceへの移行後の大きな仕事の一助として使ってみてはいかが？

Geminiを使ってVBAからGoogle Apps Scriptに変換する仕組みを作る【GAS】

移行しきれなかったものについて

SharepointにせよExchangeにせよ再実行によって概ねエラーを解消して移行することは出来ますが、それでも救えない・移行できなかったものというものはどうしても発生してしまいます（概ね1%から2%程度）。

Transaction Logを出力した結果はただのログでしかない為、このデータを元に対象のファイルやメールを特定して手動で移行などの手当が必要な場合があります。しかし、Transaction Logにはメールで言えば「メールIDなどの情報はなく、メールのSubjectとアカウントのメアド」の情報だけが手がかりになります。

この時の手立てとしては

• Sharepointの場合はRcloneを利用して対象のファイルだけを手動で移動する

• Exchangeの場合は、対象のメールを対象ユーザが手動でOutlookからGmailの「テストドメインエイリアス」宛に転送する

• Microsoft Graph APIを利用してファイルの移行やメールの移行を手動で行うツールを作成する.

• Outlookから対象のメールをemlやmsg形式のファイルとしてエクスポートしてドライブにでも保存してもらう

エラー件数が多い場合には、特にExchangeの場合は個別ユーザ対応となってしまうため、こういったリスクがあることをそもそも作業をする前に説明して同意を得ておく必要があります。

Microsoft365の契約を解除するまでの間をこの対処期間としてスケジュールを立てる時点でも考慮しておくべきでしょう。

rclone browserでGoogle Driveにガッツリ同期させる

Google Apps Scriptで特定のメールに対して自動アクション

個別ユーザにエラーの通知

OneDriveのファイルであったり、Outlookのメールであったり前述の手段を持ってしても何故か移行出来ないケースはあります。ファイルが壊れていたりパーミッションの関係で拒否されてしまったり。

こういったケースではユーザ個人単位で手動での移行をしてもらう他ありません。しかし、どのファイルどのメールがNGなのか？がわからなければ移行できません。そこで利用するのが前述でも出てきたTransaction Logです。

ログにはファイルやメールの所有者のアドレスとタイトルが記載されているので、これを元に個別にユーザに通知してあげます。ただこのCSVファイルは結構なファイルサイズですし、これをユーザ個別に通知用のSpreadsheetに落とし込んでメールで通知する仕組みが必要になります。ここは自作する必要があります（VBAなりGASなりで）。

また、このTransaction LogはMySQLサーバに格納されているものなので、直接SQL文を叩いて出力データをCSVに切り出して個別にメールで通知といったようなプログラムも作れるでしょう。この時利用するテーブルは以下の4つです。Accessあたりでうまいことクエリを構築して作るのが最速でできるのではないかと思います。

テーブル名	内容
appbridgeidentity	移行実行させたデータのSubject等が確認できる
bridgetransactions	トランザクションログ本体と思われるデータ. エラーコードなども格納されてる
bridgeexecutionlogentries	ログの詳細なエラー内容と思わしきデータ
googlefileids	添付ファイル名が格納されてる

• bridgetransactionsのerrorcode列には400や60008といったエラーコードが格納されている
• また、state列は1,4,5,7といった数値があり、1 = warning, 7 = Skip, 4 = Completed, 5 = failであろうということが推測される
• MySQLから引き抜けるならばAPIなど叩かなくて済むので比較的簡単な仕組みでデータを再構成できる。

• Microsoft Access + MySQL ODBC Driverにて接続し（リンクテーブル）、データを抽出→クエリを構築して1枚にする

• 上記のクエリからExcel形式なりCSV形式なりでデータを整形して出力する

• ブリッジ単位でテーブルが作成されるので、その当たりは調査が必要。
• MySQL側でエラーコード1290（--secure-file-priv）が出る可能性があるので、事前に対処が必要です。
• MySQLサーバからのデータの引き抜く方法の１つとして、HeidiSQLを使ってテーブルのScheme含めてデータを塊（拡張子sql）をエクスポートする事が可能です。MySQL Workbenchを使う手法もあります。
• SQLファイルとしてエクスポートする場合には、以下の2点に注意

  • データのエクスポートにはDBやテーブルのCreate文は必ず含める

  • データの追加はDropは含めず、Insertとして含める

• 別のMySQLにインポートする場合は、対象のDBのテーブルを開けてる状態でインポートしようとするとエラーとなって止まるのでテーブルは開かないようにしましょう

• 但し結果のレコード数やデータサイズから考えて、制限のあるAccessで編集は難しい場合(ファイルサイズ2GB制限)がある。

• Excelも1,048,576 行の上限値があるため、CSVでしか出力が難しいケースがある。

MXレコードの切り替え

移行も完了し、いよいよ本番運用というときに忘れがちなのが「MXレコードの切り替え作業」。これは従業員が仕事終えた後の夜間に行うと良いでしょう。切り替えてもすぐにはDNSに浸透しないので、暫く待ち実際にメールを送って届くかチェックが必要です。

この時注意すべきは

• Microsoft365側の転送設定を解除しておく（テストメールが転送されて届いてしまいテストにならない）
• DNSのMXレコードは「SMTP.GOOGLE.COM」を指定する
• テストメール送信先はテストドメインエイリアスではなく本番のドメイン宛です

DNSによっては.COMの後に「ピリオド」が必要になります。利用してるDNSサーバの仕様をよく調べてセットしてください。さくらインターネットはピリオドが必要です。

関連リンク

• Exchange Online での Google ワークスペースの移行の前提条件
• Exchange Online における転送設定を制御する方法
• 二重配信を使用して複数の受信トレイにメールを配信する
• 一部の社員だけGoogle Workspaceを導入する方法
• 外部メール アドレスへの自動転送がブロックされる
• 組織外のユーザーへ自動転送されません。自動転送を許可する方法を知りたいです。
• メールがブロックされ、送信者にエラーが返送されてしまいます。
• EOP で送信スパム ポリシーを構成する
• Exchange Online PowerShell を使用してユーザー メールボックスのプロパティを変更する

• 管理センターの Microsoft 365 レポート - メールボックスの使用状況

• Google Workspace Migrate Gmail API Limit

• MYSQLが吹っ飛んだ

• ある日、目が覚めたらMySQLが「Can't connect to MySQL server on '127.0.0.1'(10061)」になっていた時の備忘録

• MySQLをstartしたら[ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't existがでたとき