Fehlerbehebung in GWMME

Wenn ein Problem mit Google Workspace Migration for Microsoft Exchange (GWMME) auftritt, können Sie die Tests, Berichte und Protokolle im Produkt zur Fehlerbehebung verwenden. Weitere Informationen und Unterstützung bei Problemen mit GWMME finden Sie unten im Abschnitt Fehlerbehebung.

Log-Analysetool verwenden

Mit diesem Tool lassen sich die meisten Probleme direkt nach dem Eingang ermitteln. 

• Senden Sie die Trace-Logs (als unkomprimierte ZIP-Dateien) an das Log-Analysetool in der Google Admin Toolbox.
• Für erweiterte Protokollanalysen können Sie unkomprimierte Dateien an das Log-Analysetool 2 senden. 

Die Trace-Logs von GWMME finden Sie auf Ihrem Computer unter dem Pfad: C:\Users\Nutzername\AppData\Local\Google\Google Apps Migration\Tracing\ExchangeMigration

Ein Beispiel für eine Trace-Log-Datei von GWMME finden Sie unter Protokolle überprüfen weiter unten.

Fehlerbehebung mit GWMME

Mit Tests und Berichten in GWMME lassen sich Fehler bei der Migration leichter beheben.

Methode	Beschreibung	Weitere Informationen
Diagnosetests	Um Probleme mit der Konfiguration oder Nutzerliste zu erkennen, können Sie noch vor dem Migrieren von Daten Diagnosetests durchführen. Sie werden vom Dienstprogramm auf Fehler hingewiesen und sehen im Ausgabefenster die entsprechenden Informationen.	Kapitel zur Datenmigration im GWMME-Administratorhandbuch (nur auf Englisch verfügbar)
Migrationsberichte	Nachdem Sie eine Migration durchgeführt haben, können Sie mithilfe des entsprechenden Migrationsberichts ermitteln, ob und warum Fehler aufgetreten sind und welche Nutzer davon betroffen waren. Hinweis: Die Berichtsdaten werden im Microsoft Windows-Nutzerprofil auf dem lokalen Computer gespeichert. Nur der Windows-Nutzer, der GWMME ausgeführt hat, kann auch die Berichte aufrufen.	Kapitel zu Migrationsberichten im GWMME-Administratorhandbuch (nur auf Englisch verfügbar)

Fehlerbehebung

Hier finden Sie Beschreibungen und Lösungsvorschläge für häufig auftretende Migrationsprobleme.

Probleme mit der Migration beheben  |  Probleme bei fehlgeschlagenen Migrationen beheben  |  Fehlermeldungen interpretieren  |  Google Workspace-Dienste und GWMME

Probleme mit der Migration beheben

Abschnitt öffnen  |  Alle minimieren und nach oben

Das Exchange-Profil des Administrators konnte nicht erstellt werden.

Mögliche Ursachen:

• Der Exchange-Server wird nicht ausgeführt.
• Es besteht ein Netzwerkproblem, sodass keine Verbindung zwischen dem Clientcomputer und dem Exchange-Server hergestellt werden kann. Pingen Sie den Server vom Clientcomputer aus an, um die Verbindung zu testen.
• Sie haben einen falschen Namen für den Exchange-Server oder den Administrator eingegeben. So prüfen Sie diese Daten:
  1. Klicken Sie auf dem Clientcomputer auf Systemsteuerung  E-Mail, um ein Microsoft Outlook-Profil für das Administratorkonto zu erstellen, das Sie für die Migration verwenden möchten.
  2. Geben Sie im GWMME-Bildschirm „Schritt 1 (Serverdetails)“ Folgendes ein:
     • Im Feld Hostname/IP-Adresse den Exchange-Hostnamen aus dem Profil
     • Im Feld Admin-Nutzername den Nutzernamen aus dem Profil

Wenn Sie von einem gehosteten Server migrieren, müssen Sie für das Profil des Administratorkontos die Standardeinstellungen verwenden, um eine Serververbindung herzustellen. Ändern Sie eine der Einstellungen unter SystemsteuerungE-MailProfilnameEigenschaftenE-Mail-KontenProfilnameE-Mail-Konto ändernWeitere Einstellungen, treten bei der Verbindung Fehler auf.

Der Exchange-Server erkennt den Administratornamen nicht, den ich für die Migration verwende.

Achten Sie darauf, dass Sie den korrekten Namen und das richtige Passwort für den Administrator eingegeben haben.

