通知

Duet AI は Gemini for Google Workspace になりました。詳細

GWMME のトラブルシューティング

Google Workspace Migration for Microsoft Exchange

Google Workspace Migration for Microsoft Exchange (GWMME) で問題が発生した場合は、GWMME ツール内のテスト、レポート、ログ機能を使ってトラブルシューティングを行うことができます。後述の問題のトラブルシューティングに、GWMME での移行に関する一般的な問題と対応方法が記載されていますので、詳細はそちらをご確認ください。

Log Analyzer を試す

このツールを使うと、ほとんどの問題を送信から数分以内に特定できます。

GWMME のトレースログは C:\ユーザー\[ユーザー名]\AppData\Local\Google\Google Apps Migration\Tracing\ExchangeMigration にあります。

GWMME トレースログ ファイルの例は、後述のログを調べるでご確認ください。

GWMME を使用したトラブルシューティング

GWMME のテストとレポート機能を使うことで、移行のトラブルシューティングをスムーズに行えます。

方法 説明 詳細
診断テスト データ移行前に診断テストを行うと、設定やユーザーリストに関する問題がないか確認できます。問題があると診断ユーティリティからエラーが通知され、出力画面に情報が表示されます。 GWMME 管理ガイドの「Migrate data」(データの移行)の章
移行レポート

移行後に移行レポートを見ることで、エラーの有無と発生理由、影響を受けているユーザーを確認できます。

注: レポートデータはローカル コンピュータの Microsoft Windows ユーザー プロファイルに保存されます。GWMME を実行した Windows ユーザーのみがレポートを確認できます。

GWMME 管理ガイドの「Migration reports」(移行レポート)の章

問題のトラブルシューティング

以下は、移行に関する一般的な問題とおすすめの対応方法をまとめたものです。

移行に関する問題を解決する  |  移行の失敗を修正する  |  エラー メッセージを解釈する  |  Google Workspace サービスと GWMME

移行に関する問題を解決する

セクションを開く  |  すべて閉じて一番上に移動

管理者の Exchange プロファイルを作成できない

以下の理由が考えられます。

  • Exchange サーバーが実行されていない。
  • ネットワークの問題によって、クライアント コンピュータと Exchange サーバーとの接続が妨げられている。接続を確認するには、クライアント コンピュータからサーバーに ping を行います。
  • Exchange サーバーまたは管理者のユーザー名が間違っている。この情報を確認するには、次の操作を行います。
    1. クライアント コンピュータで、[コントロール パネル] 次に [メール] をクリックし、移行に使用する管理者アカウントの Microsoft Outlook プロファイルを作成します。
    2. GWMME の [Step 1 (Server Details)] 画面で次の操作を行います。
      • [Hostname/IP Address] 欄に、プロファイルの Exchange ホスト名を入力します。
      • [Admin username] 欄に、プロファイルのユーザー名を入力します。

ホスティング型サーバーから移行する場合は、管理者アカウントのプロファイルでデフォルトの設定を使用してサーバーに接続する必要があります。[コントロール パネル] 次に [メール] 次に [プロファイル名] 次に [プロパティ] 次に [電子メール アカウント] 次に [プロファイル名] 次に [メール アカウントの変更] 次に [詳細設定] でいずれかの設定を変更すると、サーバーに接続できません。

移行に使用する管理者のユーザー名を Exchange Server が認識しない

管理者のユーザー名とパスワードが正しいことを確認してください。

問題が解決しない場合は、Exchange Server のユーザー名が正しいことを確認してください。

  1. クライアント コンピュータで、[コントロール パネル] 次に [メール] をクリックし、移行に使用する管理者アカウントの Outlook プロファイルを作成します。
  2. GWMME の [Step 1 (Server Details)] 画面で次の操作を行います。
    • [Hostname/IP Address] 欄に、プロファイルの Exchange ホスト名を入力します。
    • [Admin username] 欄に、プロファイルのユーザー名を入力します。
GWMME が起動直後にクラッシュする

GWMME が起動直後にクラッシュする場合は、実行しているコンピュータが Exchange サーバーではなくクライアント コンピュータであることを確認してください。GSMME をサーバーで実行すると、クラッシュすることがあります。詳しくは、Microsoft のドキュメントをご覧ください。

GWMME のクラッシュの原因として負荷分散の問題が考えられる場合は、GWMME 管理ガイドの「Prepare your Windows client machines」(Windows クライアント コンピュータの準備)をご覧ください。

ウイルス対策ソフトウェアまたはプラグインが原因の問題

コンピュータで動作する別のプロセス(例: ウイルス対策ソフトウェア、検索、バックアップ ソフトウェア)が、移行中にデータベース ファイルへの GWMME のアクセスを妨げることがあります。この問題が発生した場合、ログファイルには次のエラーコードが記録されます。

