Troubleshoot GSMME

If you encounter an issue with G Suite Migration for Microsoft® Exchange (GSMME), you can use the tests and reports in the tool to troubleshoot your problem. For detailed help, see the troubleshooting issues about common GSMME migration problems. 

Use the GSMME tool to troubleshoot

Tests and reports in the GSMME tool can assist you with troubleshooting your migration.  

Tool 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.  "Migrating data" chapter in the GSMME Admin Guide
Migration reports

After you run a migration, check the migration report to see if any errors occurred, why they occurred, and which users were affected. 

Note: The report data is stored in the Windows® user profile on the local machine. Only the Windows user who ran GSMME can view the reports. 

"Reviewing migration reports" chapter in the GSMME Admin Guide
Migration logs

You can examine log files for more information about migration errors or provide logs to support. 

The Google Log Analyzer tool can scan your trace log files and quickly identify many types of migration issues. Go to the analyzer and upload your log files.

"Troubleshooting" chapter in the GSMME Admin Guide

Troubleshooting issues

See these descriptions and suggested responses to common migration problems.

Open all   |   Close all

Address migration issues

Migration fails: The administrator's Exchange profile couldn't be created

The 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. Ping the server from the client machine to verify a connection.
  • You used the wrong name for the Exchange server or the administrator. To verify this information:
    1. On the client machine, click Control Panel and then Mail to create a Microsoft Outlook® profile for the admin account you want to use for migration.
    2. In the GSMME tool:
      • In step 1, enter the Exchange host name from the profile in the Microsoft Exchange Server field. 
      • In step 2, enter the username from the profile in the Microsoft Exchange Administrator User name field. 

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 fails if you modify any of the settings under Control Panel and then Mail and then Profile Name and then Properties and then Email Accounts and then Profile Name and then Change Email Account and then More Settings.

Exchange Server doesn't recognize the admin name I'm using for the migration

Verify that you entered the correct name and password for the admin.

If the issue persists, verify you entered the correct name for the Exchange Server:

  1. On the client machine, click Control Panel and then Mail to create an Outlook profile for the admin account you want to use for migration.
  2. In the GSMME tool:
    • In step 1, enter the Exchange host name from the profile in the Microsoft Exchange Server field. 
    • In step 2, enter the username from the profile in the Microsoft Exchange Administrator User name field. 
GSMME crashes soon after starting

If GSMME crashes soon after starting, make sure that you're running it on your client machine and not on the Exchange server. Running the utility on the server itself can cause it to crash. Check Microsoft's documentation to learn about why this happens.

If you think GSMME could be crashing because of load balancing issues, see "Prepare your Windows client machines" in the GSMME Admin Guide.

Issues caused by anti-virus software or a plugin

Occasionally, additional processes running on your machine (for example: anti-virus, desktop search, or backup software) disrupt GSMME's access to the database file during a migration. This error code in your log files indicate that the issue has occurred:

0x80040109
Fail:While stamping the message

Although the messages have been migrated, GSMME didn't save the information that the migration was successful. If a migration is rerun with Only New Data checked, GSMME tries to migrate these messages again. This won't duplicate messages, but it might duplicate calendar events or contacts.

Fix migration failures

Migration fails for a single user

If migration fails for a user, verify that:

  • The user's name or SMTP address is formatted correctly in the user file.
  • The user isn't hidden in the Global Address List.
  • The user has an account on the Exchange server.
  • The user has signed in to G Suite, accepted the Terms of Service, and finalized the creation of their G Suite account.
Migration fails due to OAuth error

The following troubleshooting steps should resolve all GSMME OAuth validation errors:

  • Make sure that you have authorized the software for your domain correctly as described in Authorize GSMME for your domain.
  • Verify that the G Suite users and passwords listed in your CSV file are correct. A single mistake in the CSV file can cause the migration to fail. For details, see Create a control CSV file for user accounts
  • On the computer where you're running GSMME, verify that the system clock is set to the correct time. If the computer's clock is off, the wrong local time stamp is sent to Google's servers during the OAuth validation check, causing a failure. Sync your computer with internet time servers.
  • Ensure the G Suite super administrator account used to authenticate GSMME is valid and the username is entered correctly in the GSMME configuration.
Migration fails due to a nonexistent G Suite user

GSMME doesn't provision users in G Suite. You need to create the G Suite user accounts before you migrate data.

Interpret error messages

Migration fails with error 0x80070005

An error message similar this to this one appears on the output screen or in the trace log:

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

This issue is usually caused by user accounts that don't have the required permissions. To resolve this issue, ensure that 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.

GSMME 0x80004005 errors when migrating from Exchange 2010

Some users fail to migrate from Exchange 2010 and you see "Failed with 0x80004005" errors in the logs. You also see:

  • 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 and Outlook 2007 and 2010. You might need to upgrade to Exchange 2010 SP2 RU3. For more information, see Microsoft's support article KB2674185, blog post, and wiki page.

Messages fail to upload with 0x8004106a errors

If you see many instances of HTTP error codes 500, 502, and 503 in the logs and messages fail to upload with the error code 0x8004106a, there might be an issue with the target mailbox. This is usually due to high load.

To resolve the issue, make sure that the target mailbox isn't being heavily used. You can: 

  • Disable any sync clients (such as, IMAP, POP, mobile devices, and mail clients).
  • Migrate messages from only one source at a time.

Use G Suite services with GSSME

Migrated Google Calendar events aren't updating correctly

The following issues indicate that 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 G Suite before you migrate any accounts—even if you want to perform only 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.

I encounter 403 errors and failures when migrating contacts and calendars

GSMME defaults to migrating data at a rate of 25 users per second. This rate exceeds the default QPS for both the Contacts API and 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
Migration fails for only some messages

If some messages fail to migrate, the message might exceed the size limit imposed by Gmail. Or, it could contain attachment types that are blocked by Gmail.

You might also need to remove folder size limits and make sure that folders show in IMAP. See Turn POP and IMAP on and off for users for instructions.

After a migration, the number of Gmail messages doesn't match my legacy inbox

G Suite estimates the number of messages in your inbox after a migration. It doesn't provide an absolute count. The number of messages indicated your Gmail inbox might then be different from the number of messages in your legacy inbox.

Messages missing or not migrated with the right sender or recipient

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 deleted from the GAL.

What happens when GSMME finds an X.500 address 

When GSMME finds an X.500 address, it looks for a MAPI mail profile registered on the migration server that matches the same X.500 Exchange organization name. If it finds one, GSMME resolves the X.500 address using the address book registration in the MAPI mail profile.

If GSMME 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 that as the email address username. For example, the X.500 address / O=ExchangeOrg/OU=CA/CN=RECIPIENTS/CN=EX_ALIAS results in the SMTP address ex_alias@domain.com.

How to use the Exchange address book to resolve the X.500 address

  1. Create a (non-cache mode) MAPI mail profile on the server that is conducting the migration.
  2. Ensure the profile is configured on the server that is used to perform the PST migration.
  3. The MAPI mail profile must be connected to the original Exchange server so GSMME can properly resolve the recipients using the GAL. 
  4. Configure the mail profile with the user or service account that is currently signed in to avoid authentication errors.

Important note

Test and confirm you have properly configured the migration. If the issue persists, a re-migration won't update the data already migrated to your Google Accounts. You must delete the email data, remove it from the trash, and then remigrate.

In Gmail, messages appear with the wrong date

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.

Related topics

Was this helpful?
How can we improve it?