Wenn das Problem weiterhin besteht, prüfen Sie auch den Namen des Exchange-Servers, den Sie eingegeben haben:

1. Klicken Sie auf dem Clientcomputer auf Systemsteuerung  E-Mail, um ein Outlook-Profil für das Administratorkonto zu erstellen, das Sie für die Migration verwenden möchten.
2. Geben Sie im GWMME-Bildschirm „Schritt 1 (Serverdetails)“ Folgendes ein:
   • Im Feld Hostname/IP-Adresse den Exchange-Hostnamen aus dem Profil
   • Im Feld Admin-Nutzername den Nutzernamen aus dem Profil

GWMME stürzt kurz nach dem Start ab

Wenn die GWMME App nach dem Start schnell abstürzt, stellen Sie sicher, dass sie auf Ihrem Client-Computer und nicht auf dem Exchange-Server ausgeführt wird. Wenn Sie das Dienstprogramm auf dem Server ausführen, kann es abstürzen. Weitere Informationen finden Sie in der Microsoft-Dokumentation.

Wenn Sie der Ansicht sind, dass GWMME aufgrund von Problemen beim Lastausgleich abstürzt, lesen Sie das Kapitel zum Vorbereiten von Windows-Clientcomputern im GWMME-Administratorhandbuch (nur auf Englisch verfügbar).

Probleme aufgrund von Antivirensoftware oder Plug-ins

Manchmal wird der Zugriff von GWMME auf die Datenbankdatei während der Migration durch Prozesse unterbrochen, die im Hintergrund auf dem Computer ausgeführt werden, z. B. Antiviren-, Such- oder Sicherungssoftware. Der folgende Fehlercode in Ihren Protokolldateien weist auf dieses Problem hin:

0x80040109
Fail:While stamping the message

Obwohl die Nachrichten migriert wurden, wurde die Information, dass die Migration abgeschlossen ist, nicht in GWMME gespeichert. Wenn Sie eine Migration wiederholen und die Option Nur neue Daten aktivieren, wird über GWMME versucht, diese Nachrichten noch einmal zu migrieren. Dadurch werden zwar keine Nachrichten dupliziert, aber möglicherweise Kalendertermine oder Kontakte.

Probleme bei fehlgeschlagenen Migrationen beheben

Abschnitt öffnen  |  Alle minimieren und nach oben

Fehler bei der Migration eines einzelnen Nutzers

Wenn die Migration für einen Nutzer nicht ausgeführt werden kann, prüfen Sie Folgendes:

• Der Name oder die SMTP-Adresse des Nutzers in der Nutzerdatei ist richtig formatiert.
• Der Nutzer ist in der globalen Adressliste (GAL) nicht ausgeblendet.
• Der Nutzer hat ein Konto auf dem Exchange-Server.
• Der Nutzer hat sich in Google Workspace angemeldet, die Nutzungsbedingungen akzeptiert und ein Google Workspace-Konto erstellt.

Fehler bei der Migration wegen eines OAuth-Fehlers

Anhand der folgenden Schritte sollten Sie alle Fehler bei der OAuth-Bestätigung von GWMME beheben können:

• Sie müssen die Software für Ihre Domain autorisiert haben. Die Anleitung dazu finden Sie im Hilfeartikel GWMME für mein Konto autorisieren.
• Prüfen Sie, ob die in der CSV-Datei aufgeführten Google Workspace-Nutzer und ‑Kennwörter korrekt sind. Selbst wenn die CSV-Datei nur einen einzigen Fehler enthält, kann die Migration nicht ausgeführt werden. Weitere Informationen finden Sie unter CSV-Dateien für die Migration erstellen.
• Auf dem Computer, auf dem Sie GWMME ausführen, muss die Systemuhr auf die richtige Uhrzeit eingestellt sein. Wenn die Uhr des Computers ausgeschaltet ist, wird während der OAuth-Bestätigung der falsche lokale Zeitstempel an die Google-Server gesendet, sodass ein Fehler auftritt. Synchronisieren Sie Ihren Computer am besten mit Zeitservern im Internet.
• Das Super Admin-Konto für Google Workspace, das zur Authentifizierung von GWMME verwendet wird, muss gültig sein und der Nutzername muss bei der Konfiguration von GWMME korrekt angegeben werden.

Fehler bei der Migration wegen eines nicht vorhandenen Google Workspace-Nutzers

