פתרון בעיות נפוצות ב-GCDS

פתרון בעיות בהגדרה באמצעות Configuration Manager

אם נתקלתם בבעיה בהרצת סנכרון, ודאו שפרטי ההגדרה נכונים ב-Configuration Manager וציינו אילו בדיקות נכשלו:

1. בConfiguration Manager, פותחים את קובץ ה-XML שבו משתמשים כדי להגדיר את הסנכרון.
2. בדף LDAP Connections (חיבורי LDAP), לוחצים על Test Connections (בדיקת חיבורים) כדי לוודא שאפשר להתחבר לשרת ה-LDAP.
3. בדף התראות, לוחצים על התראה לבדיקה כדי לוודא שאפשר לשלוח התראה לבדיקה.
4. בדף סנכרון, לוחצים על סימולציית סנכרון כדי לוודא שמילאתם את כל השדות הנדרשים ושהסנכרון פועל.

איך מפעילים רישום מלא ביומן של בקשות API מסוג HTTP?

במקרים נדירים, צוות התמיכה עשוי לבקש מכם להפעיל רישום מלא של HTTP בנוסף להפעלת רישום ברמת מעקב ב-GCDS. רישום מלא ביומן של HTTP משמש כדי לראות את בקשת ה-API המדויקת שבוצעה על ידי GCDS ואת התגובה שסופקה על ידי Google APIs.

חשוב: יומני HTTP מלאים יכולים להכיל מידע רגיש מאוד. לפני ששולחים את היומנים לתמיכה, צריך להסיר מהם מידע רגיש (כמו השדות refresh_token או access_token הנוכחיים).

כדי להפעיל רישום מלא ביומן של HTTP:

1. מוודאים ש-GCDS לא פועל עם sync-cmd או עם אשף ההגדרות.
2. עוברים לתיקיית ההתקנה של GCDS.

3. עורכים את הקובץ jre/lib/logging.properties.

4. מוסיפים את השורות הבאות לסוף הקובץ:

   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. שומרים את הקובץ.
6. מריצים סנכרון נוסף של GCDS (כשהרישום ביומן מוגדר לTrace).

   קבצי יומן בשם gcdshttp*.log נוצרים ב-homedir‏ (Linux) או בתיקיית הפרופיל (Microsoft Windows). כדאי לארכב את הקבצים האלה יחד, כי הם יכולים להיות גדולים מאוד.

7. כדי למנוע יצירה של קובצי יומן גדולים בעתיד, מוחקים את השורות שנוספו בשלב 4.
8. עליך לספק את הקבצים הבאים לתמיכה:
   • קובץ XML
   • יומנים ברמת מעקב וקבצים gcdshttp*.log מהסנכרון האחרון

טיפ: אם רוצים להפעיל רישום ביומן עבור מחלקה חדשה, מוסיפים שורה בתבנית class.fqdn.level = ALL, אין צורך לשכפל את כל בלוק ההגדרה.

שימוש ב-Proxy לניפוי באגים

גודל הגוף של הבקשה והתגובה מוגבל ל-16KB כל אחד. אם אתם רואים רשומה ביומן שנחתכה כי היא חורגת מהמגבלה הזו, אתם יכולים להשתמש בשרת proxy לניפוי באגים, כמו Fiddler.

כדי להפעיל את Fiddler, פועלים לפי השלבים הבאים:

1. עוברים לנתיב שבו GCDS מותקן, למשל, C:\Program Files\Google Cloud Directory Sync.
2. כדי להשבית את בדיקות ה-CRL, מוסיפים את הדגלים הבאים לקבצים .vmoptions (לדוגמה, config-manager.vmoptions או sync-cmd.vmoptions):

   -Dcom.sun.security.enableCRLDP=false

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

מפעילים מחדש את GCDS כדי שהשינויים ייכנסו לתוקף.

1. מגדירים את Fiddler כשרת proxy בהגדרות ה-proxy של תצורת הדומיין ב-Google. בשדה של שם המארח, מוסיפים את כתובת ה-IP המקומית 127.0.0.1. יציאת ברירת המחדל היא 8888, אבל אפשר לוודא זאת על ידי פתיחת Fiddler, מעבר אל Options (אפשרויות) > Connections (חיבורים) ובדיקת הערך בשדה Fiddler Classiclistens on port (יציאת ההאזנה של Fiddler Classic).