0x80040109
Fail:While stamping the message

メールは移行されていますが、移行の成功情報が GWMME に保存されていません。[Only New Data] チェックボックスをオンにして移行を再実行した場合、これらのメールの移行が GWMME で再試行されます。その場合もメールの重複は発生しませんが、カレンダーの予定または連絡先で重複が発生することがあります。

移行の失敗を修正する

セクションを開く  |  すべて閉じて一番上に移動

1 人のユーザーの移行に失敗する

1 人のユーザーの移行に失敗した場合は、次の点を確認してください。

  • ユーザー名または SMTP アドレスがユーザー ファイルに正しい形式で入力されている。
  • ユーザーがグローバル アドレス一覧(GAL)で非表示になっていない。
  • ユーザーのアカウントが Exchange サーバーに存在する。
  • ユーザーが Google Workspace にログインし、利用規約に同意して Google Workspace アカウントの作成を完了している。
OAuth エラーが原因で移行に失敗する

次のトラブルシューティングの手順に沿って、GWMME の OAuth 検証エラーをすべて解決します。

  • アカウント向けに GWMME を承認するの手順どおり、ソフトウェアをドメインで適切に認証しているか。
  • CSV ファイルに記載された Google Workspace ユーザーとパスワードが正しいか。CSV ファイルに 1 つでも誤りがあれば移行に失敗する可能性があります。詳しくは、移行用の CSV ファイルを作成するをご覧ください。
  • GWMME を実行しているコンピュータのシステム クロックが、正しい時刻に設定されているか。コンピュータのクロックの時刻がずれていると、OAuth の検証中に間違ったローカル タイムスタンプが Google のサーバーに送信されてエラーとなります。コンピュータをインターネット上のタイムサーバーと同期してください。
  • GWMME の認証に使用した Google Workspace ドメインの特権管理者アカウントが有効であり、そのユーザー名が GWMME の設定で誤って入力されていないか。
Google Workspace ユーザーが存在しないことが原因で移行に失敗する

GWMME には Google Workspace のユーザーをプロビジョニングする機能はありません。データの移行前に Google Workspace のユーザー アカウントを作成してください。

エラー メッセージを解釈する

セクションを開く  |  すべて閉じて一番上に移動

ネットワークまたは TLS の問題のログを確認する

ネットワーク エラー(ネットワーク タイムアウト、接続拒否など)または SSL / TLS の問題(接続のセキュリティに関する問題など)が発生すると、接続試行先 IP アドレスがログに記録されます。接続のセキュリティに関する問題が発生した場合は、その原因(証明書の名前の不一致、証明書の期限切れ、CRL チェックの失敗など)と証明書の詳細(Google 証明書、HTTPS 検査プロキシなど)がログに示されます。こうした記録により、トラブルシューティングの目的でネットワーク キャプチャを取得する必要性が大幅に軽減されます。このことは、メインのログ(Trace-*.log)と認証ログ([Identity] フォルダ内)の両方について言えます。

認証ログの例

[2022-09-21T03:59:46:ERROR:windows_http.cc(331)] TLS connection failure. See details below. [Status: 0x00010000. Status Info: 0x00000001]
[2022-09-21T03:59:46:ERROR:windows_http.cc(340)] Certificate details:
---Validity--
Valid from: 2017-09-13 17:23:55 UTC
Valid until: 2017-12-06 17:10:00 UTC
---Subject---
US
California
Mountain View
Google Inc
*.googleapis.com
---Issuer----
US
Google Inc
Google Internet Authority G2
-------------
[2022-09-21T03:59:46:ERROR:windows_http.cc(282)] WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED: Certification revocation checking has been enabled, but the revocation check failed to verify whether a certificate has been revoked. The server used to check for revocation might be unreachable.
[2022-09-21T03:59:46:ERROR:windows_http.cc(197)] Error from API WinHttpSendRequest with WinHTTP proxy. Will try direct (without proxy). Code: 0x00002f8f
[2022-09-21T03:59:46:ERROR:windows_http.cc(107)] Network connection destination details: 216.58.194.170:443 (sfo07s13-in-f170.1e100.net)

この場合、パソコンの現在日設定が 2022 年に変更されていたため、証明書が期限切れと判断されました。現在の日付は各ログ行の先頭に記載されています。この例では、証明書の「Valid from」と「Valid until」の日付が現在の日付と一致しません。エラーフラグ WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED は、証明書失効チェックが失敗したことを示します。

また、ログの最終行の「Network connection destination details」の後には、接続先 IP アドレスと解決されたホスト名が記録されています。これは 1e100.net address(Google)のアドレスです。

トレースログの例

注: これは GWMMO ログの例です。ネットワークまたは TLS の問題が発生した場合、同様のトレースログ エントリが、GSMME、Password Sync、GWSMO でも記録されます。

