Troubleshoot GSMME

G Suite Migration for Microsoft Exchange

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

Use GSMME to troubleshoot

Tests, reports, and logs in the GSMME 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 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 Microsoft Windows® user profile on the local machine. Only the Windows user who ran GSMME can view the reports.

"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 Google Support.

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

To view an example of a GSMMO trace log, which is similar to a GSMME log file, go to this page.

"Troubleshoot" chapter in the GSMME Admin Guide

Troubleshooting issues

See these descriptions and suggested responses to common migration problems.

Open all   |   Close all

Fix migration issues

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 GSMME:
      • 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 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 GSMME:
    • 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 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. Consult your Microsoft's documentation to learn why this happens.

If you think GSMME could be crashing because of load balancing issues, go to "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. The following error code in your log files indicate this 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:

  • 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 you have authorized the software for your domain correctly as described in Authorize GSMME for your account.
  • Verify 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, go to Create a control CSV file for user accounts.
  • On the computer where you're running GSMME, verify 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 to this one appears on the output screen or in the trace log file:

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, 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.

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 log file. 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, consult Microsoft's support article KB2674185 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 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 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.
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. For details, see File types blocked in Gmail.

You might also need to remove folder size limits and make sure folders show in IMAP. For details, see Turn POP and IMAP on and off for users.

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 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.
  • An attachment to the message is not blocked by Gmail. Gmail blocks 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.
Messages missing, or migrated with an incorrect 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 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 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 conducting the migration.
  2. Make sure the MAPI mail profile is configured on the server 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 MAPI mail profile with the user or service account currently signed in to avoid authentication errors.

Important note

Test and confirm you have properly configured the migration. If the issue persists, remigrating 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?