Felsök GWMME

Problemet kan bero på att:

• Exchange-servern körs inte.
• Ett nätverksproblem blockerar en anslutning mellan klientdatorn och Exchange-servern. För att verifiera en anslutning, pinga servern från klientdatorn.
• Du använde fel namn för Exchange-servern eller administratören. Så här verifierar du informationen:
  1. På klientdatorn klickar du på Kontrollpanelen E-post för att skapa en Microsoft Outlook-profil för det administratörskonto du vill använda för migreringen.
  2. I GWMME, på skärmen Steg 1 (Serverinformation):
     • I fältet Värdnamn/IP-adress anger du Exchange-värdnamnet från profilen.
     • I fältet Administratörsanvändarnamn anger du användarnamnet från profilen.

Om du migrerar från en värdbaserad server måste profilen för administratörskontot använda standardinställningarna för att ansluta till servern. Anslutningen kommer att misslyckas om du ändrar någon av inställningarna under Kontrollpanelen. Post Profilnamn Fastigheter E-postkonton Profilnamn Ändra e-postkonto Fler inställningar .

Kontrollera att du angav rätt namn och lösenord för administratören.

Om problemet kvarstår, kontrollera att du angav rätt namn för Exchange-servern:

1. På klientdatorn klickar du på Kontrollpanelen E-post för att skapa en Outlook-profil för det administratörskonto du vill använda för migreringen.
2. I GWMME, på skärmen Steg 1 (Serverinformation):
   • I fältet Värdnamn/IP-adress anger du Exchange-värdnamnet från profilen.
   • I fältet Administratörsanvändarnamn anger du användarnamnet från profilen.

Om GWMME kraschar strax efter start, se till att du kör det på din klientdator och inte på Exchange-servern. Att köra verktyget på servern kan orsaka att det kraschar. För mer information, se Microsoft-dokumentationen.

Om du tror att GWMME kraschar på grund av problem med lastbalansering, gå till "Förbered dina Windows-klientdatorer" i GWMME-administratörsguiden .

Ibland stör extra processer som körs på din dator (till exempel antivirus-, sök- eller säkerhetskopieringsprogram) GWMME:s åtkomst till databasfilen under en migrering. Följande felkod i dina loggfiler indikerar att det här problemet har uppstått:

0x80040109
Fail:While stamping the message

Även om meddelandena har migrerats sparade inte GWMME informationen, migreringen lyckades. Om en migrering körs igen med Endast nya data markerat försöker GWMME migrera dessa meddelanden igen. Meddelanden dupliceras inte, men kalenderhändelser eller kontakter kan dupliceras.

Om migreringen misslyckas för en användare, verifiera:

• Användarens namn eller SMTP-adress är korrekt formaterad i användarfilen.
• Användaren är inte dold i den globala adresslistan (GAL).
• Användaren har ett konto på Exchange-servern.
• Användaren har loggat in på Google Workspace, godkänt användarvillkoren och slutfört skapandet av sitt Google Workspace-konto.

Följande felsökningssteg bör lösa alla GWMME OAuth-valideringsfel:

• Se till att du har auktoriserat programvaran för din domän korrekt enligt beskrivningen i Auktorisera GWMME för ditt konto .
• Kontrollera att Google Workspace-användarna och lösenorden som anges i din CSV-fil är korrekta. Ett enda misstag i CSV-filen kan göra att migreringen misslyckas. Mer information finns i Skapa CSV-filer för din migrering .
• På datorn där du kör GWMME, kontrollera att systemklockan är inställd på rätt tid. Om datorns klocka är felaktig skickas fel lokal tidsstämpel till Googles servrar under OAuth-valideringskontrollen, vilket gör att den misslyckas. Synkronisera din dator med internettidsservrar.
• Se till att Google Workspace- superadministratörskontot som används för att autentisera GWMME är giltigt och att användarnamnet är korrekt angett i GWMME-konfigurationen.