2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2025 ()> Secure connection failure. Status: 0x00010000. Info 0x00000009
2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2030 ()> Failure details:
WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED: Certification revocation checking has been enabled, but the revocation check failed to verify whether a certificate has been revoked. The server used to check for revocation might be unreachable.
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA: The function is unfamiliar with the Certificate Authority that generated the server's certificate.
Certificate details:
---Validity--
Valid from: 2016-09-20T04:08:45.000Z
Valid until: 2022-09-20T04:08:45.000Z
---Subject---
Created by http://www.fiddler2.com
DO_NOT_TRUST
*.google.com
---Issuer----
Created by http://www.fiddler2.com
DO_NOT_TRUST
DO_NOT_TRUST_FiddlerRoot
-------------
2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2071 ()> Error result 5, hr = 0x80072f8f. Setting event 0000000000001638.
2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2076 ()> Network connection destination details: 127.0.0.1:8888 (COMPUTERNAME)

この場合、Fiddler がインストールされ、HTTPS 復号を行う(独自の証明書を使用する)ように設定されていますが、その証明書は Windows の信頼できる証明書リストから削除されているため、信頼できません。Fiddler はプロキシであるため、Google ではなく 127.0.0.1 に接続していることがわかります。エラーフラグには WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA が含まれています。これは、認証局 (CA).  がシステムによって信頼されていないことを意味します。この証明書は Google が発行したものではないこともわかります。

ここで示されたサンプル テキストは、攻撃者であれば簡単に偽造できるため、認証には絶対に使用しないでください(代わりに CA 署名を使用してください)。ただし、SSL インスペクションまたは中間者(MITM)攻撃を行うファイアウォール / プロキシの設定の問題を特定するのには有用です。
エラー 0x80070005 で移行に失敗する

出力画面またはトレースログ ファイルに、次のようなエラー メッセージが表示されます。

E:Generic ExchangeMigration!SetPropertyGuid @ 641 (user@example.com)> Failed with 0x80070005, last successful line = 637.

この問題は通常、ユーザー アカウントに必要な権限がないことが原因で発生します。解決するには、Exchange でアカウントに「受信者」の権限を付与します。

アカウントに「受信者」権限を設定してもエラーが解決しない場合は、ユーザー アカウントに「送信者」権限の付与も必要な可能性があります。

Exchange 2010 からの移行で GWMME 0x80004005 エラーが発生する

一部のユーザーが Exchange 2010 からの移行に失敗すると、トレースログ ファイルに「Failed with 0x80004005」エラーと次の内容が記録されます。

  • Exchange 2010 へのランダムな MAPI 呼び出し。
  • Exchange Server 2010 クライアント アクセス サーバーのリモート プロシージャ コール(RPC)クライアント アクセス ログの「BufferTooSmall」エラー。

これは Exchange 2010 と Outlook 2007 / 2010 で報告されている問題で、Exchange 2010 SP2 RU3 へのアップデートが必要となる場合があります。詳しくは、MAPI 呼び出しの失敗エラーに関する Microsoft のドキュメントをご覧ください。

メールがアップロードされず、0x8004106a エラーが発生する

HTTP エラーコード 500、502、503 が何度もログに記録され、エラーコード 0x8004106a が発生してメールがアップロードされない場合は、対象となるメールボックスに問題があることが考えられます。通常は負荷が高いことが原因です。

この問題を解決するには、対象となるメールボックスの負荷が高くならないよう、次の対応を行ってください。

  • 同期クライアント(IMAP、POP、モバイル デバイス、メール クライアントなど)を無効にする。
  • 一度に 1 つの移行元からのみメールを移行する。

Google Workspace サービスと GWMME

セクションを開く  |  すべて閉じて一番上に移動

移行した Google カレンダーの予定が正しく更新されない

次の問題は、ユーザーが正しくプロビジョニングされていないことを示しています。

  • カレンダーの予定を変更しても参加者と共有されない
  • カレンダーの通知と更新が参加者のカレンダーに反映されない

部分移行のみを行う場合でも、アカウントを移行する前に、Google Workspace ですべてのユーザーをプロビジョニングしてください。すべてのドメイン エイリアスとニックネームが追加されていることを確認します。その後、問題を解決するために、このユーザーが主催者またはゲストとなっている予定をすべて削除して作成し直します。

連絡先とカレンダーの移行時に 403 エラーが発生して失敗する

デフォルトの設定により、GWMME では毎秒 25 ユーザーが移行されます。これは Contacts API と Calendar API の両方のデフォルトの秒間クエリ数(QPS)を上回っています。

この問題を解決するには、連絡先とカレンダーの移行を次のように実施します。

  • メールとは別に移行する。
  • 移行ペースを毎秒 4~8 ユーザーになるように下げる。
