Felsök vanliga GCDS-problem

Om du har problem med att få en synkronisering att fungera korrekt, bekräfta att konfigurationsinformationen är korrekt i Konfigurationshanteraren och notera vilka tester som misslyckas:

1. I Konfigurationshanteraren öppnar du XML-filen som du använder för att konfigurera synkroniseringen.
2. På sidan LDAP-anslutningar klickar du på Testa anslutningar för att bekräfta att du kan ansluta till din LDAP-server.
3. På sidan Aviseringar klickar du på Testavisering för att bekräfta att du kan skicka en testavisering.
4. På sidan Synkronisera klickar du på Simulera synkronisering för att bekräfta att du har fyllt i alla obligatoriska fält och att synkroniseringen körs.

I sällsynta fall kan supporten be dig att aktivera fullständig HTTP-loggning utöver att aktivera spårningsnivåloggning i GCDS. Fullständig HTTP-loggning används för att se den exakta API-begäran som görs av GCDS och svaret som tillhandahålls av Googles API:er.

Viktigt : Fullständiga HTTP-loggar kan innehålla mycket känslig information. Ta bort all känslig information (t.ex. aktuella fält för refresh_token eller access_token) innan du skickar loggarna till supporten.

Så här aktiverar du fullständig HTTP-loggning:

1. Se till att GCDS inte körs med vare sig sync-cmd eller Configuration Manager.
2. Navigera till GCDS-installationsmappen.

3. Redigera filen jre/lib/logging.properties .

4. Lägg till följande rader i slutet av filen:

   java.util.logging.FileHandler.pattern = %h/gcdshttp%u.%g.log
   java.util.logging.FileHandler.limit = 5000000
   java.util.logging.FileHandler.count = 100
   java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
   hanterare = java.util.logging.FileHandler
   com.google.api.client.http.level = KONFIG
   
   com.google.gdata.client.http.HttpGDataRequest.level = ALL
   sun.net.www.protocol.http.HttpURLConnection.level = ALL

5. Spara filen.
6. Kör en annan GCDS-synkronisering (med loggningen inställd på Trace ).

   Loggfiler med namnet gcdshttp*.log skapas i homedir (Linux) eller profilmappen (Microsoft Windows). Arkivera dessa filer tillsammans, eftersom de kan vara ganska stora.

7. Ta bort raderna som lades till i steg 4 för att förhindra att stora loggfiler skapas i framtiden.
8. Tillhandahåll följande filer som stöd:
   • XML-fil
   • Spårningsnivåloggar och gcdshttp*.log- filerna från den senaste synkroniseringen

TIPS: Om du vill aktivera loggning för en ny klass, lägg till en rad i formen class.fqdn.level = ALL , du behöver inte duplicera hela installationsblocket.

Loggade begäranden och svarstexter är vardera begränsade till en storlek på 16 KB. Om du ser en loggpost som är avkortad eftersom den överskrider den gränsen, använd en felsökningsproxy, till exempel Fiddler.

För att aktivera Fiddler, följ dessa steg:

Starta om GCDS för att ändringarna ska träda i kraft.

Om du använder GCDS på Linux kan du inte använda Windows betrodda certifikatarkiv, så du måste importera Fiddler-rotcertifikatet till GCDS Java-trustarkiv. Mer information om dessa steg finns i Felsök certifikatrelaterade problem .

1. Gå till sökvägen där GCDS är installerat, till exempel C:\Program Files\Google Cloud Directory Sync .
2. Lägg till följande flaggor i .vmoptions filerna (till exempel config-manager.vmoptions eller sync-cmd.vmoptions) för att inaktivera CRL-kontrollerna:

   -Dcom.sun.security.enableCRLDP=false

   -Dcom.sun.net.ssl.checkRevocation=false

   1. Konfigurera Fiddler som en proxy i proxyinställningarna för din Google-domänkonfiguration. I fältet värdnamn lägger du till den lokala IP-adressen 127.0.0.1 . Standardporten är 8888 , men du kan bekräfta detta genom att öppna Fiddler, gå till Alternativ > Anslutningar och kontrollera värdet i fältet "Fiddler Classiclyssnar på port".