GWMME administrerar inte användare i Google Workspace. Skapa Google Workspace-användarkontona innan du migrerar data.

I det här fallet ändrades året i maskinens aktuella datum till 2022, vilket gör att certifikatet verkar föråldrat. Du kan se det aktuella datumet i början av varje loggrad, och datumen " Valid from " och " Valid until " för certifikatet matchar inte det aktuella datumet. Felflaggan WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED indikerar att kontrollen av certifikatåterkallelse misslyckades.

Du kan också se destinations-IP-adressen och det matchade värdnamnet efter " Network connection destination details " på den sista loggraden. Det är en 1e100.net address , vilket betyder att det är Google.

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)

I det här fallet installerades Fiddler och ställdes in på att göra HTTPS-dekryptering (vilket innebär att den använder sitt eget certifikat), men dess certifikat togs bort från Windows lista över betrodda certifikat, så det är inte betrott. Observera att eftersom Fiddler är en proxy anslöt den till 127.0.0.1 och inte till Google. Felflaggorna inkluderar WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA , vilket innebär att systemet inte litar på certifikatutfärdaren (CA). Observera också att Google inte utfärdade detta certifikat.

Ett felmeddelande som liknar det här visas på utdataskärmen eller i spårningsloggfilen:

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

Användarkonton utan nödvändiga behörigheter orsakar oftast detta problem. För att lösa problemet, se till att du ger kontona behörigheten Ta emot som på Exchange.

Om konton har behörigheten Ta emot som och felet kvarstår kan din Exchange-miljö kräva att användarkonton också har behörigheten Skicka som .

Vissa användare kan inte migrera från Exchange 2010 och de får felmeddelandet "Misslyckades med 0x80004005" i spårningsloggfilen. Loggarna innehåller också:

• Slumpmässiga MAPI-anrop till Exchange 2010.
• " BufferTooSmall "-fel i klientåtkomstloggen för fjärrproceduranrop ( RPC ) på Exchange Server 2010-klientåtkomstservern.

Detta är ett känt problem med Exchange 2010, Outlook 2007 och Outlook 2010. Du kan behöva uppdatera till Exchange 2010 SP2 RU3. Mer information finns i Microsoft-dokumentationen om fel vid misslyckade MAPI-anrop.

Om du har många förekomster av HTTP-felkoderna 500, 502 och 503 i loggarna och meddelanden inte laddas upp med felkoden 0x8004106a , kan det vara ett problem med målpostlådan. Det beror vanligtvis på hög belastning.

För att lösa problemet, se till att målpostlådan inte används flitigt. Du kan:

• Stäng av alla synkroniseringsklienter (t.ex. IMAP, POP, mobila enheter och e-postklienter).
• Migrera meddelanden från endast en källa åt gången.

Följande problem indikerar att dina användare inte har etablerats korrekt:

• Ändringar i en kalenderhändelse delas inte med deltagarna.
• Kalendermeddelanden och uppdateringar sprids inte till deltagarnas kalendrar.

Administrera alla dina användare i Google Workspace innan du migrerar några konton – även om du bara vill göra en delvis migrering. Se till att lägga till alla domänalias och smeknamn. Lös sedan problemet genom att ta bort och återskapa alla händelser där användaren är organisatör eller gäst.

GWMME har som standard en datamigreringshastighet på 25 användare per sekund. Denna hastighet överstiger standardantalet frågor per sekund (QPS) för både Contacts API och Calendar API.

För att lösa problemet, kör migreringar för kontakter och kalendrar:

• Separat från e-postmigreringar.
• Med en lägre hastighet på 4–8 användare per sekund.

Om vissa meddelanden inte migreras kan meddelandet överskrida den storleksgräns som Gmail har satt. Eller så kan det innehålla bilagor som blockeras av Gmail. Mer information finns i Filtyper som blockeras i Gmail .