אם אתם משתמשים ב-GCDS ב-Linux, אתם לא יכולים להשתמש במאגר האישורים המהימנים של Windows, ולכן אתם צריכים לייבא את אישור הבסיס של Fiddler למאגר האישורים של Java ב-GCDS. פרטים נוספים על השלבים האלה זמינים במאמר בנושא פתרון בעיות שקשורות לאישורים.

בעיה בהגדרת מארח שרת ה-SMTP

אם נתקלתם בבעיות בהגדרת שרת ה-SMTP להעברת ההתראות, נסו את הפתרונות הבאים:

הודעה על כשל בחיבור ומארח SMTP לא ידוע

1. פותחים שורת פקודה.
2. כדי לבדוק אם שם המארח המוגדר של שרת ה-SMTP מפנה לכתובת IP, מזינים את הפקודה הבאה:

   nslookup smtp-host-name.com

החיבור נכשל ולא ניתן להתחבר להודעת מארח SMTP

בודקים אם השרת שמריץ את GCDS יכול להתחבר למארח SMTP.

1. כדי לבדוק את החיבור, מזינים את הפקודה הבאה בשורת הפקודה או בטרמינל של Windows:

   telnet smtp.gmail.com 587

2. אם המארח לא מצליח להתחבר, צריך לבדוק את כללי חומת האש של שרת ה-SMTP לדואר נכנס ואת כללי חומת האש של שרת GCDS לדואר יוצא.
3. חשוב לוודא שאפשרתם תנועה ביציאת SMTP.

השגיאה 'לא ניתן להמיר את השקע ל-TLS' ביומנים

משביתים את הבדיקות של רשימת האישורים שבוטלו (CRL). פרטים נוספים זמינים במאמר איך רשימות אישורים שבוטלו נבדקות ב-GCDS.

איך פותחים קובץ XML ששמור במחשב אחר או ששמור בתור משתמש אחר?

הוראות לפתיחת קובץ XML שנשמר במחשב אחר או על ידי משתמש אחר באותו מחשב מופיעות במאמר בנושא עבודה עם קובצי תצורה.

איך מייצאים נתונים ממאגר LDAP?

אם נתוני ה-LDAP ביומנים ברמת המעקב של GCDS לא תואמים למה שאתם מצפים לקרוא בשרת ה-LDAP (לדוגמה, משתמש לא נמצא או שלמאפיין אין את הערך הנכון), מייצאים את הנתונים ממדריך ה-LDAP בפורמט LDIF. צוות התמיכה יכול להשוות את הנתונים לנתוני ה-LDAP מיומני GCDS.

כשמייצאים את הנתונים, צריך להשתמש בכלי לשאילתות LDAP כמו ldapsearch (Linux) או ldifde (Windows) ולדמות את אותם התנאים שבהם GCDS פועל:

• משתמשים באותן הגדרות חיבור שמוגדרות ב-GCDS.
• מריצים את כלי השאילתות מאותה מכונה שבה פועל GCDS.
• משתמשים באותו שם משתמש לאימות LDAP ב-GCDS.

דוגמה

בלוגים של GCDS לא מופיע מאפיין האימייל של המשתמשים, וההגדרות של כלל החיפוש ב-GCDS הן:

• Base DN: ou=Ireland,dc=altostrat,dc=com
• היקף: Subtree
• מסנן חיפוש: (&(objectCategory=person)(objectClass=user))
• שרת: dc01.altostrat.com
• יציאה: 636
• פרוטוקול: LDAP+SSL
• DN של משתמש האימות: cn=GCDS,ou=Users,dc=altostrat,dc=com

משתמשים בפקודות האלה:

• ‫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 (יכול להיות שתצטרכו לשנות את הפקודה בהתאם למערכת שלכם).
• ‫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 (מחליפים את PASSWORD בסיסמה של משתמש LDAP שהוגדר ב-GCDS).