Om du har problem med att konfigurera SMTP-relävärden för dina aviseringar kan du prova följande felsökningssteg.

Anslutningsmisslyckades och okänt SMTP-värdmeddelande

1. Öppna en kommandotolk.
2. För att kontrollera om det konfigurerade värdnamnet för SMTP-servern matchar en IP-adress, ange följande kommando:

   nslookup smtp-värdnamn .com

Anslutningen misslyckades och det gick inte att ansluta till SMTP-värdmeddelandet

Kontrollera om servern som kör GCDS kan ansluta till SMTP-värden.

1. För att kontrollera anslutningen, ange följande kommando från Windows kommandorad eller terminal:

   telnet smtp.gmail.com 587

2. Om värden inte kan ansluta, kontrollera brandväggsreglerna för ingångstrafik för SMTP-servern och brandväggsreglerna för utgångstrafik för GCDS-servern.
3. Se till att du har tillåtit trafik på SMTP-porten.

Kunde inte konvertera socket till TLS-fel i loggarna

Stäng av kontroller av certifikatåterkallningslistor (CRL). Mer information finns i Hur GCDS kontrollerar certifikatåterkallningslistor .

Se Arbeta med konfigurationsfiler för instruktioner om hur du öppnar en XML-fil som har sparats på en annan dator, eller som en annan användare på samma dator.

Om LDAP-data i GCDS-spårningsnivåloggarna inte matchar vad du förväntar dig att läsa på LDAP-servern (till exempel om en användare inte hittas eller om ett attribut inte har rätt värde), exporterar du data från LDAP-katalogen i LDIF-format. Supporten kan jämföra data med LDAP-data från GCDS-loggarna.

När du exporterar data, använd ett LDAP-frågeverktyg som ldapsearch (Linux) eller ldifde (Windows) och simulera samma förhållanden som GCDS körs med:

• Använd samma anslutningsinställningar som de som GCDS är konfigurerat att använda.
• Kör frågeverktyget från samma dator som GCDS körs på.
• Använd samma användarnamn för GCDS LDAP-autentisering.

Exempel

Dina GCDS-loggar visar inte användarnas mail- attribut, och dina GCDS-sökregelinställningar är:

• Bas-DN: ou=Ireland,dc=altostrat,dc=com
• Omfattning: Underträd
• Sökfilter: (&(objektkategori=person)(objektklass=användare))
• Server: dc01.altostrat.com
• Hamn: 636
• Protokoll: LDAP+SSL
• Autentiseringsanvändar-DN: cn=GCDS,ou=Användare,dc=altostrat,dc=com

Använd dessa kommandon:

• Linux: ldapsearch -v -b "ou=Ireland,dc=altostrat,dc=com" -s sub -h dc01.altostrat.com -p 636 -x -Z -D "cn=GCDS,ou=Users,dc=altostrat,dc=com" "(&(objectCategory=person)(objectClass=user))" mail givenname uniqueidentifier sn > out.ldif (Du kan behöva ändra kommandot beroende på ditt system.)
• Windows: ldifde -f out.ldif -s dc01.altostrat.com -v -t 636 -d "ou=Ireland,dc=altostrat,dc=com" -r "(&(objectCategory=person)(objectClass=user))" -p SubTree -l mail,givenname,uniqueidentifier,sn -a "cn=GCDS,ou=Users,dc=altostrat,dc=com" PASSWORD (Ersätt PASSWORD med lösenordet för LDAP-användaren som angetts i GCDS.)

Om utdata (out.ldif) inte innehåller attributet mail för en berörd användare finns det ett problem med LDAP-infrastrukturen. Det kan vara relaterat till behörigheterna för den användare du använder för att komma åt LDAP (till exempel tillåter både OpenLDAP och Active Directory inställning av behörigheter på attributnivå). Eller så kanske attributet inte replikeras till den globala katalogen, om du använder en global katalogport som 3268 eller 3269.