一部のメールのみ移行に失敗する

一部のメールの移行に失敗する場合は、それらのメールが Gmail のサイズの上限を超えているか、Gmail でブロックされている種類のファイルがメールに添付されていることが考えられます。詳しくは、Gmail でブロックされるファイルの種類をご覧ください。

また、フォルダサイズの制限をなくして、フォルダが IMAP に表示されることの確認が必要な場合があります。詳しくは、管理アカウントで POP と IMAP の有効、無効を設定するをご覧ください。

Gmail のメール数と移行元アカウントが一致しない

Google Workspace で移行後に表示される受信トレイ内のメール数は概算であり、正確な数を示しているわけではありません。このため、Gmail の受信トレイ内のメール数が以前の受信トレイ内のメール数とは異なることもあります。

見つからないメールがある場合は、以下を確認してください。

  • メールのサイズ(添付ファイルを含む)が 25 MB を超えていないか確認してください(25 MB を超えるメールは移行できません)。詳しくは、Gmail のメールにファイルを添付して送信するをご覧ください。
  • Gmail でメールの添付ファイルがブロックされていないか。Gmail では、実行可能ファイルといった一定の種類の添付ファイルがブロックされます。詳しくは、Gmail でブロックされるファイルの種類をご覧ください。
  • メールがフォルダ内にある、または移行対象期間内のものであるか。
メールが見つからない、または移行されたメールの送信者もしくは受信者が正しくない

Exchange または PST ファイルの移行でメールが見つからない、または移行されたメールの送信者もしくは受信者が正しくない問題が発生することがあります。メールの送信者または受信者の SMTP アドレスが見つからなかった場合、代わりに Exchange X.500 アドレスが使用されます。これは、グローバル アドレス一覧(GAL)プロファイルが作成されていない場合、またはユーザーが GAL から削除されている場合に発生することがあります。

GWMME で X.500 アドレスが見つかった場合

GWMME で X.500 アドレスが見つかると、移行サーバーに登録された MAPI メール プロファイルから X.500 Exchange 組織名と一致するプロファイルが検索されます。見つかったら、その MAPI メール プロファイルのアドレス帳登録を使用して、X.500 アドレスが解決されます。

Exchange アドレス帳でこの情報が見つからない場合、X.500 アドレスから SMTP アドレスへの変換が試みられます。これを行う場合は X.500 アドレスの最後の CN 値が考慮され、その値がメールアドレスのユーザー名として使用されます。たとえば、X.500 アドレス /O=ExchangeOrg/OU=CA/CN=RECIPIENTS/CN=EX_ALIAS は、ex_alias@example.com という SMTP メールアドレスに変換されます。

Exchange アドレス帳を使用して X.500 アドレスを解決する方法

  1. 移行を実行するサーバーに(非キャッシュ モードの)MAPI メール プロファイルを作成します。
  2. PST 移行の実行に使用されるサーバーに MAPI メール プロファイルが設定されていることを確認します。
  3. GWMME で GAL を使用して受信者を適切に処理できるように、MAPI メール プロファイルを元の Exchange サーバーに接続します。
  4. 認証エラーを回避するために、現在ログインしているユーザーまたはサービス アカウントで MAPI メール プロファイルを設定します。

重要な注意事項

移行の設定が正しいことをテストで確認します。問題が解消しない場合、再移行しても Google アカウントに移行済みのデータは更新されません。移行したメールデータを削除し、ゴミ箱からも削除した後に再移行してください。

Gmail でメールが間違った日付で表示される

移行されたメールに元のメールの日時ではなく、移行された日時が表示される場合があります。

元のメールの日付ヘッダーが RFC 5322 に準拠していないことが原因である可能性が高いと考えられます。メールに含まれる日付ヘッダーの形式が正しくない場合、Gmail では移行の日時がメールに適用されます。

「User neither attendee or organizer for event」(予定の参加者でも主催者でもないユーザー)という警告が表示される

当初の主催者でも参加者でもないユーザーの予定を読み込むと、この警告が表示されます。

警告メッセージが表示された場合でも、その予定は Google Workspace に正常に移行され、Google カレンダーの予定には移行先の Google Workspace ユーザーが参加者として表示されます。Google カレンダーでは、主催者または参加者ではないユーザーに対するカレンダーの予定のリスト表示がサポートされていないため、この警告が表示されます。

関連トピック


Google、Google Workspace、および関連するマークとロゴは、Google LLC の商標です。その他すべての企業名および商品名は、関連各社の商標または登録商標です。

この情報は役に立ちましたか?

改善できる点がありましたらお聞かせください。
検索
検索をクリア
検索を終了
メインメニュー
16859258463130543417
true
ヘルプセンターを検索
true
true
true
true
true
73010
false
false