אם הפלט (out.ldif) לא מכיל את המאפיין mail של משתמש מושפע, יש בעיה בתשתית ה-LDAP. יכול להיות שהבעיה קשורה להרשאות של המשתמש שמשמש אותך לגישה ל-LDAP (לדוגמה, גם OpenLDAP וגם Active Directory מאפשרים להגדיר הרשאות ברמת המאפיין). או שהמאפיין לא משוכפל לקטלוג הגלובלי, אם משתמשים ביציאה של קטלוג גלובלי כמו 3268 או 3269.

אם הפלט מכיל את המאפיין mail של משתמש מושפע, צריך לספק את הפרטים הבאים לתמיכה של Google Workspace:

• הקובץ out.ldif
• צילום מסך של חלון שורת הפקודה או המסוף שבו הפעלתם את הפקודה
  (חשוב להסיר קודם את הסיסמה).
• היומן ברמת המעקב של GCDS

האם צריך שרת התראות כדי להריץ סנכרון מדומה?

כדי להריץ סימולציה של סנכרון, צריך שרת שיכול לשלוח אימייל. אם אתם מפעילים את GCDS במכונה של שרת אימייל, אתם יכולים להשתמש בכתובת ה-IP ‏127.0.0.1 עבור שרת האימייל. אפשרות נוספת היא לפנות לאדמין של האימייל כדי לקבל את פרטי האימייל הנכונים.

למה GCDS לא מריץ סנכרון משורת הפקודה?

אם אתם משתמשים בשורת הפקודה כדי להריץ סנכרון והסנכרון לא מתחיל, בדקו אם השתמשתם בארגומנט -o או --oneinstance בשורת הפקודה.

אם משתמשים באחד מהארגומנטים האלה, GCDS יוצר קובץ נעילה (‎.lock) שמשויך לקובץ התצורה של ה-XML. בנוסף, אם נמצא קובץ LOCK נוסף באותו השרת, GCDS לא יריץ את הסנכרון כדי למנוע הפעלה של כמה מופעים של GCDS בו-זמנית.

אם אין מופע אחר של GCDS שפועל, צריך לבדוק אם יש קובץ LOCK אחר בשרת. צריך למחוק את הקובץ באופן ידני ולנסות להריץ שוב את הסנכרון.

הסנכרון שלי לא הושלם. יכול להיות שזו בעיה ב-API?

אם הסנכרון לא הושלם, למשל אם החברות המלאה בקבוצה לא סונכרנה, יכול להיות שיש בעיה ב-Directory API. כדי לבדוק אם הבעיה קשורה ל-API ולא למוצר GCDS, צריך לבצע קריאה ידנית ל-Directory API ולבדוק את התוצאות. כדי לשלוח קריאה ל-API באופן ידני, אפשר לבחור באחת משתי אפשרויות.

אפשרות 1: שימוש בדף ההפניה של ה-API

1. סקירה כללית של הפניית Admin SDK API
2. בצד ימין, לוחצים על Directory API. בקטע REST Resources, עוברים אל REST Resource שרוצים לשלוח לו שאילתה.
3. בצד שמאל, לוחצים על השיטה שרוצים לנסות ואז על רוצה לנסות?.

   אם האפשרות Try it לא מופיעה בדף ההפניה של ה-API, עוברים לאפשרות 2: שימוש ב-OAuth 2.0 Playground.

4. מזינים את פרטי הכניסה של האדמין ששימשו לאישור GCDS.

   פרטים נוספים זמינים במאמר הגדרת הדומיין של Google.

5. בודקים את המידע כדי לוודא שהתגובה של ה-API הייתה צפויה.

אפשרות 2: שימוש ב-OAuth 2.0 Playground

1. פותחים את OAuth 2.0 Playground.
2. בוחרים אפשרות:
   • בוחרים היקף מהרשימה.
   • מעתיקים היקף מהרשימה Authorization scopes (היקפי הרשאה) בדף ההפניה ל-API. לאחר מכן מדביקים את ההיקף בשדה Input your own scopes (הזנת היקפים משלכם).
3. לוחצים על Authorize APIs.
4. מזינים את פרטי הכניסה של האדמין ששימשו לאישור GCDS.

   פרטים נוספים זמינים במאמר הגדרת הדומיין של Google.

