Felsökning av vanliga GCDS-frågor

Om du har problem med att få en synkronisering att fungera korrekt, bekräftar du att konfigurationsinformationen är korrekt i konfigurationshanteraren och noterar vilka test 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å Testanslutningar och bekräftar att du kan ansluta till LDAP-servern.
3. På sidan Aviseringar klickar du på Testavisering och bekräftar att du kan skicka en testavisering.
4. På sidan Synkronisering klickar du på Simulera synkronisering och bekräftar att du har fyllt i alla obligatoriska fält och för att bekräfta att synkroniseringen körs.

I sällsynta fall kan supporten be dig att aktivera fullständig HTTP-loggning i tillägg till aktivering av spårnivåloggning i GCDS. Fullständig HTTP-loggning används för att se den exakta API-begäran som gjorts av GCDS och svaret från Googles API:er.

Viktigt! Fullständiga HTTP-loggar kan innehålla mycket känslig information. Du bör ta bort känslig information (som de aktuella fälten för refresh_token eller access_token) innan du skickar loggarna till supporten.

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

1. Kontrollera att GCDS inte körs med sync-cmd eller konfigurationshanteraren.
2. Navigera till installationsmappen för GCDS.

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
   handlers = java.util.logging.FileHandler
   com.google.api.client.http.level = CONFIG
   
   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-synk (med loggningen inställd på Spåra).

   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 sedan följande filer till supporten:
   • XML-fil
   • Loggar på spårningsnivå och gcdshttp*.log-filerna från den senaste synkroniseringen

TIPS! Om du vill aktivera loggning för en ny klass lägger du till en rad i form av class.fqdn.level = ALL. Du behöver inte duplicera hela konfigurationsblocket.

Loggad begäran och loggade svar är begränsade till en storlek på 16 kB vardera. Om du ser en loggpost som har trunkerats på grund av att den överskrider gränsen använder du en felsökningsproxy, till exempel Fiddler.

Så här aktiverar du Fiddler:

Starta om GCDS för att ändringarna ska börja gälla.

Om du använder GCDS på Linux kan du inte använda Windows betrodda certifikatarkiv. Du måste därför importera Fiddler-rotcertifikatet till GCDS Java-förtroendearkiv. Mer information om dessa steg finns i Felsöka certifikatrelaterade problem.

1. Öppna 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 proxy i proxyinställningarna för Google-domänkonfigurationen. Lägg till den lokala IP-adressen 127.0.0.1 i fältet för värdnamn. Standardporten är 8888, men du kan bekräfta detta genom att öppna Fiddler, gå till Options > Connections och kontrollera värdet i fältet Fiddler Classiclistens on port.

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

Meddelande om att anslutningen misslyckades och okänd SMTP-värd

1. Öppna en kommandotolk.
2. Kontrollera om det konfigurerade värdnamnet för SMTP-servern hänvisar till en IP-adress genom att ange följande kommando:

   nslookup smtp-host-name.com

Meddelandet Det gick inte att ansluta och Det gick inte att ansluta till SMTP-värden

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

1. Kontrollera anslutningen genom att ange följande kommando på kommandoraden eller i terminalen i Windows:

   telnet smtp.gmail.com 587

2. Om värden inte kan ansluta kontrollerar du SMTP-serverns regler för inkommande brandvägg och GCDS-serverns regler för utgående brandvägg.
3. Kontrollera att du har tillåtit trafik på SMTP-porten.

Fel: Det gick inte att konvertera socket till TLS i loggarna

Inaktivera kontroller av listor över återkallade certifikat (CRL). Mer information finns i Så här kontrolleras listor med återkallade certifikat i GCDS.

Instruktioner om att öppna en XML-fil som sparats på en annan dator eller som en annan användare på samma dator finns i Jobba med konfigurationsfiler.

Om LDAP-datan i GCDS-loggarna på spårningsnivå inte stämmer överens med det 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-datan från GCDS-loggarna.

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

• Använd samma anslutningsinställningar som de som GCDS har konfigurerats för 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

GCDS-loggarna visar inte användarnas e-postattribut och inställningarna för GCDS-sökregler är:

• Bas-DN: ou=Irland,dc=altostrat,dc=com
• Omfattning: Subtree
• Sökfilter: (&(objectCategory=person)(objectClass=user))
• Server: dc01.altostrat.com
• Port: 636
• Protokoll: LDAP+SSL
• Användar-DN för autentisering: cn=GCDS,ou=Users,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 har angetts i GCDS.)

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

Om utdatan innehåller attributet mail för en berörd användare anger du följande uppgifter till supporten för Google Workspace:

• Filen out.ldif
• En skärmbild av kommandotolken eller terminalfönstret där du körde kommandot
  (ta bort lösenordet först)
• GCDS-spårningsnivålogg

Beskrivning: Problemet uppstår med Google Cloud Directory Sync (GCDS) version 5.0.22 när du slutför följande steg:

1. I Konfigurationshanteraren klickar du på Google-domän och sedan på Uteslutningsregler för konfiguration.
2. Ange en användares sökfråga för Sökfråga för användare och spara konfigurationsfilen.
3. Radera samma sökfråga och spara konfigurationsfilen.
4. Jämför konfigurationsfilen i steg 2 med filen i steg 3.

   Konfigurationsfilen är densamma. Den raderade sökfrågan sparades inte i filen.

Lösning: Öppna konfigurationsfilen och radera inställningen manuellt.

Om du vill köra en simulerad synkronisering behöver du en server som kan skicka e-post. Om du kör GADS på en e-postserverdator kan du använda IP-adressen 127.0.0.1 för din e-postserver. Annars kontaktar du e-postadministratören för rätt e-postinformation.

Om du kör en synkronisering via kommandoraden och synkroniseringen inte startar kontrollerar du om du använde argumentet -o eller --oneinstance på kommandoraden.

Om du använder ett av dessa argument skapar GCDS en LOCK-fil (.lock) som är kopplad till XML-konfigurationsfilen. 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 kontrollerar du om det finns en annan LOCK-fil på servern. Radera filen manuellt och försök köra synkroniseringen igen.

Om synkroniseringen var ofullständig, till exempel om det fullständiga medlemskapet i en grupp inte synkroniserades, kan det finnas ett problem med Directory API. Verifiera om problemet rör ett API i stället för GCDS-produkten genom att anropa Directory API manuellt och granska resultaten. Välj ett av två alternativ för att anropa API:et manuellt.

Alternativ 1: Använd API-referenssidan

1. Gå till Översikt över Admin SDK API-referens.
2. Klicka på Directory API till vänster och gå sedan till den REST-resurs som du vill söka efter i REST-resurser.
3. Klicka på metoden du vill testa till höger och klicka på Testa.

   Om API-referenssidan inte visar Testa går du till Alternativ 2: Använd OAuth 2.0 Playground.

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

   Mer information finns i Definiera dina Google-domäninställningar.

5. Granska informationen för att se till att API:et svarade som förväntat.

Alternativ 2: Använd OAuth 2.0 Playground

1. Öppna OAuth 2.0 Playground.
2. Välj ett alternativ:
   • Välj en omfattning i listan.
   • Kopiera en omfattning från listan Auktoriseringsomfattningar på API-referenssidan. Klistra sedan in omfattningen i fältet Ange egna omfattningar.
3. Klicka på Auktorisera API:er.
4. Ange de administratörsuppgifter som du använde för att auktorisera GCDS.

   Mer information finns i Definiera dina Google-domäninställningar.

5. Klicka på Exchange authorization code for 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å referenswebbsidan för API-metoden.

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

Beskrivning: Problemet uppstår med Google Cloud Directory Sync (GCDS). Om du ändrar en användares primära e-postadress på LDAP-servern tas namnbytet inte med i beräkningen när GCDS synkroniserar användarens licens. GCDS försöker lägga till licensen för användaren med det nya namnet och du får ett 412-fel.

Beskrivning: Google Cloud Directory Sync (GCDS) använder en unik identifierare för att länka användare mellan Google Workspace och din externa katalog. Microsoft Active Directory-användare har identifieraren ObjectGUID och Microsoft Azure Active Directory-användare har ett objekt-id.

Om du skapar en användare på nytt i den externa katalogen får den nya användaren en ursprunglig identifierare för ObjectGUID eller Object ID. Eftersom den nya användarens e-postadress redan är länkad till den raderade användaren i Workspace misslyckas synkroniseringen.