Du kan också behöva ta bort begränsningar för mappstorlek och se till att mappar visas i IMAP. Mer information finns i Aktivera och inaktivera POP och IMAP för användare .

Google Workspace uppskattar antalet meddelanden i din inkorg efter en migrering. Den ger inte ett absolut antal. Antalet meddelanden som anges i din Gmail-inkorg kan skilja sig från antalet meddelanden i din äldre inkorg.

Om du tror att du missar några meddelanden, kontrollera om:

• Meddelandet, inklusive bilagor, är inte större än 25 MB. Du kan inte migrera meddelanden som är större än 25 MB. Mer information finns i Skicka bilagor med ditt Gmail-meddelande .
• Gmail blockerar inte en bilaga till meddelandet. Gmail förhindrar vissa typer av bilagor, till exempel körbara filer. Mer information finns i Filtyper blockerade i Gmail .
• Meddelandet finns i en mapp eller inom ett datumintervall som ingår i migreringen.

Saknade meddelanden eller meddelanden som migrerats med fel avsändare eller mottagare kan uppstå vid migrering av Exchange- eller PST-filer. SMTP-adressen för ett meddelandes avsändare eller mottagare kan saknas och Exchange X.500-adressen används istället. Detta kan inträffa om ingen global adresslista (GAL)-profil har skapats eller om användaren har tagits bort från GAL:en.

Vad händer när GWMME hittar en X.500-adress

När GWMME hittar en X.500-adress söker den efter en MAPI-e-postprofil som är registrerad på migreringsservern och som matchar samma X.500 Exchange-organisationsnamn. Om den hittar en matchar GWMME X.500-adressen med hjälp av adressboksregistreringen i MAPI-e-postprofilen.

Om GWMME inte hittar den här informationen i Exchange-adressboken försöker den konvertera X.500-adressen till en SMTP-adress. För att göra detta tar den hänsyn till det sista CN-värdet i X.500-adressen och använder det som användarnamn för e-postadressen. Till exempel resulterar X.500-adressen /O=ExchangeOrg/OU=CA/CN=RECIPIENTS/CN=EX_ALIAS i SMTP-e-postadressen ex_alias@example.com.

Hur man använder Exchange-adressboken för att matcha X.500-adressen

1. Skapa en MAPI-e-postprofil (icke-cacheläge) på servern som utför migreringen.
2. Se till att MAPI-e-postprofilen är konfigurerad på servern som används för att utföra PST-migreringen.
3. MAPI-e-postprofilen måste vara ansluten till den ursprungliga Exchange-servern så att GWMME kan matcha mottagarna korrekt med hjälp av den allmänna adressen (GAL).
4. Konfigurera MAPI-e-postprofilen med det användar- eller tjänstkonto som för närvarande är inloggat för att undvika autentiseringsfel.

Viktig anmärkning

Testa och bekräfta att du har konfigurerat migreringen korrekt. Om problemet kvarstår kommer ommigreringen inte att uppdatera data som redan har migrerats till dina Google-konton. Radera e-postdatan, ta bort den från papperskorgen och migrera sedan om.

Migrerade meddelanden kan visa migreringsdatum och -tid, snarare än tid och datum för det ursprungliga meddelandet.

Detta beror troligtvis på att datumrubriken i det ursprungliga meddelandet inte är kompatibel med RFC 5322. Om ett meddelande har en datumrubrik som inte är korrekt formaterad tillämpar Gmail migreringstiden och -datumet på meddelandet.

Detta händer när du importerar händelser för användare som inte är en av de ursprungliga organisatörerna eller första deltagare för händelsen.

Oavsett varningsmeddelandet migreras händelsen till Google Workspace och Google Workspace-målanvändaren visas som deltagare i händelsen i Google Kalender. Detta är nödvändigt eftersom Kalender inte stöder att lista kalenderhändelser för en användare som inte är organisatör eller deltagare.