5. לוחצים על Exchange authorization code for tokens (החלפת קוד הרשאה באסימונים).

   אם התהליך יסתיים בהצלחה, תופנו אל שלב 3: הגדרת הבקשה ל-API.

6. ממלאים את הפרטים הנדרשים.

   טיפ: רוב המידע זמין בדף האינטרנט של הפניית השיטה של API.

7. לוחצים על שליחת הבקשה.
8. בודקים את המידע כדי לוודא שהתגובה של ה-API הייתה צפויה.

מה גורם לשגיאות או לקונפליקטים מסוג EntityDoesNotExist או EntityExists?

בקובץ ההגדרות בפורמט XML, מגדירים את האפשרות useDynamicMaxCacheLifetime. האפשרות הזו מגדירה את GCDS לשמירת נתונים במטמון למשך 8 ימים לכל היותר, ולניקוי המטמון בתדירות גבוהה יותר בקבוצות נתונים קטנות עד בינוניות, כדי לצמצם את הסיכוי שהנתונים במטמון יהיו ישנים או יתנגשו עם נתונים חדשים. האפשרות useDynamicMaxCacheLifetime מופעלת אוטומטית בהגדרות שנוצרו באמצעות GCDS מגרסה 3.2.1 ומעלה.

הערה: השגיאות האלה מתרחשות בדרך כלל כשמבצעים שינויים ישירות בדומיין שלכם ב-Google. כשמשתמשים ב-GCDS לסנכרון, לא מומלץ לבצע שינויים ישירות בדומיין Google. במקום זאת, מבצעים שינויים במשתמשים, בקבוצות ובגורמים אחרים בספריית ה-LDAP. לאחר מכן, משתמשים ב-GCDS כדי לסנכרן את השינויים האלה עם דומיין Google.

איך אפשר לפתור בעיות שקשורות לזיכרון?

אם מופיעות שגיאות שקשורות לזיכרון, צריך להגדיל את גודל הערימה של מכונת Java הווירטואלית. כדי להגדיל את גודל ה-heap, עורכים את הקבצים sync-cmd.vmoptions ו-config-manager.vmoptions בספריית ההתקנה של GCDS. הערכים הרלוונטיים נראים כך:

• ‫-Xmx1000m (הכמות המקסימלית של הזיכרון שהוקצה לגודל הערימה)
• ‫-Xms64m (הכמות המינימלית של הזיכרון שהוקצה לגודל הערימה)

עורכים את הקבצים sync-cmd.vmoptions ו-config-manager.vmoptions כדי שהשינוי יחול על הגרסאות של sync-cmd ושל Configuration Manager.

עורכים את המספר -Xmx כדי להגדיל את נפח הזיכרון. האות m אחרי המספר מציינת שהזיכרון נמדד במגה-בייט (MB). כמות הזיכרון הנכונה תלויה בכמות הזיכרון שיש לשרת GCDS ובכמות הזיכרון שהוא צריך לסינכרון. יכול להיות שתצטרכו לשנות את המספר כמה פעמים כדי להגדיר את הגודל הנכון. מידע נוסף על כמות ה-RAM החופשי שנדרשת להפעלת GCDS זמין במאמר דרישות המערכת של GCDS.

למה GCDS ממשיך להחזיר שגיאה כשהמטמון מושבת?

יכול להיות שהבעיה נובעת מבעיה בהגדרות, למשל הגדרה שגויה של כלל החרגה. יכול להיות שהגדרות שגויות מהסוג הזה לא יופיעו בגלל שמנגנון ה-Caching של GCDS.

‫GCDS שומר במטמון נתונים של שירות Google (כמו Google Workspace או Cloud Identity) למשך 8 ימים לכל היותר. יכול להיות ש-GCDS ינקה את המטמון בתדירות גבוהה יותר, בהתאם לגודל הנתונים שנשמרו במטמון. עם זאת, אם המטמון לא נמחק, יכול להיות שהעדכונים לא יוצגו במשך עד 8 ימים.