Lösning: Om du planerar att återskapa en användare med samma e-postadress sparar du användarens ObjectGUID eller objekt-id i den externa katalogen. Du kan även byta namn på eller radera användarens e-postadress i Workspace så att GCDS kan länka det nya användarkontot till den nya användaren i den externa katalogen.

Aktivera alternativet useDynamicMaxCacheLifetime i din XML-konfigurationsfil. Detta alternativ konfigurerar GCDS så att data lagras i cacheminnet i högst åtta dagar. Genom att rensa cacheminnet oftare i små till medelstora datamängder minskas risken för att cachelagrad information blir inaktuell eller hamnar i konflikt med ny information. useDynamicMaxCacheLifetime är automatiskt i konfigurationer som skapats med GCDS 3.2.1 och senare.

Obs! Dessa fel brukar uppstå när ändringar görs direkt på Google-domänen. När du använder GCDS för synkronisering bör du undvika att göra ändringar direkt på Google-domänen. Istället ska du göra ändringar av användare, grupper och andra enheter i LDAP-katalogen. Använd sedan GCDS för att synkronisera dessa ändringar på Google-domänen.

Om du ser minnesrelaterade fel måste du öka stackstorleken för den virtuella Java-datorn. Öka stackstorleken genom att redigera filerna sync-cmd.vmoptions och config-manager.vmoptions i GCDS-installationskatalogen. De relevanta posterna ser ut så här:

• -Xmx1 000m (den maximala mängden minne för stacktorleken)
• -Xms64m (den minsta mängden minne för stackstorleken)

Redigera filerna sync-cmd.vmoptions och config-manager.vmoptions så att ändringen gäller både versioner av sync-cmd och konfigurationshanteraren.

Redigera -Xmx för att öka mängden minne. Bokstaven "m" efter talet anger att minnet mäts i megabyte (MB). Det korrekta värdet beror på hur mycket minne GCDS-servern har och hur mycket minne GCDS behöver för en synkronisering. Du kan behöva ändra siffran flera gånger för att ställa in rätt storlek. Mer information om hur mycket fritt RAM-minne som krävs för att köra GCDS finns i Systemkrav för GCDS.

Felet kan bero på ett konfigurationsproblem, till exempel en felaktig konfiguration av uteslutningsregeln. 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 (exempelvis Google Workspace eller Cloud Identity) i maximalt åtta dagar. GCDS kan rensa cachen oftare, beroende på storleken på cachelagrad data. Om cachen inte har rensats ser du kanske inte dina uppdateringar i upp till åtta dagar.

Du synkroniserar exempelvis dina LDAP-data och skapar en ny grupp för Google-tjänsten (som Google Workspace eller Cloud Identity). Sedan skapar du en uteslutningsregel som exkluderar gruppen från påföljande synkroniseringar. Uteslutningsregeln är felaktigt konfigurerad och kommer att misslyckas. Vid den efterföljande synkroniseringen anropas däremot cachelagrad data och gruppen finns kvar i Google-tjänsten. När du synkar igen med rensad cache gör den felaktiga konfigurationen att gruppen tas bort från Google-tjänsten.

Så här rensar du cacheminnet manuellt:

• Kör en synkronisering från konfigurationshanteraren och välj alternativet för 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 cacheminnet.
• Ändra XML-konfigfilen och ställ in värdet för maxCacheLifetime på 0.

Viktigt! Om du tvingar fram en rensning av cachen kan de öka synkroniseringstiden markant.

Om du får felmeddelandet 409: Enheten finns redan eller ett felmeddelande om kontokonflikt försöker GCDS skapa en användare med en e-postadress som redan finns som ett ohanterat personligt konto, ett ohanterat arbetskonto eller en befintlig hanterad användare. Lös problemet genom att gå till Hantera konfliktkonton med GCDS och Lös fel med dubblettkonton. Om du inte ser felet i efterföljande synkroniseringar är det troligt att GCDS-cacheminnet var inaktuellt och att du kan ignorera felet.

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