Om utdata innehåller mail- attributet för en berörd användare, ange följande information till Google Workspace-supporten:

• out.ldif -filen
• En skärmdump av kommandotolken eller terminalfönstret där du körde kommandot
  (Se till att ta bort lösenordet först.)
• GCDS-spårningsnivåloggen

För att köra en simulerad synkronisering behöver du en server som kan skicka e-post. Om du kör GCDS på en e-postserver kan du använda IP-adressen 127.0.0.1 för din e-postserver. Annars kontaktar du din e-postadministratör för korrekt e-postinformation.

Om du använder kommandoraden för att köra en synkronisering och synkroniseringen inte startar, kontrollera om du använde argumentet -o eller --oneinstance i kommandoraden.

Om du använder ett av dessa argument skapar GCDS en LOCK-fil (.lock) som är associerad med XML-konfigurationsfilen. Och om en annan LOCK-fil hittas på samma server kör GCDS inte synkroniseringen för att förhindra att flera instanser av GCDS körs samtidigt.

Om det inte finns någon annan instans av GCDS som körs, kontrollera om det finns en annan LOCK-fil på servern. Ta bort filen manuellt och försök att köra synkroniseringen igen.

Om din synkronisering var ofullständig, till exempel om det fullständiga medlemskapet i en grupp inte synkroniserades, kan det vara ett problem med Directory API. För att kontrollera om problemet relaterar till ett API snarare än GCDS-produkten, anropa Directory API manuellt och granska resultaten. För att anropa API:et manuellt, välj ett av två alternativ.

Alternativ 1: Använd API-referenssidan

1. Gå till referensöversikten för Admin SDK API .
2. Till vänster klickar du på Directory API och går sedan till den REST-resurs du vill fråga efter under REST-resurser .
3. Till höger klickar du på den metod du vill prova och klickar på Prova det .

   Om API-referenssidan inte visar "Prova det" , gå till alternativ 2: Använd OAuth 2.0 Playground.

4. Ange administratörsuppgifterna som du använde för att auktorisera GCDS.

   För mer information, gå till Ange dina Google-domäninställningar .

5. Granska informationen för att säkerställa att API:et svarade som förväntat.

Alternativ 2: Använd OAuth 2.0 Playground

1. Öppna OAuth 2.0-lekplatsen .
2. Välj ett alternativ:
   • Välj ett omfång från listan.
   • Kopiera ett omfång från listan Auktoriseringsomfång på API-referenssidan. Klistra sedan in omfånget i fältet Ange dina egna omfång .
3. Klicka på Auktorisera API: er.
4. Ange administratörsuppgifterna som du använde för att auktorisera GCDS.

   För mer information, gå till Ange dina Google-domäninställningar .

5. Klicka på Utbytesauktoriseringskod för tokens .

   Om processen lyckas omdirigeras du till steg 3: Konfigurera begäran till API .

6. Fyll i den begärda informationen.

   Tips : Du hittar det mesta av informationen på webbsidan för API-metodens referens.

7. Klicka på Skicka begäran .
8. Granska informationen för att säkerställa att API:et svarade som förväntat.

I din XML-konfigurationsfil ställer du in alternativet useDynamicMaxCacheLifetime . Det här alternativet konfigurerar GCDS att cachelagra data i maximalt 8 dagar och rensa cachen oftare i små till medelstora datamängder för att minska risken för att cachade data blir inaktuella eller står i konflikt med nya data. Alternativet useDynamicMaxCacheLifetime är automatiskt i konfigurationer som skapats med GCDS 3.2.1 och senare.

Obs! Dessa fel uppstår vanligtvis när ändringar görs direkt i din Google-domän. När du använder GCDS för att synkronisera bör du undvika att göra ändringar direkt i din Google-domän. Gör istället ändringar i användare, grupper och andra enheter i din LDAP-katalog. Använd sedan GCDS för att synkronisera dessa ändringar till din Google-domän.

Om du ser minnesrelaterade fel behöver du öka heap-storleken för Java Virtual Machine. Öka heap-storleken genom att redigera filerna sync-cmd.vmoptions och config-manager.vmoption s i installationskatalogen för GCDS. De relevanta posterna ser ut så här:

• - X mx1000m (den maximala mängden minne som allokeras för heapstorleken)
• - X ms64m (den minsta mängd minne som allokeras för heapstorleken)

Redigera både filerna sync-cmd.vmoptions och config-manager.vmoptions så att ändringen gäller både sync-cmd- och Configuration Manager-versionerna.

Redigera numret -X mx för att öka mängden minne. "m" efter numret indikerar att minnet mäts i megabyte (MB). Rätt mängd minne beror på hur mycket GCDS-servern har och hur mycket den behöver för en synkronisering. Du kan behöva revidera numret flera gånger för att ställa in rätt storlek. För mer information om mängden ledigt RAM-minne som krävs för att köra GCDS, gå till Systemkrav för GCDS .

Problemet kan orsakas av ett konfigurationsproblem, till exempel en felaktig konfiguration av en undantagsregel. Den här typen av felaktig konfiguration kan döljas av GCDS-cachning.

GCDS lagrar en cache med data för din Google-tjänst (som Google Workspace eller Cloud Identity) i högst 8 dagar. GCDS kan rensa cachen oftare, beroende på storleken på den cachade datan. Men om cachen inte rensas kanske du inte ser dina uppdateringar på upp till 8 dagar.

Du synkroniserar till exempel dina LDAP-data och skapar en ny grupp för din Google-tjänst (t.ex. Google Workspace eller Cloud Identity). Sedan skapar du en undantagsregel för att exkludera den gruppen från efterföljande synkroniseringar. Undantagsregeln är felkonfigurerad och kommer att misslyckas. Den efterföljande synkroniseringen anropar dock cachade data och gruppen finns kvar i din Google-tjänst. När du synkroniserar igen med ren cache, leder felkonfigurationen till att gruppen tas bort från din Google-tjänst.

Så här rensar du cachen manuellt:

• Kör en synkronisering från Konfigurationshanteraren och välj alternativet att rensa cachen när du utför en synkronisering.
• Kör en synkronisering från kommandot och använd argumentet -f för att tvinga fram en tömning av cachen.
• Ändra XML-konfigurationsfilen för att ställa in maxCacheLifetime-värdet till 0.

Viktigt : Att tvinga fram en tömning av cachen kan öka synkroniseringstiden dramatiskt.

Om du får felet 409: Entiteten finns redan , försöker GCDS skapa Google-användare som redan finns. Om du inte ser felet i efterföljande synkroniseringar är det troligt att GCDS-cachen var föråldrad och det är säkert att ignorera felet.

Om problemet uppstår vid varje synkronisering eller med några dagars mellanrum är de mest troliga orsakerna:

• En Google-användarundantagsregel är för bred – regeln matchar vissa Google-användare som också finns i LDAP-katalogen.
• En fråga är för snäv – frågan matchar inte vissa Google-användare som också finns i LDAP-katalogen.

Båda scenarierna kan göra att GCDS ignorerar Google-användare som redan finns. Om dessa användare finns i resultaten för LDAP-användarens sökregel försöker GCDS skapa dem i ditt Google-konto.

För att lösa problemet, justera undantagsregeln eller sökfrågan. Eller, om du vill att GCDS ska ignorera användarna i din LDAP-katalog helt, justera din LDAP-användarsökregel eller skapa en LDAP-användarundantagsregel. Mer information finns i Utelämna data med undantagsregler och frågor .

Ibland synkroniseras inte dina anpassade schemaattribut, särskilt de som nyligen skapats, från din LDAP-katalog till dina Google-användare. När detta händer förblir attributfälten för dina Google-användare tomma, även efter en lyckad synkronisering.

Möjliga orsaker inkluderar:

• Den auktoriserade användaren för LDAP-servern, som är konfigurerad i Google Cloud Directory Sync (GCDS), har inte läsåtkomst till de specifika attributen i din LDAP-katalog.
• Om du använder den globala katalogservern (port 3268 eller 3269) och inte har markerat rutan Replikera detta attribut till den globala katalogen från Active Directory-schemat, kommer dina anpassade schemaattribut inte att hittas på Google Cloud-servern under synkroniseringen.