לדוגמה, אתם מסנכרנים את נתוני ה-LDAP ויוצרים קבוצה חדשה בשירות Google (כמו Google Workspace או Cloud Identity). לאחר מכן יוצרים כלל החרגה כדי להחריג את הקבוצה הזו מסנכרונים עתידיים. כלל ההחרגה מוגדר באופן שגוי והוא ייכשל. עם זאת, קריאות הסנכרון הבאות של נתונים שנשמרו במטמון והקבוצה יישארו בשירות Google. כשמסנכרנים שוב עם מטמון נקי, ההגדרה השגויה גורמת להסרת הקבוצה משירות Google.

כדי לנקות את המטמון באופן ידני:

• מריצים סנכרון מ-Configuration Manager ובוחרים באפשרות לניקוי המטמון במהלך הסנכרון.
• מריצים סנכרון מהפקודה ומשתמשים בארגומנט -f כדי לכפות ניקוי של המטמון.
• משנים את קובץ התצורה של ה-XML כדי להגדיר את הערך של maxCacheLifetime כ-0.

חשוב: אם תכריחו את המערכת לנקות את המטמון, יכול להיות שזמן הסנכרון יתארך משמעותית.

למה GCDS מנסה ליצור משתמשי Google שכבר קיימים?

אם מופיעה השגיאה 409: הישות כבר קיימת, מערכת GCDS מנסה ליצור משתמשי Google שכבר קיימים. אם השגיאה לא מופיעה בסנכרונים הבאים, סביר להניח שהמטמון של GCDS היה לא עדכני, ואפשר להתעלם מהשגיאה.

אם הבעיה מתרחשת בכל סנכרון או אחת לכמה ימים, הסיבות הסבירות ביותר הן:

• כלל החרגה של משתמש Google רחב מדי – הכלל תואם לחלק ממשתמשי Google שקיימים גם במדריך ה-LDAP.
• השאילתה מצומצמת מדי – השאילתה לא תואמת לחלק מהמשתמשים ב-Google שקיימים גם במדריך ה-LDAP.

בשני המקרים, יכול להיות ש-GCDS יתעלם ממשתמשי Google שכבר קיימים. אם המשתמשים האלה קיימים בתוצאות של כלל חיפוש המשתמשים ב-LDAP, מערכת GCDS מנסה ליצור אותם בחשבון Google שלכם.

כדי לפתור את הבעיה, צריך לשנות את כלל ההחרגה או את שאילתת החיפוש. לחלופין, אם רוצים שמערכת GCDS תתעלם לחלוטין מהמשתמשים בספריית ה-LDAP, צריך לשנות את כלל חיפוש המשתמשים ב-LDAP או ליצור כלל החרגה של משתמשים ב-LDAP. פרטים נוספים זמינים במאמר בנושא השמטת נתונים באמצעות כללי החרגה ושאילתות.

למה חלק מהמשתמשים לא מסונכרנים כחברים בקבוצה?

כדי לסנכרן את חברי הקבוצה בנפרד מתוצאות של כל כלל חיפוש משתמשים, GCDS מפעיל את INDEPENDENT_GROUP_SYNC כברירת מחדל. אם אתם משתמשים במאפייני הפניה לחברים לסנכרון קבוצות, מערכת GCDS מנסה לזהות את כתובת האימייל של כל משתמש בספריית ה-LDAP, ללא קשר לכללי חיפוש המשתמשים.

כדי לסנכרן חברים בקבוצה רק על סמך התוצאות של כללי חיפוש המשתמשים, צריך להסיר את INDEPENDENT_GROUP_SYNC מקובץ ה-XML של התצורה. GCDS:

• משתמש בתוצאות של כללי החיפוש של המשתמשים כדי לקבוע את החברות בקבוצה
• רק משתמשים שכלולים בסנכרון המשתמשים שלכם מסונכרנים כחברים בקבוצה
• מבצע כללי חיפוש משתמשים, גם אם משביתים את סנכרון חשבונות המשתמשים בהגדרות כלליות

  (עם זאת, התוצאות לא מסונכרנות עם Google כמשתמשים אלא כחברים בקבוצה, אם המשתמשים שעומדים בדרישות הם גם חברים בקבוצה).

