When you run a migration with Google Workspace Migration for Microsoft Outlook (GWMMO), a trace file is created that logs each step of the migration. If you encounter any errors during the import, the trace file can identify where in the process the error occurred. This information is typically most valuable to Google Support. For example, if a log message indicates an error with a particular migration module, then Google engineers can address the issue.
Log messages can also identify problems that need to be resolved in your own environment, such as timeouts or network errors. If you receive a migration error, first check the trace file for problems in your own environment.
Locate your trace log files
Trace files are located on your computer in the following locations:
- Microsoft Windows 7 and up—C:\Users\your-user-name\AppData\Local\Google\Google Apps Migration\Tracing\ClientMigration.
- Earlier versions of Windows—C:\Documents and Settings\your-user-name\Local Settings\Application Data\Google\Google Apps Migration\Tracing\ClientMigration.
A trace file is created and named according to the date and time its corresponding migration completed, along with a process ID. For example, a file with the name...
Trace-2020-05-03-11-33-17-p732.log
...was created on May 3, 2020, at 11:33:17 A.M., with a process ID of 732.
Interpret a trace log file
Each trace file is updated as the migration progresses. The file begins with entries that identify the location and version of the ClientMigration.exe file, the migration product version, your computer's operating system, and the process information for this particular migration:
Configuration: Exe name: C:\Program Files\Google\Google Apps Migration\ClientMigration.exe
Exe version: 1.0.0.1
Product version: 1.0.0.1
OS Version: 5.1.2600
OS Service Pack: 3.0
OS Suite/Product: 256/1
Process Id: 732
Process architecture: x64
Subsequent entries provide specific information about each step of the migration process. For example, this entry...
2020-05-03T11:45:22.668-07:00 de4 A:Migration ClientMigration!ConfigOptionsDialog::TraceMigrationConfig @ 269 ()> Creating a new migration GUID :
... reports the following information:
- 2020-05-03T11:45:22.668-07:00: The date and time the entry was written
- de4: The thread ID
- A: The logging level (A:All, I:Information, E:Error, F:Fatal, W:Warning, V:Verbose)
All, Error, Fatal, and Warning are hard coded.
- Migration: Module name (for example, Migration, Generic, Sync, Calendar)
- ConfigOptionsDialog: Class name
- TraceMigrationConfig: Method name
- @ 269: Line number
- > following text: Log message (for example, Creating a new migration GUID)
Troubleshoot common issues
Check the logsIf you have network errors (for example, a network timeout, connection refused, etc.) or SSL/TLS issues (for example, a secure connection problem), the logs show the IP address the tool tried to connect to. If there's a secure connection issue, the logs show the reason (for example, certificate name mismatch, certificate expired, CRL check was unsuccessful, etc.) and the certificate details (for example, a Google certificate or a HTTPS-inspecting proxy). This should significantly reduce the need to get network captures for troubleshooting, and applies to both the main logs (Trace-*.log) and the authorization logs (in the "Identity" folder).
Authorization log example
[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)
In this case, the year in the machine's current date was changed to 2022, making the certificate seem out of date. You can view the current date at the start of each log line, and the "Valid from" and "Valid until" dates of the certificate don't match the current date. The error flag WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED indicates the certificate revocation check was unsuccessful.
You can also view the destination IP address and the resolved hostname after "Network connection destination details" on the last log line. It's a 1e100.net address, meaning it's Google.
Trace log example
Note: This log example is from GWMMO. Similar trace log entries will also appear in GWMME, Password Sync, or GWSMO when these products experience network/TLS issues.
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)
In this case, Fiddler was installed and set to do HTTPS decryption (meaning it uses its own certificate), but its certificate was removed from the Windows trusted certificate list, so it's untrusted. Note that because Fiddler is a proxy, it was connecting to 127.0.0.1 and not to Google. The error flags include WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA, which means the system doesn't trust the Certificate Authority (CA). Also notice Google did not issue this certificate.
Google, Google Workspace, and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.