För att säkerställa att dina anpassade schemaattribut synkroniseras, prova följande steg:

1. Samarbeta med din LDAP-administratör för att säkerställa att användaren som är konfigurerad i GCDS för LDAP-autentisering har läsåtkomst till alla attribut som inte synkroniseras.
2. Använd samma maskin som kör GCDS och använd en LDAP-webbläsare för att ansluta till din LDAP-server. När du ansluter, se till att autentisera med samma användare som GCDS använder. Hitta en av de berörda användarna och kontrollera att du kan se värdena för de attribut som inte synkroniseras.
3. När du har bekräftat att behörigheterna är korrekta, rensa GCDS-cachen och kör en synkronisering.

Om dina anpassade schemaattribut fortfarande inte synkroniseras, samla in din GCDS-information och kontakta supporten. För mer information, gå till Vilken GCDS-information behöver jag innan jag kontaktar supporten?

För att synkronisera gruppmedlemmar separat från resultaten av eventuella sökregler för användare aktiverar GCDS INDEPENDENT_GROUP_SYNC som standard. Om du använder medlemsreferensattribut för gruppsynkroniseringar försöker GCDS matcha e-postadressen för varje användare i LDAP-katalogen, oavsett eventuella sökregler för användare.

För att synkronisera gruppmedlemmar baserat endast på resultaten från användarnas sökregler, ta bort INDEPENDENT_GROUP_SYNC från din konfigurations-XML-fil. GCDS:

• Använder resultaten av användarnas sökregler för att identifiera gruppmedlemskap
• Synkroniserar endast som gruppmedlemmar de användare som ingår i din användarsynkronisering
• Kör regler för användarsökning, även om du inaktiverar synkronisering av användarkonton i de allmänna inställningarna

  (Resultaten synkroniseras dock inte med Google som användare utan som gruppmedlemmar, om de berättigade användarna också kvalificerar sig som gruppmedlemmar.)

Vanligtvis är det inte så här du vill att din synkronisering ska gå till, särskilt om du synkroniserar delade kontakter och har gruppmedlemmar som är kontakter. I det här fallet synkroniseras inte kontakterna som gruppmedlemmar.

Det här problemet uppstår när LDAP-attributet som konfigurerats som gruppnamnsattribut inte innehåller en fullständig e-postadress. För att lösa problemet, kontrollera dina gruppsökningsregler och se till att GCDS använder en fullständig e-postadress för gruppnamnen. Använd någon av följande metoder:

• Ställ in attributet Gruppnamn till ett annat LDAP-attribut som anger en fullständig e-postadress för varje grupp, till exempel e-post.
• Aktivera Ersätt domännamn i LDAP-e-postadresser i Googles domäninställningar så att ditt gruppnamnsattribut matchar gruppnamnen på Googles sida.
• Lägg till domännamnet till gruppnamnet genom att ange ett gruppnamnssuffix i din gruppsökregel.

Se till att du har valt MS Active Directory i fältet för servertyp i avsnittet LDAP-konfiguration .

Det här alternativet (visas som SUPPRESS_DOMAIN i XML-filen) används om e-postadresserna i LDAP-katalogen finns i en annan domän än din Google-domän. När du aktiverar det tar GCDS bort domändelen från alla e-postadresser som läses.

All bearbetning sker utan domännamnet. Om du använder undantagsregler baserade på e-postadresser behöver du endast beakta den lokala delen av e-postadressen för undantagsregeln.

Om du till exempel har avaktiverat Ersätt domännamn i LDAP-e-postadresser och skapar en undantagsregel för exakt matchning, ange luka@example.com som användarens e-postadress som ska matchas. Om du har aktiverat Ersätt domännamn i LDAP-e-postadresser , använd luka . Att försöka matcha luka@example.com fungerar inte eftersom @example.com tas bort före jämförelsen.