בדרך כלל, לא כדאי להגדיר את הסנכרון בצורה הזו, במיוחד אם אתם מסנכרנים אנשי קשר משותפים ויש לכם חברים בקבוצה שהם אנשי קשר. במקרה כזה, אנשי הקשר לא יסונכרנו כחברים בקבוצה.

למה חלק מהמשתמשים או הקבוצות נוצרים מחדש בכל סנכרון?

הבעיה הזו מתרחשת כשמאפיין ה-LDAP שהוגדר כמאפיין שם הקבוצה לא מכיל כתובת אימייל מלאה. כדי לפתור את הבעיה, צריך לבדוק את כללי החיפוש של הקבוצה ולוודא ש-GCDS משתמש בכתובת אימייל מלאה לשמות הקבוצות. אפשר להשתמש באחת מהשיטות הבאות:

• מגדירים את מאפיין שם הקבוצה למאפיין LDAP אחר שמציין כתובת אימייל מלאה לכל קבוצה, כמו mail.
• מפעילים את האפשרות החלפת שמות הדומיין בכתובות אימייל של LDAP בהגדרות הדומיין של Google, כדי שמאפיין שם הקבוצה יתאים לשמות הקבוצות בצד של Google.
• מוסיפים את שם הדומיין לשם הקבוצה על ידי ציון סיומת לשם הקבוצה בכלל החיפוש של הקבוצה.

קבוצות עם יותר מ-1,500 חברים ב-Active Directory לא מסתנכרנות בצורה נכונה

מוודאים שבחרתם באפשרות MS Active Directory בשדה של סוג השרת בקטע LDAP Configuration.

איך משתמשים באפשרות 'החלפת שמות הדומיין בכתובות אימייל של LDAP'?

משתמשים באפשרות הזו (שמוצגת כ-SUPPRESS_DOMAIN בקובץ ה-XML) אם כתובות האימייל בספריית ה-LDAP נמצאות בדומיין שונה מהדומיין שלכם ב-Google. כשמפעילים את האפשרות הזו, GCDS מסיר את החלק של הדומיין מכל כתובות האימייל שהוא קורא.

העיבוד מתבצע ללא שם הדומיין. אם אתם משתמשים בכללי החרגה שמבוססים על כתובות אימייל, אתם צריכים להתייחס רק לחלק המקומי של כתובת האימייל בכלל ההחרגה.

לדוגמה, אם האפשרות החלפת שמות הדומיין בכתובות אימייל של LDAP מושבתת ואתם יוצרים כלל החרגה של התאמה מדויקת, צריך להזין את כתובת האימייל של המשתמש luka@example.com כדי שתהיה התאמה. אם הפעלתם את האפשרות החלפת שמות הדומיין בכתובות אימייל של LDAP, השתמשו ב-luka. ניסיון להתאים את luka@example.com לא יצליח, כי @example.com מוסר לפני ההשוואה.

האם אפשר להשתמש בקבוצות סטטיות ודינמיות בתוך קבוצות אחרות?

כשמקצים קבוצות באמצעות GCDS, אי אפשר להוסיף קבוצות דינמיות כקבוצות משנה של קבוצות סטטיות (או קבוצות סטטיות כקבוצות משנה של קבוצות דינמיות). כדי להשתמש ב-GCDS, צריך להריץ שאילתה על קבוצות סטטיות בנפרד מקבוצות דינמיות. עם זאת, כל הקבוצות המקוננות צריכות להיות חלק מאותה שאילתה.

אפשר להטמיע קבוצות דינמיות כקבוצות סטטיות, אולי באמצעות אוטומציה של משימה שמבצעת שאילתה תקופתית בכל קבוצה דינמית כדי לאכלס קבוצות סטטיות בספרייה. לאחר מכן, GCDS יכול להשתמש בקבוצות הסטטיות (כפי שנוצרו מהקבוצות הדינמיות) להקצאת הרשאות, ולא להקצות הרשאות לקבוצה הדינמית.

למה קיבלתי תוצאות לא צפויות משאילתת ה-LDAP שלי?

התוצאות של שאילתות LDAP תלויות בהגדרות של אשף ההגדרות ובשרת ה-LDAP. אם כלל החיפוש של LDAP מחזיר תוצאה לא צפויה, כדאי לנסות את הטיפים האלה לפתרון בעיות. ודא כי:

