If you encounter an issue with Google Workspace Migration for Microsoft Exchange (GWMME), you can use the tests, reports, and logs in the product to troubleshoot your problem. For detailed help, go to troubleshooting issues below for responses to common GWMME migration problems.
Try the Log Analyzer
This tool can identify most issues within a few moments of submission.
- Submit your trace logs (as uncompressed or ZIP files) to the Google Admin Toolbox Log Analyzer.
- For advanced log analysis, submit uncompressed files to Log Analyzer 2.
You can find GWMME trace logs on your computer at this location: C:\Users\username\AppData\Local\Google\Google Apps Migration\Tracing\ExchangeMigration.
To view an example of a GWMME trace log file, go to check the logs below.
Use GWMME to troubleshoot
Tests and reports in the GWMME product can assist you with troubleshooting your migration.
| Method | Description | More information |
|---|---|---|
| Diagnostic tests | To uncover issues with your configuration or users list, run diagnostic tests before you migrate data. The utility alerts you to errors and displays information on the output screen. | "Migrate data" chapter in the GWMME Admin Guide |
| Migration reports |
After you run a migration, check the migration report to learn if any errors occurred, why they occurred, and which users were affected. Note: The report data is stored in the Microsoft Windows user profile on the local machine. Only the Windows user who ran GWMME can view the reports. |
"Migration reports" chapter in the GWMME Admin Guide |
Troubleshooting issues
Review these descriptions and suggested responses to common migration problems.
Fix migration issues | Fix unsuccessful migrations | Interpret error messages | Google Workspace services & GWMME
Fix migration issues
Expand section | Collapse all & go to top
The administrator's Exchange profile couldn't be createdThe issue could be because:
- The Exchange server isn't running.
- A network issue is blocking a connection between the client machine and the Exchange server. To verify a connection, ping the server from the client machine.
- You used the wrong name for the Exchange server or the administrator. To verify this information:
- On the client machine, click Control Panel
Mail to create a Microsoft Outlook profile for the admin account you want to use for migration.
- In GWMME, on the Step 1 (Server Details) screen:
- In the Hostname/IP Address field, enter the Exchange host name from the profile.
- In the Admin username field, enter the username from the profile.
- On the client machine, click Control Panel
If you're migrating from a hosted server, the profile for the admin account must use the default settings to connect to the server. The connection will be unsuccessful if you modify any of the settings under Control PanelMail
Profile Name
Properties
Email Accounts
Profile Name
Change Email Account
More Settings.
Verify you entered the correct name and password for the admin.
If the issue persists, verify you entered the correct name for the Exchange server:
- On the client machine, click Control Panel
- In GWMME, on the Step 1 (Server Details) screen:
- In the Hostname/IP Address field, enter the Exchange host name from the profile.
- In the Admin username field, enter the username from the profile.
If GWMME crashes soon after starting, make sure you're running it on your client machine and not on the Exchange server. Running the utility on the server can cause it to crash. For more details, consult your Microsoft documentation.
If you think GWMME could be crashing because of load balancing issues, go to "Prepare your Windows client machines" in the GWMME Admin Guide.
Occasionally, extra processes running on your machine (for example: anti-virus, search, or backup software) disrupt GWMME's access to the database file during a migration. The following error code in your log files indicates this issue has occurred:
0x80040109
Fail:While stamping the message
Although the messages have been migrated, GWMME didn't save the information the migration was successful. If a migration is rerun with Only New Data checked, GWMME tries to migrate these messages again. It won't duplicate messages, but it might duplicate calendar events or contacts.
Fix unsuccessful migrations
Expand section | Collapse all & go to top
Migration unsuccessful for a single userIf migration is unsuccessful for a user, verify:
- The user's name or SMTP address is formatted correctly in the user file.
- The user isn't hidden in the Global Address List (GAL).
- The user has an account on the Exchange server.
- The user has signed in to Google Workspace, accepted the Terms of Service, and finalized the creation of their Google Workspace account.
The following troubleshooting steps should resolve all GWMME OAuth validation errors:
- Make sure you’ve authorized the software for your domain correctly as described in Authorize GWMME for your account.
- Verify the Google Workspace users and passwords listed in your CSV file are correct. A single mistake in the CSV file can cause the migration to be unsuccessful. For details, go to Create CSV files for your migration.
- On the computer where you're running GWMME, verify the system clock is set to the correct time. If the computer's clock is off, the wrong local timestamp is sent to Google's servers during the OAuth validation check, causing it to be unsuccessful. Sync your computer with internet time servers.
- Ensure the Google Workspace super administrator account used to authenticate GWMME is valid and the username is entered correctly in the GWMME configuration.
GWMME doesn't provision users in Google Workspace. Create the Google Workspace user accounts before you migrate data.
Interpret error messages
Expand section | Collapse all & go to top
Check the logs for network or TLS issuesIf 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://fiddler2.com
DO_NOT_TRUST
*.google.com
---Issuer----
Created by http://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.
An error message similar to this one appears on the output screen or in the trace log file:
E:Generic ExchangeMigration!SetPropertyGuid @ 641 ([email protected])> Failed with 0x80070005, last successful line = 637.
User accounts without the required permissions usually cause this issue. To resolve this issue, make sure you grant accounts the Receive As permission on Exchange.
If accounts have the Receive As permission and the error persists, your Exchange environment might require users' accounts to also have the Send As permission.
Some users cannot migrate from Exchange 2010 and they get "Failed with 0x80004005" errors in the trace log file. The logs also have:
- Random MAPI calls to Exchange 2010.
- "BufferTooSmall" errors in the remote procedure call (RPC) client access log on the Exchange Server 2010 Client Access server.
This is a known issue with Exchange 2010, Outlook 2007, and Outlook 2010. You might need to update to Exchange 2010 SP2 RU3. For more information, consult your Microsoft documentation on MAPI call failed errors.
If you have many instances of HTTP error codes 500, 502, and 503 in the logs and messages do not upload with the error code 0x8004106a, there might be an issue with the target mailbox. It's generally due to high load.
To resolve the issue, make sure the target mailbox isn't being heavily used. You can:
- Turn off any sync clients (such as, IMAP, POP, mobile devices, and mail clients).
- Migrate messages from only one source at a time.
Google Workspace services & GWMME
Expand section | Collapse all & go to top
Migrated Google Calendar events aren't updating correctlyThe following issues indicate your users haven't been provisioned correctly:
- Changes to a calendar event aren't shared with attendees.
- Calendar notifications and updates don't propagate to attendees' calendars.
Provision all your users in Google Workspace before you migrate any accounts—even if you want to only do a partial migration. Make sure to add any domain aliases and nicknames. Then, to resolve the issue, delete and recreate all events where the user is an organizer or guest.
GWMME defaults to migrating data at a rate of 25 users per second. This rate exceeds the default queries per second (QPS) for both the Contacts API and the Calendar API.
To resolve the issue, run migrations for contacts and calendars:
- Separately from email migrations.
- At a lower rate of 4—8 users per second.
If some messages don't migrate, the message might exceed the size limit imposed by Gmail. Or, it could contain attachment types blocked by Gmail. For details, go to File types blocked in Gmail.
You might also need to remove folder size limits and make sure folders show in IMAP. For details, go to Turn POP and IMAP on and off for users.
Google Workspace estimates the number of messages in your inbox after a migration. It doesn't provide an absolute count. The number of messages indicated in your Gmail inbox might be different from the number of messages in your legacy inbox.
If you think you’re missing some messages, check whether:
- The message, including attachments, is not bigger than 25 MB. You can’t migrate messages bigger than 25 MB. For details, go to Send attachments with your Gmail message.
- Gmail is not blocking an attachment to the message. Gmail prevents certain types of attachments, such as executable files. For details, go to File types blocked in Gmail.
- The message is in a folder or within a date range that’s part of the migration.
Missing messages or messages migrated with an incorrect sender or recipient can occur with Exchange or PST file migrations. The SMTP address for a message's sender or recipient might be missing and the Exchange X.500 address is used instead. This can occur if no Global Address List (GAL) profile is created or the user has been removed from the GAL.
What happens when GWMME finds an X.500 address
When GWMME finds an X.500 address, it searches for a MAPI mail profile registered on the migration server that matches the same X.500 Exchange organization name. If it finds one, GWMME resolves the X.500 address using the address book registration in the MAPI mail profile.
If GWMME doesn't find this information in the Exchange address book, it tries to convert the X.500 address to an SMTP address. To do this, it considers the last CN value of the X.500 address and uses it as the email address username. For example, the X.500 address /O=ExchangeOrg/OU=CA/CN=RECIPIENTS/CN=EX_ALIAS results in the SMTP email address [email protected].
How to use the Exchange address book to resolve the X.500 address
- Create a (non-cache mode) MAPI mail profile on the server conducting the migration.
- Make sure the MAPI mail profile is set up on the server used to perform the PST migration.
- The MAPI mail profile must be connected to the original Exchange server so GWMME can properly resolve the recipients using the GAL.
- Set up the MAPI mail profile with the user or service account currently signed in to avoid authentication errors.
Important note
Test and confirm you’ve properly set up the migration. If the issue persists, remigrating won't update the data already migrated to your Google Accounts. Delete the email data, remove it from the trash, and then remigrate.
Migrated messages might show the migration date and time, rather than the time and date of the original message.
This most likely occurs because the date header of the original message isn't compliant with RFC 5322. If a message has a date header that isn't formatted correctly, Gmail applies the migration time and date to the message.
This happens when you import events for users who are not an original organizer or initial attendee for the event.
Regardless of the warning message, the event successfully migrates into Google Workspace and the Google Workspace target user is shown as an attendee of the event on the Google Calendar. This is necessary as Calendar doesn't support listing calendar events for a user where they aren't an organizer or attendee.
Related topics
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.
