Troubleshoot GSMME

Use the tools below to help you troubleshoot G Suite Migration for Microsoft® Exchange (GSMME).

Using the utility to problem solve

Pre-migration diagnostic tests

To determine if there are issues with your configuration or users list, you can run diagnostic tests before you migrate data. The utility alerts you to errors and displays information on the Output screen. For details, see "Migrating Data" chapter in the GSMME Admin Guide (PDF).

Migration reports

After you run a migration, you can check the migration report to determine if any errors occurred, why they occurred, and which users were affected by them. For details, see the "Viewing Migration Reports" chapter in the GSMME Admin Guide (PDF).

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. If you log in as a different Windows user, you won't see the same report.

Migration logs

You can examine log files for more information about migration errors or provide logs to Google Cloud Support. For details, see the "Troubleshooting Issues" chapter in the GSMME Admin Guide (PDF).

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.

Common issues and solutions

Open all   |   Close all

My migration fails immediately because the administrator's Microsoft Exchange profile could not be created

The Microsoft Exchange Server may not be running.

You may have a network issue that is blocking a connection between the client machine and the Microsoft Exchange Server. Ping the server from the client machine to verify a connection.

You may have used the wrong name for the  Exchange server or for the administrator. Use the following method to verify the Exchange server name and administrator user name:

On the client machine, use Control Panel > Mail to create a Microsoft Outlook® profile for the administrator account you want to use for migration. When that profile has been created, use the Microsoft Exchange host name from that profile for the Microsoft Exchange Server parameter in Step 1, and use the user name from that profile for the Microsoft Exchange Administrator User name parameter in Step 2.

If you are migrating from a hosted server, the profile for the administrator account must use the default settings to connect to the server. If you modify any of the settings under Control Panel > Mail > Profile Name > Properties > Email Accounts > Profile Name > Change Email Account > More Settings, the connection to the server will fail.

The Microsoft Exchange Server doesn't recognize the administrator name I am using for the migration

Verify that you have entered the correct name and password for the administrator.

You may have used the wrong name for the Exchange Server or for the administrator. Use the following method to verify the server name and administrator user name:

On the client machine, use Control Panel > Mail to create an Outlook profile for the administrator account you want to use for migration. When that profile has been created, use the Exchange host name from that profile for the Microsoft Exchange Server parameter in Step 1, and use the user name from that profile for the Microsoft Exchange Administrator User name parameter in Step 2.

GSMME 0x80004005 errors when migrating from Exchange 2010


Some users fail to migrate from Exchange 2010 with a high percentage of migration errors. In the logs, you see GSMME 80004005 errors ("Failed with 0x80004005") paired with random MAPI calls to Exchange 2010.

You see will see "BufferTooSmall" errors in the remote procedure call (RPC) Client Access log on the Exchange Server 2010 Client Access server. Example:

2012-10-15T00:04:27.367Z,165145,991,"/o=domain, Inc./ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=exchangemigrationaccount",,ExchangeMigration.exe,12.0.6606.1000,Classic,,,ncacn_ip_tcp,,0,,,RopHandler: ReadRecipients: Unable to add even one recipient to the RecipientCollector.. Error code = BufferTooSmall


This is a known issue with Microsoft Exchange 2010 and Outlook 2007/2010. You will need to upgrade to Exchange 2010 SP2 RU3.

For more information, see Microsoft's support article KB2674185, blog post, and wiki page.
GSMME crashes soon after starting

If the GSMME app quickly crashes 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. Read more about why this happens on Microsoft's support site.

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

Migration fails for a single user

Check the following:

  • The user's name or SMTP address is formatted correctly in the user file.
  • The user is not hidden the Global Address List.
  • Verify that the user has an account on the Exchange server.
  • Verify that the user has logged in to G Suite at least once, accepted the terms of service, and finalized creation of the 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 user(s) and passwords listed in your CSV file are correct. A single mistake in the CSV file will cause the migration to fail.
  • Verify that the system clock on the computer you're running GSMME from is set to the correct time. If the computer's clock is off by just a few minutes, the wrong local time stamp will be sent to Google's servers during the OAuth validation check, causing a failure. We recommend syncing your computer with internet time servers.
  • Ensure the G Suite domain super administrator used to authenticate GSMME is a valid super administrator and their username is spelled correctly in the GSMME configuration.
Issues caused by anti-virus software or a plug-in

Sometimes, additional processes running on your machine (for example: anti-virus, desktop search, or backup software) will access the migration tool's database file during the migration. This interrupts the tool's ability to save the state of that message. If you think you're affected by this issue, check for the follow error codes in your log files:

Fail:While stamping the message

This problem does not indicate that messages failed to migrate, only that the tool couldn't save that they were migrated. The only negative consequence is that if the migration is re-run at a later time with Only New Data checked, the tool will attempt to migrate these messages again since it doesn't have a record of them being migrated previously. This won't cause message duplication, but it may lead to duplicate calendar events or contacts.

Migration fails due to a non-existent G Suite user

GSMME does not provision users in G Suite. You need to create the G Suite user accounts before you migrate data.

Migration fails for only some messages

Those messages (including attachments) may exceed the size limit imposed by Gmail, or the messages may contain attachment types that are blocked by Gmail.

Or, you may need to remove folder size limits and expose additional folders to the migration tools. See IMAP and POP access for instructions.

Migration fails with error 0x80070005

An error message similar to the following appears on the Output screen or in the Trace log:

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

The most common cause is that user accounts don't have the required permissions for the utility to read users' mailboxes. To resolve this issue, ensure that you grant accounts the Receive As permission on Microsoft Exchange. If accounts have the Receive As permission and the error persists, your Exchange environment may require users' accounts to also have the Send As permission.

Migrated Calendar events are not being updated correctly

Ensure you provision all your users in G Suite before you migrate any accounts—even if you want to perform only a partial migration. This includes ensuring that all domain aliases and nicknames are added for each user. Otherwise, you may see the following issues:

  • Changes to the event are not shared with attendees
  • Calendar notifications and updates will not propagate to the attendees' calendars

To resolve this issue, provision the user and then delete and recreate all events for which the user is the organizer or a guest.

After a migration, the number of emails in my Gmail inbox doesn't exactly match what was in my legacy inbox

G Suite estimates the number of emails in your inbox after a migration. It does not provide an absolute count. The number of emails in your Gmail inbox may therefore be different to the number of emails in your legacy inbox.

I encounter 403 errors and failures when migrating contacts and calendars

As configured, GSMME defaults to migrating data at a rate of 25 users per second, however, this rate exceeds the default QPS for both the Contacts API and Calendar API. The solution is to run contacts/calendar migrations separate to email migrations and at a lower rate of 4-8 users per second instead of 25.

Messages fail to upload with 0x8004106a errors

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

Make sure that the target mailbox isn't being heavily used:

  • Disable any sync clients (such as, IMAP, POP, mobile devices, and mail clients).
  • Don't migrate messages from other sources at the same time.
Messages are missing or aren't migrated with the correct sender/recipient

This 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 attempts 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 of

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

  • Create a (non-cache mode) MAPI mail profile on the server that will be conducting the migration.
  • Ensure the profile is configured on the server that will be used to perform the PST migration.
  • The MAPI mail profile needs to be connected to the original Exchange server so GSMME can properly resolve the recipients using the GAL. 
  • Configure the mail profile with the user or service account that is currently logged 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 re-migrate it.

Next steps

Check the following articles for more troubleshooting information:

Was this article helpful?
How can we improve it?