• השאילתה של LDAP מוגדרת בצורה נכונה באשף ההגדרות – כשמגדירים כלל חיפוש, לוחצים על בדיקת שאילתת LDAP כדי לוודא שהיא מוגדרת בצורה נכונה. פרטים נוספים זמינים במאמר בנושא שימוש בכללי חיפוש LDAP לסנכרון נתונים.
• כמה שאילתות לא סותרות זו את זו – בדקו שלא הגדרתם כלל חיפוש או כלל החרגה שמשנה את התוצאה של שאילתה.
• למשתמש המורשה בשרת ה-LDAP יש הרשאות מספיקות – מוודאים שהאדמין שמשמש לאימות שרת ה-LDAP יכול להשתמש בשורת הפקודה באותו שרת. מנסים להריץ את השאילתה בשרת ה-LDAP ומאמתים את התוצאות.

שגיאה: לא ניתן ליצור את הקבוצה

יכול להיות שתופיע הודעת השגיאה לא ניתן ליצור את הקבוצה [שם הקבוצה]. הודעה: אין לך הרשאה לגשת למשאב או ל-API הזה ביומני GCDS.

כדי לפתור את הבעיה, בודקים שהמאפיין Active Directory ‏ (AD) שמכיל את הדומיין של כתובות האימייל של המשתמשים והקבוצות תואם לדומיין שבו משתמש חשבון הסופר-אדמין.

למה יש כפילויות של אנשי קשר בספריית הדומיין שלי אחרי סנכרון עם GCDS?

הבעיה הזו בדרך כלל מתרחשת אם אתם מסנכרנים אנשי קשר משותפים וכללי החיפוש לא מוגדרים בצורה נכונה.

יש 2 סוגים של אובייקטים רלוונטיים שאפשר לסנכרן עם GCDS:

• פרופילים של משתמשים – משתמשים בדומיין Google שלכם עם נתונים נוספים כמו מספר טלפון או כתובת. אפשר לסנכרן פרופיל רק של משתמש שקיים בדומיין.
• אנשי קשר משותפים – אנשי קשר של גורמים חיצוניים שהמשתמשים בדומיין שלכם צריכים ליצור איתם קשר.

כדי לפתור את הבעיה, צריך לתקן את כללי החיפוש של אנשי הקשר המשותפים כדי להחריג משתמשים בדומיין שלכם. בסנכרון הבא, GCDS ינסה למחוק את אנשי הקשר המיותרים. יכול להיות שתצטרכו לשנות את מגבלת המחיקה של אנשי הקשר המשותפים בסנכרון הראשון.

למה חלק מהמשתמשים לא רואים את מיקום העבודה הראשי שלהם ביומן Google?

במקרים מסוימים, משתמשים לא רואים את מיקום העבודה העיקרי שלהם ביומן Google כשהם קובעים או מארגנים פגישות.

אם הבעיה הזו מופיעה, צריך לוודא שמאפייני סוג המיקום והאזור מוגדרים כ'שולחן'.

למה כלל חיפוש לא מוצא כלום?

אם נתקלתם בבעיות בתוצאות החיפוש, כדאי לבדוק:

• היקף הכלל. יכול להיות שתצטרכו להגדיר את ההיקף לעץ משנה.
• כלל החיפוש שבו אתם משתמשים נכון.
• המאפיינים שבהם נעשה שימוש קיימים וגלויים.

שאילתת ה-LDAP. מוודאים שהשאילתה בשרת ה-LDAP משתמשת באותו שם משתמש של אדמין שהוגדר ב-GCDS.

פרטים נוספים זמינים במאמר בנושא שימוש בכללי חיפוש LDAP לסנכרון נתונים.

למה אני לא רואה את הלחצן 'אישור' כשאני יוצר כלל חריג?

יכול להיות שאתם משתמשים בגופן גדול מדי למסך. תיבת הדו-שיח לא פועלת עם גופנים גדולים או גדולים במיוחד. לשנות את גודל הגופן או לערוך ישירות את קובץ ה-XML.