• En exkluderingsregel för Google-användare är för bred – regeln matchar vissa Google-användare som även 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 leda till att GCDS ignorerar Google-användare som redan finns. Om dessa användare finns i resultaten av LDAP-användarsökregeln försöker GCDS skapa dem i Google-kontot.

Lös problemet genom att justera uteslutningsregeln eller sökfrågan. Om du vill att GCDS ska ignorera användarna i LDAP-katalogen helt kan du justera sökregeln för LDAP-användare eller skapa en uteslutningsregel för LDAP-användare. Mer information finns i Utesluta data med undantagsregler och frågor.

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

Det här är några möjliga anledningar:

• 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 LDAP-katalogen.
• Om du använder Global Catalog-servern (port 3268 eller 3269) och inte har markerat rutan Replikera det här attributet till Global Catalog i Active Directory-schemat hittas inte dina anpassade schemaattribut på Google Cloud-servern under synkroniseringen.

Prova följande steg för att se till att dina anpassade schemaattribut synkroniseras:

1. Samarbeta med LDAP-administratören för att säkerställa att användaren som har konfigurerats i GCDS för LDAP-autentisering har läsåtkomst till alla attribut som inte synkroniseras.
2. Använd samma dator som kör GCDS och använd en LDAP-webbläsare för att ansluta till LDAP-servern. När du ansluter ska du autentisera med samma användare som GCDS använder. Leta reda på 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 rensar du GCDS-cacheminnet och kör en synkronisering.

Om dina anpassade schemaattribut fortfarande inte synkroniseras samlar du in GCDS-informationen och kontaktar supporten. Mer information finns i Vilken GCDS-information behöver jag innan jag kontaktar supporten?

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

Om du vill synkronisera gruppmedlemmar baserat på enbart resultaten av användarsökregler tar du bort INDEPENDENT_GROUP_SYNC från XML-konfigurationsfilen. GCDS:

• Använder resultaten från reglerna för användarsökning för att matcha gruppmedlemskap
• Synkronisera enbart de användare som ingår i användarsynkroniseringen som gruppmedlemmar
• Kör regler för användarsökning, även om du inaktiverar synkronisering av användarkonton i Allmänna inställningar

  (Resultaten synkroniseras dock inte med Google som användare utan som gruppmedlemmar, om de kvalificerade användarna också är kvalificerade som gruppmedlemmar.)

Du vill vanligen inte att synkroniseringen ska köras så här, framför allt om du synkroniserar delade kontakter och har gruppmedlemmar som är kontakter. I så fall synkroniseras kontakterna inte som gruppmedlemmar.

Detta händer när LDAP-attributet som konfigurerats som gruppnamnattributet inte innehåller en fullständig e-postadress. Lös problemet genom att kontrollera gruppsökreglerna och se till att GCDS använder en fullständig e-postadress för gruppnamnen. Använd en av följande metoder:

• Ställ in gruppnamnattributet på ett annat LDAP-attribut som anger en fullständig e-postadress för varje grupp, till exempel mail.
• Aktivera Ersätt domännamn i e-postadresser för LDAP i Googled-domäninställningarna så att gruppnamnattributet matchar gruppnamnen på Googles sida.
• Lägg till domännamnet i gruppnamnet genom att ange ett gruppnamnssuffix i gruppsökregeln.

Kontrollera att du har valt MS Active Directory i servertypfältet för LDAP-konfiguration.

