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

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

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

במקרים נדירים, צוות התמיכה עשוי לבקש מכם להפעיל רישום מלא של 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, אין צורך לשכפל את כל בלוק ההגדרה.

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

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

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

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

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

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

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

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

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

   nslookup smtp-host-name.com

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

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

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

   telnet smtp.gmail.com 587

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

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

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

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

אם נתוני ה-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.

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

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

תיאור: הבעיה מתרחשת בגרסה 5.0.22 של Google Cloud Directory Sync‏ (GCDS) כשמבצעים את השלבים הבאים:

1. באשף ההגדרות, לוחצים על דומיין של Google ואז על כללי החרגה של הגדרות.
2. בשדה Users Search Query (שאילתת חיפוש משתמשים), מזינים שאילתת חיפוש של משתמש ושומרים את קובץ התצורה.
3. מוחקים את אותה שאילתה ושומרים את קובץ ההגדרות.
4. משווים את קובץ התצורה בשלב 2 לקובץ בשלב 3.

   קובץ התצורה זהה. השאילתה שנמחקה לא נשמרה בקובץ.

פתרון עקיף: פותחים את קובץ ההגדרות ומוחקים באופן ידני את ההגדרה .

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

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

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

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

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

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

1. סקירה כללית של הפניית Admin SDK API
2. בצד ימין, לוחצים על Directory API ואז, בקטע REST Resources, עוברים אל משאב ה-REST שרוצים לשלוח לו שאילתה.
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 (אישור ממשקי API).
4. מזינים את פרטי הכניסה של האדמין שבהם השתמשתם כדי לתת הרשאה ל-GCDS.

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

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

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

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

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

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

תיאור: הבעיה מתרחשת ב-Google Cloud Directory Sync‏ (GCDS). אם משנים את כתובת האימייל הראשית של משתמש בשרת LDAP, השינוי לא נלקח בחשבון כש-GCDS מסנכרן את הרישיון של המשתמש. ‫GCDS מנסה להוסיף את הרישיון למשתמש ששמו שונה ומופיעה שגיאה 412.

תיאור: מערכת Google Cloud Directory Sync‏ (GCDS) משתמשת במזהה ייחודי כדי לקשר בין משתמשים ב-Google Workspace לבין הספרייה החיצונית שלכם. למשתמשים ב-Microsoft Active Directory יש מזהה ObjectGUID, ולמשתמשים ב-Microsoft Azure Active Directory יש מזהה אובייקט.

אם יוצרים מחדש משתמש בספרייה החיצונית, הוא מקבל מזהה ObjectGUID או מזהה אובייקט מקורי. אבל מכיוון שכתובת האימייל של המשתמש החדש כבר מקושרת למשתמש שנמחק ב-Workspace, הסינכרון נכשל.

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

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

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

אם מופיעות שגיאות שקשורות לזיכרון, צריך להגדיל את גודל הערימה של מכונת Java הווירטואלית. כדי להגדיל את גודל הערימה, עורכים את הקבצים 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 פועל.

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

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

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

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

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

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

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

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

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

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

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

סיבות אפשריות:

• למשתמש המורשה של שרת ה-LDAP, שהוגדר ב-Google Cloud Directory Sync ‏ (GCDS), אין גישת קריאה למאפיינים הספציפיים האלה בספריית ה-LDAP.
• אם אתם משתמשים בשרת Global Catalog (יציאה 3268 או 3269) ולא סימנתם את התיבה Replicate this attribute to the Global Catalog (שכפול המאפיין הזה בקטלוג הגלובלי) מסכימת Active Directory, מאפייני הסכימה המותאמת אישית לא יימצאו בשרת Google Cloud במהלך הסנכרון.

כדי לוודא שמאפייני הסכימה המותאמת אישית מסתנכרנים, נסו לבצע את הפעולות הבאות:

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

אם המאפיינים של הסכימה המותאמת אישית עדיין לא מסתנכרנים, כדאי לאסוף את פרטי GCDS ולפנות לתמיכה. פרטים מופיעים במאמר איזה מידע ב-GCDS נדרש כדי לפנות לתמיכה?

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

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

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

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

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

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

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

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

משתמשים באפשרות הזו (שמוצגת כ-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 ומאמתים את התוצאות.

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

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

הבעיה יכולה להתרחש ב-Google Cloud Directory Sync ‏ (GCDS) בשני מצבים.

תרחיש 1: שיניתם את השם של כתובת האימייל של קבוצה ב-Microsoft Active Directory (AD) אחרי שהקבוצה סונכרנה עם Google Workspace. אחרי הסנכרון, GCDS מוחק את הקבוצה הנוכחית ויוצר קבוצה חדשה עם כתובת האימייל החדשה.

פתרון עקיף 1: לא משנים את כתובת האימייל הקבוצתית ב-AD.

פתרון עקיף 2: משנים באופן ידני את כתובת האימייל הקבוצתית גם ב-AD וגם ב-Google Workspace כך שהן יהיו זהות.

מצב 2: הבעיה מתרחשת כשהתנאים הבאים מתקיימים:

1. כתובת אימייל קבוצתית מכילה תווים מיוחדים (כמו !#$%&'*+/=?^_`).
2. הקבוצה סונכרנה עם Google Workspace באמצעות גרסה של GCDS שקודמת לגרסה 5.0.20.
3. משדרגים את GCDS לגרסה 5.0.20 ואילך.
4. אחרי הסנכרון, GCDS מנסה למחוק את הקבוצה וליצור אותה מחדש באמצעות התווים המיוחדים.

פתרון עקיף 1: מסירים את התווים המיוחדים מכתובת האימייל הקבוצתית של קבוצת המשתמשים ב-AD.

פתרון עקיף 2: מוסיפים את התווים המיוחדים לכתובת האימייל בקבוצות Google.

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

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

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

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

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

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

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

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

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

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

אם החיפוש מייבא רק 1,000 משתמשים זמינים (או את גודל הדף שמוגדר כברירת מחדל ב-LDAP), יכול להיות שההגדרה של שם המארח ב-LDAP באשף ההגדרות מוגדרת לדומיין כללי או לדומיין בסיסי של יער שמנפיק הפניות לאובייקטים ב-DN הבסיסי.

כדי לפתור את הבעיה, צריך לעדכן את אשף ההגדרות כך שההגדרה של שם המארח תהיה זהה להגדרה של ה-Base DN. לחלופין, אפשר להשתמש בבקר דומיין (לדוגמה, dc01.example.com) שמכיל את אובייקטים של חשבונות משתמשים ב-Base DN.