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

השגיאה Could not convert socket to 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
• היקף: Subtree
• מסנן חיפוש: (&(objectCategory=person)(objectClass=user))
• השרת: dc01.altostrat.com
• יציאה: 636
• פרוטוקול: LDAP+SSL
• Authentication user 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 באופן ידני, אפשר לבחור אחת מ-2 אפשרויות.

אפשרות 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.
4. מזינים את פרטי הכניסה של האדמין שבהם השתמשתם כדי לתת הרשאה ל-GCDS.

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

5. לוחצים על המרת קוד הרשאה לטוקנים.

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

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

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

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

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

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

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

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