Detta alternativ (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 den tar GCDS bort domändelen från alla e-postadresser som läses.

All behandling sker utan domännamnet. Om du använder undantagsregler som bygger på e-postadresser så måste du använda enbart den lokala delen av e-postadressen för undantagsregeln.

Om du till exempel har inaktiverat Ersätt domännamnen i e-postadresserna för LDAP och skapar en uteslutningsregel för exakt matchning, anger du lukas@exempel.com som användarens e-postadress för matchning. Om du har aktiverat Ersätt domännamn i LDAP-e-postadresser använder du lukas. Det fungerar inte att matcha lukas@exempel.com eftersom @exempel.com tas bort före jämförelsen.

Vid administration av grupper med GCDS kan du inte kapsla dynamiska grupper under statiska grupper (eller statiska grupper under dynamiska grupper). GCDS kräver att sökningar görs separat mellan statiska grupper och dynamiska grupper, men alla kapslade grupper måste vara en del av samma fråga.

Hitta ett sätt att implementera dynamiska grupper som statiska grupper, eventuellt genom att automatisera en uppgift som med jämna mellanrum söker i varje dynamisk grupp för att fylla statiska grupper i katalogen. GCDS kan sedan använda de statiska grupperna (som skapas från dynamiska grupper) för administration och administrera de dynamiska grupperna.

Resultaten för LDAP-frågor beror på inställningarna för Konfigurationshanteraren och LDAP-servern. Använd dessa felsökningstips om LDAP-sökregeln returnerar ett oväntat resultat. Kontrollera följande:

• 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ända LDAP-sökregler för att synkronisera data.
• Flera sökfrågor motsäger inte varandra – kontrollera att du inte har skapat en sök- eller uteslutningsregel som ändrar resultatet av en sökfråga.
• Den auktoriserade användaren för LDAP-servern har tillräckliga behörigheter – se till att administratören som används för att autentisera LDAP-servern kan använda kommandoraden på samma server. Testa sökfrågan på LDAP-servern och verifiera resultaten.

Du kan stöta på felmeddelandet Det gick inte att skapa gruppen …. Message: Not Authorized to access this resource/api i GCDS-loggarna. 

Felsök genom att kontrollera att Active Directory-attributet (AD) som innehåller domänen för användar- och grupp-e-postadresser matchar domänen som ditt avancerade administratörskonto använder.

Problemet kan uppstå med Google Cloud Directory Sync (GCDS) i två situationer.

Situation 1: Du byter namn på en grupp-e-postadress i Microsoft Active Directory (AD) efter att gruppen har synkroniserats med Google Workspace. Efter en synkronisering raderar GCDS den aktuella gruppen och skapar en ny grupp med den nya e-postadressen.

Lösning 1: Ändra inte gruppens e-postadress i AD.

Lösning 2: Ändra gruppens e-postadress manuellt i både AD och Google Workspace så att de matchar.

Situation 2: Problemet uppstår när

1. Gruppens e-postadress innehåller specialtecken (till exempel !#$%&'*+/=?^_`).
2. Gruppen har synkroniserats med Google Workspace med en GCDS-version som är tidigare än 5.0.20.
3. Du uppgraderar GCDS till version 5.0.20 eller senare.
4. Efter en synkronisering försöker GCDS radera gruppen och skapa den igen med specialtecknen.

Lösning 1: Ta bort specialtecknen från AD-gruppens e-postadress.

Lösning 2: Lägg till specialtecknen i e-postadressen i Google Grupper.

Detta händer ofta om du synkroniserar delade kontakter och sökreglerna är felaktigt uppbyggda.

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

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

Läs detta genom att ändra dina sökregler för delade kontakter så att de utesluter användare på din egen domän. Vid nästa synkronisering görs ett försök att ta bort de överflödiga kontakterna i GCDS. Du kan behöva justera borttagningsgränsen för delade kontakter för denna första synkronisering.

I vissa fall ser användarna inte sin huvudarbetsplats i Google Kalender när de planerar eller bokar möten.

Om du ser det här problemet kontrollerar du att platstypen och områdesattributen är inställda på ”skrivbord”.

Kontrollera följande om du har problem med sökresultaten: 

• Regelns omfattning. Du kan behöva ställa in omfattningen på Underträd.
• Sökregeln som du använder är korrekt.
• Attributen som används finns och är synliga.
• Din LDAP-sökfråga. Verifiera att sökfrågan på LDAP-servern använder administratörsanvändarnamnet som har konfigurerats i GCDS.

Mer information finns i Använda LDAP-sökregler för att synkronisera data.

Du kanske använder en font som är för stor för skärmen. Dialogrutan fungerar inte med stora eller extra stora tecken. Ändra din teckenstorlek eller redigera XML-filen direkt.

Om sökningen bara importerar 1 000 tillgängliga användare (eller standardstorleken för LDAP-sidan) kan inställningen för LDAP-värdnamn i konfigurationshanteraren 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 konfigurationshanteraren så att inställningen Värdnamn matchar inställningen Bas-DN. Du kan även använda en domänkontrollant (till exempel dc01.example.com) som innehåller användarkontoobjekten i bas-DN.