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

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

1. ב-Configuration Manager, פותחים את קובץ ה-XML שמשמש להגדרת הסנכרון.
2. בדף חיבורי LDAP, לוחצים על בדיקת חיבורים כדי לוודא שאפשר להתחבר לשרת ה-LDAP.
3. בדף Notifications, לוחצים על Test Notification כדי לוודא שאפשר לשלוח התראת בדיקה.
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, אין צורך לשכפל את כל בלוק ההגדרה.

גוף הבקשה וגוף התגובה שמתועדים ביומן מוגבלים לגודל של 16KB כל אחד. אם אתם רואים רשומת יומן שנקטעה כי היא חורגת מהמגבלה, השתמשו בשרת 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. אם המארח לא מצליח להתחבר, צריך לבדוק את כללי חומת האש של תעבורת הנתונים הנכנסת של שרת ה-SMTP ואת כללי חומת האש של תעבורת הנתונים היוצאת של שרת 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 לא מופיע המאפיין mail של המשתמשים, והגדרות כללי החיפוש ב-GCDS הן:

• ‫Base DN: ou=Ireland,dc=altostrat,dc=com
• היקף: עץ משנה
• מסנן חיפוש: (&(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 ברמת המעקב

תיאור: הבעיה מופיעה בגרסה 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 (‎.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. בצד שמאל, לוחצים על השיטה שרוצים לנסות ואז על רוצה לנסות?.

   אם בדף מאמרי העזרה של ה-API לא מופיעה האפשרות Try it, עוברים לאפשרות השנייה: שימוש ב-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 היא כמו שציפיתם.

תיאור: הבעיה קשורה ל-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.

אם מוצגות שגיאות שקשורות לזיכרון, צריך להגדיל את ה-heap size של Java Virtual Machine. כדי להגדיל את ה-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.

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

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

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

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

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

אם מופיעה השגיאה 409: Entity already exists או שגיאה שקשורה לחשבונות בעלי מאפיינים זהים לחשבון פעיל, מערכת GCDS מנסה ליצור משתמש עם כתובת אימייל שכבר קיימת כחשבון אישי לא מנוהל, כחשבון לצורכי עבודה לא מנוהל או כמשתמש מנוהל קיים. כדי לפתור את הבעיה, אפשר לעבור אל ניהול חשבונות מתנגשים באמצעות GCDS ואל פתרון שגיאות של חשבונות כפולים. אם השגיאה לא מופיעה בסנכרונים הבאים, סביר להניח שהמטמון של 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 (שכפול המאפיין הזה ל-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.

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

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

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

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

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

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

• שאילתת ה-LDAP מוגדרת בצורה נכונה ב-Configuration Manager – כשמגדירים כלל חיפוש, לוחצים על בדיקת שאילתת 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 כשהם קובעים או מארגנים פגישות.

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

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

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

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

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

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

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