排解 GWMME 問題

這個問題的可能原因如下：

• Exchange 伺服器並未執行。
• 網路問題導致用戶端電腦無法與 Exchange 伺服器連線。如要驗證連線狀態，請透過用戶端電腦對伺服器進行連線偵測 (ping)。
• 您使用的 Exchange 伺服器或管理員名稱有誤。如何驗證這項資訊：
  1. 在用戶端電腦上依序點選「控制台」 「郵件」，為您要用於遷移作業的管理員帳戶建立 Microsoft Outlook 設定檔。
  2. 在 GWMME 中的步驟 1「Server Details」(伺服器詳細資料) 畫面上進行以下操作：
     • 在「主機名稱/IP 位址」欄位中，輸入設定檔中的 Exchange 主機名稱。
     • 在「Admin username」(管理員使用者名稱) 欄位中，輸入設定檔中的使用者名稱。

如果您是從代管伺服器遷移資料，管理員帳戶的設定檔必須採用預設設定才能連線至伺服器。如果您從「控制台」 「郵件」 「設定檔名稱」 「內容」 「電子郵件帳戶」 「設定檔名稱」 「變更電子郵件帳戶」 「其他設定」 中修改任何設定，就會導致連線失敗。

請確認您輸入的管理員名稱和密碼正確無誤。

如果問題仍未解決，請確認您輸入的 Exchange 伺服器名稱正確無誤：

1. 在用戶端電腦上依序點選「控制台」「郵件」，為您要用於遷移作業的管理員帳戶建立 Outlook 設定檔。
2. 在 GWMME 中的步驟 1「Server Details」(伺服器詳細資料) 畫面上進行以下操作：
   • 在「主機名稱/IP 位址」欄位中，輸入設定檔中的 Exchange 主機名稱。
   • 在「Admin username」(管理員使用者名稱) 欄位中，輸入設定檔中的使用者名稱。

如果 GWMME 在啟動後不久隨即當機，請確認您是在用戶端電腦而非在 Exchange 伺服器上執行 GWMME，因為在伺服器上執行公用程式可能導致當機。詳情請參閱 Microsoft 說明文件。

如果您認為 GWMME 可能是因為負載平衡問題而當機，請參閱《GWMME 管理指南》的「Prepare your Windows client machines」(準備 Windows 用戶端電腦) 一節。

在遷移期間，電腦上執行的其他程序 (例如防毒、搜尋或備份等軟體) 有時會中斷 GWMME 對資料庫檔案的存取作業。如果發生這類問題，記錄檔會顯示以下錯誤代碼：

0x80040109
Fail:While stamping the message

雖然郵件已遷移完畢，但 GWMME 並未儲存遷移成功的資訊。如果您在勾選「Only New Data」(僅限新資料) 的情況下重新執行遷移作業，GWMME 會嘗試再次遷移這些郵件。這項操作不會產生重複的郵件，但可能導致日曆活動或聯絡人重複。

如有使用者的遷移作業失敗，請確認以下事項：

• 使用者檔案中的使用者名稱或 SMTP 地址格式正確無誤。
• 使用者在全域通訊清單 (GAL) 中並未受到隱藏。
• 使用者在 Exchange 伺服器擁有帳戶。
• 使用者已登入 Google Workspace、接受《服務條款》，並完成 Google Workspace 帳戶建立作業。

下列疑難排解步驟通常可解決所有 GWMME OAuth 驗證錯誤：

• 確定您已按照「為帳戶授權 GWMME」一文的說明，為網域正確授權軟體。
• 確認 CSV 檔案列出的 Google Workspace 使用者和密碼正確無誤。即使 CSV 檔案中只有一項錯誤，也可能造成遷移失敗。詳情請參閱「為遷移作業建立 CSV 檔案」。
• 在您執行 GWMME 的電腦上，確認系統時鐘設定的時間正確無誤。如果電腦的時鐘有誤差，系統會在執行 OAuth 驗證檢查時將錯誤的本機時間戳記傳送至 Google 伺服器，進而導致遷移失敗。請將您的電腦與網際網路時間伺服器保持同步。
• 確認用於驗證 GWMME 的 Google Workspace 超級管理員帳戶有效，且您在 GWMME 設定中輸入的使用者名稱正確無誤。

GWMME 不會在 Google Workspace 中佈建使用者。請先建立 Google Workspace 使用者帳戶，再開始遷移資料。

上例顯示，由於電腦上當前日期的年份已變更為 2022 年，導致系統誤以為憑證已經過期。您可以在每行記錄的開頭找到當前日期，並發現該日期晚於憑證的「Valid from」和「Valid until」日期。出現 WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED 錯誤標記則代表系統未能檢查憑證撤銷情況。

在最後一行記錄的「Network connection destination details」後方，您也可以找到目的地 IP 位址和經過解析的主機名稱。這個 1e100.net address 即代表 Google。

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 解密作業 (這表示 Fiddler 使用的是自身的憑證)，但是因為相關憑證已從 Windows 的信任憑證清單中移除，所以 Fiddler 處於不受信任的狀態。請注意，由於 Fiddler 是 Proxy，所以是連線至 127.0.0.1 (而不是 Google)。錯誤標記包含 WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA，代表系統不信任憑證授權單位 (CA). 。另請注意，此例中的憑證不是由 Google 核發。