Mit GWMME können keine Konten für Nutzer in Google Workspace eingerichtet werden. Erstellen Sie die Google Workspace-Nutzerkonten, bevor Sie Daten migrieren.

Fehlermeldungen interpretieren

Abschnitt öffnen  |  Alle minimieren und nach oben

Protokolle auf Netzwerk- oder TLS-Probleme prüfen

Bei Netzwerkfehlern (z. B. Zeitüberschreitungen, abgelehnte Verbindungen usw.) oder SSL/TLS-Problemen (z. B. Schwierigkeiten mit sicheren Verbindungen) wird in den Protokollen die IP-Adresse angezeigt, mit der das Tool eine Verbindung herstellen wollte. Wenn es Probleme mit einer sicheren Verbindung gibt, wird in den Protokollen der Grund (z. B. nicht übereinstimmende Zertifikatsnamen, abgelaufenes Zertifikat, fehlgeschlagene Prüfung der Zertifikatssperrliste usw.) und die Zertifikatsdetails angezeigt (z. B. ein Google-Zertifikat oder ein HTTPS-untersuchender Proxy). Dadurch sollte die Netzwerkerfassung zur Fehlerbehebung erheblich reduziert werden und es gilt sowohl für die Hauptprotokolle (Trace-*.log) als auch für die Autorisierungsprotokolle (im Ordner "Identity").

Beispiel für ein Autorisierungsprotokoll