När du etablerar grupper med GCDS kan du inte kapsla dynamiska grupper under statiska grupper (eller statiska grupper under dynamiska grupper). GCDS kräver att statiska grupper efterfrågas separat från dynamiska grupper; alla kapslade grupper måste dock ingå i samma fråga.

Hitta ett sätt att implementera dynamiska grupper som statiska grupper, eventuellt genom att automatisera en uppgift som regelbundet frågar varje dynamisk grupp om att fylla i statiska grupper i katalogen. GCDS kan sedan använda de statiska grupperna (som skapats från de dynamiska grupperna) för provisionering och inte för provisionering av den dynamiska gruppen.

Resultat för LDAP-frågor beror på inställningarna i Configuration Manager och LDAP-servern. Använd dessa felsökningstips om din LDAP-sökregel returnerar ett oväntat resultat. Se till att:

• LDAP-frågan är korrekt konfigurerad i Konfigurationshanteraren — När du konfigurerar en sökregel klickar du på Testa LDAP-fråga för att verifiera. Mer information finns i Använd LDAP-sökregler för att synkronisera data .
• Flera frågor motsäger inte varandra – Kontrollera att du inte har konfigurerat en sök- eller undantagsregel som ändrar resultatet av en fråga.
• Den behöriga användaren för LDAP-servern har tillräckliga behörigheter — Kontrollera att administratören som används för att autentisera LDAP-servern kan använda kommandoraden på samma server. Försök att utföra frågan på LDAP-servern och verifiera resultaten.

Du kan stöta på felmeddelandet Grupp ... kunde inte skapas . Meddelande: Inte behörig att komma åt den här resursen/API:et i GCDS-loggarna.

För att felsöka, kontrollera att Active Directory (AD)-attributet som innehåller domänen för användar- och grupp-e-postadresser matchar den domän som ditt superadministratörskonto använder.

Det här problemet uppstår vanligtvis om du synkroniserar delade kontakter och sökreglerna är felaktigt utformade.

Det finns två typer av relevanta objekt som du kan synkronisera med GCDS:

• Användarprofiler — Användare i din Google-domän med ytterligare data, till exempel ett telefonnummer eller en adress. Du kan bara synkronisera en profil för en användare som finns i din domän.
• Delade kontakter — Kontakter från externa parter som användare i din domän behöver kontakta.

För att lösa problemet, korrigera dina sökregler för delade kontakter så att de exkluderar användare i din egen domän. Vid nästa synkronisering försöker GCDS ta bort de redundanta kontakterna. Du kan behöva justera gränsen för borttagning av delade kontakter för den första synkroniseringen.

Under vissa omständigheter ser användare inte sin huvudsakliga arbetsplats i Google Kalender när de schemalägger eller arrangerar möten.

Om du ser det här problemet, se till att platstyp och områdesattribut är inställda på "skrivbord".

Om du har problem med sökresultaten, kontrollera:

• Regelns omfattning. Du kan behöva ställa in omfattningen till Underträd .
• Sökregeln du använder är korrekt.
• De attribut som används finns och är synliga.
• Din LDAP-fråga. Kontrollera att frågan på din LDAP-server använder administratörsanvändarnamnet som är konfigurerat i GCDS.

För mer information, gå till Använd LDAP-sökregler för att synkronisera data .

Du kanske använder ett teckensnitt som är för stort för skärmen. Dialogrutan fungerar inte med stora eller extra stora teckensnitt. Ändra teckenstorleken eller redigera din XML-fil direkt.

Om din sökning bara importerar 1 000 tillgängliga användare (eller standardstorleken för LDAP-sidorna) kan inställningen för LDAP-värdnamn i Configuration Manager vara inställd på en generisk domän eller skogsrotdomän som utfärdar hänvisningar för objekt i ditt bas-DN.

Åtgärda problemet genom att uppdatera Configuration Manager så att värdnamnsinställningen matchar bas-DN-inställningen. Eller använd en domänkontrollant (till exempel dc01.example.com) som innehåller användarkontoobjekten i bas-DN:et.