輸出畫面或追蹤記錄檔會顯示類似以下內容的錯誤訊息：

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

造成這個問題的原因通常是使用者帳戶不具備必要權限。如要解決這個問題，請務必在 Exchange 將「接收身分」權限授予帳戶。

如果帳戶具備「接收身分」權限，錯誤卻仍未解決，表示您的 Exchange 環境可能要求使用者帳戶須同時具備「傳送身分」權限。

部分使用者無法從 Exchange 2010 遷移資料，並且會在追蹤記錄檔中收到「Failed with 0x80004005」錯誤訊息。記錄中還包括以下內容：

• 對 Exchange 2010 隨機發出的 MAPI 呼叫。
• 在 Exchange Server 2010 用戶端存取伺服器中，遠端程序呼叫 (RPC) 用戶端存取記錄顯示「BufferTooSmall」錯誤。

這是 Exchange 2010、Outlook 2007 和 Outlook 2010 的已知問題。您可能需要更新至 Exchange 2010 SP2 RU3。詳情請參閱有關 MAPI 呼叫失敗錯誤的 Microsoft 說明文件。

如果記錄中多次出現 500、502 和 503 這些 HTTP 錯誤代碼，而且郵件無法上傳並顯示 0x8004106a 錯誤代碼，表示目標信箱可能發生問題，原因通常是負載過高。

如要解決這個問題，請避免過度使用目標信箱。您可以：

• 停用所有同步處理用戶端 (例如 IMAP、POP、行動裝置和郵件用戶端)。
• 一次只從一個來源遷移郵件。

如果發生下列問題，表示您並未正確佈建使用者：

• 系統未將日曆活動的變更和參與者共用。
• 日曆通知及更新未反映到參與者的日曆上。

即使您只要執行局部遷移作業，也請先在 Google Workspace 中佈建所有使用者，再開始遷移帳戶。請務必新增所有網域別名和暱稱。接著，如要解決這個問題，請將使用者身為主辦人或邀請對象的活動全部刪除，然後重新建立活動。

根據預設，GWMME 遷移資料的速率為每秒 25 位使用者，超出了 Contacts API 和 Calendar API 的預設每秒查詢次數 (QPS)。

如要解決這個問題，請按照下列方式執行聯絡人和日曆的遷移作業：

• 與電子郵件遷移作業分開執行。
• 將速率調降至每秒 4 至 8 位使用者。

如有部分郵件無法遷移，表示這些郵件可能超出 Gmail 規定的大小限制，或含有 Gmail 封鎖的附件類型。詳情請參閱「Gmail 封鎖的檔案類型」。

您可能也需要移除資料夾大小限制，並確保資料夾能透過 IMAP 顯示。詳情請參閱「為使用者啟用及停用 POP 和 IMAP」。

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 地址，會搜尋已在遷移伺服器上註冊且與 X.500 Exchange 機構名稱相同的 MAPI 郵件設定檔。如果找到這個設定檔，GWMME 會使用 MAPI 郵件設定檔中的通訊錄註冊來解析 X.500 地址。

如果 GWMME 在 Exchange 通訊錄中找不到這項資訊，則會嘗試將 X.500 地址轉換為 SMTP 地址。為了執行這項作業，GSMME 會評估 X.500 地址的最後一個 CN 值，並將這個值用作電子郵件地址使用者名稱。舉例來說，X.500 地址 /O=ExchangeOrg/OU=CA/CN=RECIPIENTS/CN=EX_ALIAS 會轉換為 SMTP 電子郵件地址 ex_alias@example.com。

如何使用 Exchange 通訊錄解析 X.500 地址

1. 在執行遷移作業的伺服器上建立 (非快取模式) MAPI 郵件設定檔。
2. 確認您已在要用於執行 PST 遷移作業的伺服器上設定 MAPI 郵件設定檔。
3. MAPI 郵件設定檔必須連線至原始 Exchange 伺服器，GWMME 才能使用 GAL 正確解析收件者。
4. 透過目前登入的使用者或服務帳戶設定 MAPI 郵件設定檔，避免發生驗證錯誤。

重要注意事項

測試並確認您已妥善設定遷移作業。如果問題沒有解決，即使您再次執行遷移作業，系統也不會更新已遷移到 Google 帳戶的資料。請刪除電子郵件資料，並將刪除的資料從垃圾桶中移除，然後再重新遷移。

已遷移的郵件可能會顯示「遷移」日期和時間，而非原始郵件的時間和日期。

這很有可能是因為原始郵件的日期標頭不符合 RFC 5322 規範。如果郵件的日期標頭格式不正確，Gmail 就會為該郵件套用遷移時間和日期。

這是因為您為特定使用者匯入某些活動，但這些使用者並非活動的原始發起人或參與者。

即使您收到這則警告訊息，系統仍會將該活動遷移至 Google Workspace，並在 Google 日曆中將 Google Workspace 目標使用者顯示為活動的參與者。這是必要的功能設計，因為如果使用者不是日曆活動的發起人或參與者，Google 日曆就不會對其顯示該活動的相關資訊。