[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 diesem Fall wurde das Jahr im aktuellen Datum des Computers in 2022 geändert, sodass das Zertifikat nicht mehr aktuell zu sein scheint. Sie sehen das aktuelle Datum am Anfang jeder Protokollzeile. Die Datumsangaben "Valid from" und "Valid until" des Zertifikats stimmen nicht mit dem aktuellen Datum überein. Die Fehlerkennzeichnung WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED zeigt an, dass die Zertifikatswiderrufsprüfung fehlgeschlagen ist.

Außerdem können Sie die Ziel-IP-Adresse und den aufgelösten Hostnamen nach "Network connection destination details" in der letzten Protokollzeile sehen. Es ist eine 1e100.net address, also Google.

Beispiel für ein Trace-Log

Hinweis: Dieses Protokollbeispiel stammt von GWMMO. Ähnliche Trace-Log-Einträge werden auch in GSMME, Password Sync oder GWSMO angezeigt, wenn bei diesen Produkten Netzwerk- oder TLS-Probleme auftreten.

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 diesem Fall wurde Fiddler installiert und für die HTTPS-Entschlüsselung eingerichtet, d. h., es wird ein eigenes Zertifikat verwendet. Das Zertifikat wurde jedoch aus der Liste vertrauenswürdiger Windows-Zertifikate entfernt und ist daher nicht vertrauenswürdig. Da Fiddler ein Proxy ist, wurde eine Verbindung zu 127.0.0.1 und nicht zu Google hergestellt. Die Fehlerkennzeichnungen beinhalten WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA. Das bedeutet, dass das System der Zertifizierungsstelle (CA).  nicht vertraut. Außerdem hat Google dieses Zertifikat nicht ausgestellt.

Der hier angezeigte Beispieltext ist für Angreifer leicht zu fälschen. Er sollte daher niemals zur Authentifizierung verwendet werden. Verwenden Sie stattdessen die Signatur einer Zertifizierungsstelle. Andererseits ist er nützlich, um Einrichtungsprobleme bei Firewalls oder Proxys zu erkennen, die SSL-Inspektionen/Man-in-the-Middle-Angriffe (MITM) durchführen.

Migrationsfehler 0x80070005

Auf dem Ausgabebildschirm oder in der Trace-Log-Datei wird die folgende oder eine ähnliche Fehlermeldung angezeigt:

E:Generic ExchangeMigration!SetPropertyGuid @ 641 ([e-mail])> Failed with 0x80070005, last successful line = 637.

Dieses Problem wird in der Regel durch Nutzerkonten ohne die erforderlichen Berechtigungen verursacht. Sie können den Fehler beheben, indem Sie für die Konten die Berechtigung Empfangen als für Exchange festlegen.

Falls die Konten bereits die Berechtigung Empfangen als haben und der Fehler weiterhin auftritt, müssen Sie den Nutzerkonten in Ihrer Exchange-Umgebung möglicherweise auch die Berechtigung Senden als zuweisen.

GWMME-Fehler 0x80004005 bei der Migration von Exchange 2010

Einige Nutzer können die Migration von Exchange 2010 nicht ausführen und sie erhalten in der Trace-Log-Datei die Fehlermeldung „Failed with 0x80004005“. Außerdem enthalten die Protokolle Folgendes:

• Zufällige MAPI-Aufrufe an Exchange 2010
• „BufferTooSmall“-Fehler im Clientzugriffsprotokoll zum Remote-Prozeduraufruf (RPC) auf dem Exchange-Server 2010-Clientzugriffsserver.

Das ist ein bekanntes Problem bei Exchange 2010, Outlook 2007 und Outlook 2010. Führen Sie ein Update auf Exchange 2010 SP2 RU3 aus. Weitere Informationen finden Sie in der Microsoft-Dokumentation zu Fehlern beim MAPI-Aufruf. 

Nachrichten werden nicht hochgeladen und es werden 0x8004106a-Fehler erzeugt

Wenn in den Protokollen viele HTTP-Fehlercodes (500, 502 und 503) vorhanden sind und die Nachrichten nicht hochgeladen werden und der Fehlercode „0x8004106a“ angezeigt wird, liegt möglicherweise ein Problem mit dem Zielpostfach vor, normalerweise eine hohe Auslastung.

Sie haben folgende Möglichkeiten, dieses Problem zu beheben:

• Deaktivieren Sie alle Sync-Clients wie IMAP, POP, Mobilgeräte und E-Mail-Clients.
• Migrieren Sie Nachrichten jeweils nur aus einer Quelle.

Google Workspace-Dienste und GWMME

Abschnitt öffnen  |  Alle minimieren und nach oben

Migrierte Google Kalender-Termine werden nicht korrekt aktualisiert.

Die folgenden Probleme weisen darauf hin, dass Nutzer nicht korrekt eingerichtet wurden:

• Änderungen an einem Kalendertermin werden nicht mit den Gästen geteilt.
• Kalenderbenachrichtigungen und ‑Updates werden nicht in die Kalender der Gäste übernommen.

Stellen Sie alle Nutzer in Google Workspace bereit, bevor Sie Konten migrieren, selbst wenn Sie nur eine teilweise Migration durchführen möchten. Auch Domain-Aliasse und Alternativnamen müssen hinzugefügt werden. Um den Fehler zu beheben, löschen Sie alle Termine, bei denen der Nutzer der Organisator oder ein Gast ist, und erstellen Sie sie anschließend neu.

Fehler „403“ und weitere Fehler beim Migrieren von Kontakten und Kalendern

Standardmäßig migriert GWMME Daten mit einer Geschwindigkeit von 25 Nutzern pro Sekunde. Das ist schneller als die Standardgeschwindigkeit (Abfragen pro Sekunde) für die Contacts API und die Calendar API.

Gehen Sie daher für Kontakte und Kalender so vor:

• Migrieren Sie sie getrennt von E-Mails.
• Verwenden Sie eine niedrigere Geschwindigkeit von 4–8 Nutzern pro Sekunde.

Fehler nur bei einigen Nachrichten

Wenn einige Nachrichten nicht migriert werden, überschreiten sie möglicherweise die Größenbeschränkung in Gmail. Es kann auch sein, dass sie Anhänge enthalten, die von Gmail blockiert wurden. Weitere Informationen finden Sie im Hilfeartikel In Gmail blockierte Dateitypen.

Möglicherweise müssen Sie auch die Größenbeschränkungen für Ordner entfernen und sicherstellen, dass Ordner in IMAP angezeigt werden. Weitere Informationen finden Sie unter IMAP und POP für Nutzer aktivieren und deaktivieren.

Die Anzahl der Gmail-Nachrichten stimmt nicht mit der Anzahl der E-Mails im Quellkonto überein

In Google Workspace wird nach einer Migration die Anzahl der E-Mails in Ihrem Posteingang geschätzt. Es wird keine absolute Anzahl angegeben. Daher kann sie sich von der Anzahl der E-Mails in Ihrem alten Posteingang unterscheiden.

Wenn Nachrichten fehlen, kann das folgende Ursachen haben:

• Die Nachricht ist einschließlich Anhängen größer als 25 MB. Solche Nachrichten können nicht migriert werden. Weitere Informationen finden Sie im Hilfeartikel Dateianhänge mit Gmail-Nachrichten versenden.
• Gmail blockiert keinen Anhang der Nachricht. Gmail blockiert bestimmte Arten von Anhängen, z. B. ausführbare Dateien. Weitere Informationen finden Sie im Hilfeartikel In Gmail blockierte Dateitypen.
• Die Nachricht befindet sich in einem Ordner oder in einem Zeitraum, der nicht Teil der Migration ist.

Nachrichten fehlen oder wurden mit einem falschen Absender oder Empfänger migriert.

Das kann bei der Migration von Exchange- oder PST-Dateien passieren. Die SMTP-Adresse des Absenders oder Empfängers einer Nachricht kann fehlen und es wird stattdessen die Exchange X.500-Adresse verwendet. Das ist möglicherweise der Fall, wenn kein Profil in der globalen Adressliste (GAL) erstellt wurde oder der Nutzer aus der Liste entfernt wurde.

Was geschieht, wenn mit GWMME eine X.500-Adresse gefunden wird?

Wenn bei der Migration mit GWMME eine X.500-Adresse gefunden wird, wird nach einem MAPI-E-Mail-Profil gesucht, das auf dem Migrationsserver registriert ist, der demselben X.500 Exchange-Organisationsnamen entspricht. Wenn ein solches Profil vorhanden ist, wird die X.500-Adresse mithilfe der Adressbuchregistrierung im MAPI-E-Mail-Profil aufgelöst.

Sollten diese Informationen im Exchange-Adressbuch nicht gefunden werden, wird versucht, die X.500-Adresse in eine SMTP-Adresse umzuwandeln. Dazu wird der letzte CN-Wert der X.500-Adresse berücksichtigt und als Nutzername der E-Mail-Adresse verwendet. Beispiel: Die X.500-Adresse/O=ExchangeOrg/OU=CA/CN=RECIPIENTS/CN=EX_ALIAS ergibt die SMTP-E-Mail-Adresse [e-mail].

So nutzen Sie das Exchange-Adressbuch, um die X.500-Adresse aufzulösen

1. Erstellen Sie auf dem Server, auf dem die Migration ausgeführt wird, ein MAPI-E-Mail-Profil (nicht im Cache-Modus).
2. Das Profil muss auf dem Server eingerichtet sein, der für die PST-Migration verwendet wird.
3. Das MAPI-E-Mail-Profil muss mit dem ursprünglichen Exchange-Server verbunden sein, damit GWMME die Empfänger mithilfe der GAL korrekt auflösen kann.
4. Richten Sie das MAPI-E-Mail-Profil mit dem Nutzer- oder Dienstkonto ein, in dem Sie zurzeit angemeldet sind, um Authentifizierungsfehler auszuschließen.

Wichtiger Hinweis

Testen Sie, ob Sie die Migration richtig eingerichtet haben. Wenn der Fehler weiterhin besteht, werden bei einer neuen Migration die bereits in Ihre Google-Konten migrierten Daten nicht aktualisiert. Löschen Sie die E-Mail-Daten, entfernen Sie sie aus dem Papierkorb und migrieren Sie sie dann noch einmal.

In Gmail enthalten Nachrichten das falsche Datum

Migrierte Nachrichten werden möglicherweise mit dem Datum und der Uhrzeit der Migration angezeigt und nicht mit dem Datum und der Uhrzeit der ursprünglichen E-Mail.

Das liegt meist daran, dass der Datumsheader der ursprünglichen E-Mail nicht RFC 5322-konform ist. Nachrichten mit nicht korrekt formatierten Datumsheadern werden in Gmail mit dem Datum und der Uhrzeit der Migration angezeigt.

Es wird die Fehlermeldung angezeigt, dass der Nutzer weder Teilnehmer noch Organisator der Veranstaltung ist

Dies geschieht, wenn Sie Termine für Nutzer importieren, die nicht der ursprüngliche Organisator bzw. Teilnehmer sind.

Trotz der Fehlermeldung wird der Termin erfolgreich in Google Workspace migriert und der Zielnutzer Google Workspace wird als Teilnehmer des Termins in Google Kalender angezeigt. Das ist erforderlich, da Google Kalender die Auflistung von Kalenderterminen nicht für Nutzer unterstützt, die weder Organisatoren noch Teilnehmer sind.

Weitere Informationen

• FAQ zu GWMME
• GWMME-Fehlercodes
• GWMME-Administratorhandbuch (in englischer Sprache)

_{Google, Google Workspace sowie zugehörige Marken und Logos sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen sind Marken der Unternehmen, mit denen sie verbunden sind.}