วิธีแก้ปัญหาที่อาจพบในขณะกำหนดค่า Google Cloud Directory Sync (GCDS) มีดังต่อไปนี้
การตั้งค่าและการกำหนดค่า | การจำลองและการซิงค์ | ข้อผิดพลาด | ผู้ใช้และกลุ่ม | รายชื่อติดต่อและปฏิทิน | กฎ
ลองใช้เครื่องมือวิเคราะห์บันทึก
เครื่องมือนี้จะตรวจพบปัญหาส่วนใหญ่ได้โดยใช้เวลาไม่นานหลังการส่ง
- ส่งบันทึกการติดตามของคุณ (ในรูปแบบไฟล์ที่ไม่ได้บีบอัดหรือไฟล์ ZIP) ไปที่เครื่องมือวิเคราะห์บันทึกกล่องเครื่องมือของ Google Admin
- ส่งไฟล์ที่ไม่ได้บีบอัดไปที่เครื่องมือวิเคราะห์บันทึก 2 เพื่อทำการวิเคราะห์บันทึกแบบขั้นสูง
โปรดดูรายละเอียดเกี่ยวกับวิธีเปิดใช้การบันทึกระดับการติดตาม
การตั้งค่าและการกำหนดค่า
แก้ปัญหาการกำหนดค่าโดยใช้เครื่องมือจัดการการกำหนดค่า
หากพบว่าการซิงค์ข้อมูลมีปัญหา โปรดตรวจสอบว่าได้กำหนดค่าในเครื่องมือจัดการการกำหนดค่าไว้อย่างถูกต้องแล้วดูว่าการทดสอบใดที่ดำเนินการไม่สำเร็จ โดยทำตามขั้นตอนดังนี้
- เปิดไฟล์ XML ที่ใช้กำหนดค่าการซิงค์ข้อมูลในเครื่องมือจัดการการกำหนดค่า
- คลิกทดสอบการเชื่อมต่อในหน้าการเชื่อมต่อ LDAP เพื่อตรวจสอบว่าเชื่อมต่อกับเซิร์ฟเวอร์ LDAP ได้
- คลิกทดสอบการแจ้งเตือนในหน้าการแจ้งเตือนเพื่อยืนยันว่าคุณส่งการแจ้งเตือนการทดสอบได้
- คลิกจำลองการซิงค์ในหน้าซิงค์เพื่อยืนยันว่าคุณป้อนข้อมูลในช่องที่จำเป็นทั้งหมดแล้วและเพื่อยืนยันว่าการซิงค์ทำงาน
ฉันจะเปิดการบันทึก HTTP เต็มรูปแบบสำหรับคำขอ API อย่างไร
ในบางกรณีที่พบไม่บ่อยนัก ทีมสนับสนุนอาจขอให้คุณเปิดใช้การบันทึก HTTP อย่างสมบูรณ์ นอกเหนือจากการเปิดใช้การบันทึกที่ระดับการติดตามใน GCDS การบันทึก HTTP อย่างสมบูรณ์จะใช้เพื่อดูคำขอ API โดยเฉพาะซึ่งสร้างโดย GCDS และการตอบกลับโดย API ของ Google
สำคัญ: บันทึก HTTP เต็มรูปแบบอาจมีข้อมูลที่ละเอียดอ่อนอย่างมาก โปรดนำข้อมูลละเอียดอ่อนใดๆ (เช่น ฟิลด์ข้อมูล refresh_token หรือ access_token ปัจจุบัน) ออกก่อนที่จะส่งบันทึกให้ทีมสนับสนุน
วิธีเปิดการบันทึก HTTP อย่างเต็มรูปแบบ
- ตรวจสอบว่า sync-cmd หรือเครื่องมือจัดการการกำหนดค่าไม่ได้กำลังเรียกใช้งาน GCDS อยู่
- ไปที่โฟลเดอร์การติดตั้ง GCDS
-
แก้ไขไฟล์ jre/lib/logging.properties
- เพิ่มบรรทัดต่อไปนี้ที่ส่วนท้ายของไฟล์
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 - บันทึกไฟล์
- ซิงค์ GCDS อีกครั้ง (โดยตั้งค่าการบันทึกเป็นแบบติดตาม)
ระบบจะสร้างไฟล์บันทึกชื่อ gcdshttp*.log ไว้ใน homedir (Linux) หรือโฟลเดอร์โปรไฟล์ (Microsoft Windows) โปรดเก็บไฟล์เหล่านี้ไว้ด้วยกันเนื่องจากไฟล์อาจมีขนาดค่อนข้างใหญ่
- ลบบรรทัดที่เพิ่มไว้ในขั้นตอนที่ 4 เพื่อไม่ให้ระบบสร้างไฟล์ขนาดใหญ่อีกในอนาคต
- ส่งไฟล์ต่อไปนี้ไปยังทีมสนับสนุน
- ไฟล์ XML
- ไฟล์บันทึกระดับการติดตามและไฟล์ gcdshttp*.log จากการซิงค์ล่าสุด
เคล็ดลับ: หากต้องการเปิดใช้การบันทึกสำหรับชั้นเรียนใหม่ ให้เพิ่มบรรทัดในรูปแบบ class.fqdn.level = ALL โดยไม่ต้องทำซ้ำทั้งบล็อกการตั้งค่า
ใช้พร็อกซีการแก้ไขข้อบกพร่อง
เนื้อหาคำขอและคำตอบที่บันทึกไว้จะมีขนาดได้ไม่เกินรายการละ 16 KB หากพบรายการบันทึกที่ถูกตัดทอนออกไปเนื่องจากมีขนาดเกินขีดจำกัดที่กำหนด ให้ใช้พร็อกซีการแก้ไขข้อบกพร่อง เช่น Fiddler
หากต้องการเปิดใช้ Fiddler ให้ทำตามขั้นตอนต่อไปนี้
- ไปที่เส้นทางที่ติดตั้ง GCDS เช่น
C:\Program Files\Google Cloud Directory Sync - เพิ่มแฟล็กต่อไปนี้ลงในไฟล์
.vmoptions(เช่น config-manager.vmoptions หรือ sync-cmd.vmoptions) เพื่อปิดการตรวจสอบ CRL-Dcom.sun.security.enableCRLDP=false-Dcom.sun.net.ssl.checkRevocation=false
รีสตาร์ท GCDS เพื่อให้การเปลี่ยนแปลงมีผล
- กำหนดค่า Fiddler เป็นพร็อกซีในการตั้งค่าพร็อกซีของการกำหนดค่าโดเมน Google ในช่องชื่อโฮสต์ ให้เพิ่มที่อยู่ IP ภายใน
127.0.0.1โดยพอร์ตเริ่มต้นคือ8888แต่คุณยืนยันได้โดยเปิด Fiddler จากนั้นไปที่ Options > Connections แล้วตรวจสอบค่าในช่อง "Fiddler Classiclistens on port"
หากใช้ GCDS ใน Linux คุณจะไม่สามารถใช้ที่เก็บใบรับรองที่เชื่อถือได้ของ Windows ได้ คุณจึงต้องนำเข้าใบรับรองรูทของ Fiddler ไปยัง Java truststore ของ GCDS โปรดดูรายละเอียดเกี่ยวกับขั้นตอนเหล่านี้ที่หัวข้อแก้ปัญหาเกี่ยวกับใบรับรอง
ปัญหาในการตั้งค่าโฮสต์การส่งต่อ SMTP
หากพบปัญหาในการตั้งค่าโฮสต์การส่งต่อ SMTP สำหรับการแจ้งเตือน ให้ลองทำตามขั้นตอนการแก้ปัญหาต่อไปนี้
การเชื่อมต่อล้มเหลวและข้อความโฮสต์ SMTP ที่ไม่รู้จัก
- เปิด Command Prompt
- หากต้องการตรวจสอบว่าชื่อโฮสต์ที่กำหนดค่าของเซิร์ฟเวอร์ SMTP ตรงกับที่อยู่ IP หรือไม่ ให้ป้อนคำสั่งต่อไปนี้
nslookup smtp-host-name.com
การเชื่อมต่อล้มเหลวและเชื่อมต่อกับข้อความโฮสต์ SMTP ไม่ได้
ตรวจสอบว่าเซิร์ฟเวอร์ที่เรียกใช้ GCDS เชื่อมต่อกับโฮสต์ SMTP ได้หรือไม่
- หากต้องการตรวจสอบการเชื่อมต่อ ให้ป้อนคำสั่งต่อไปนี้จากบรรทัดคำสั่งหรือเทอร์มินัลของ Windows
telnet smtp.gmail.com 587
- หากโฮสต์เชื่อมต่อไม่ได้ ให้ตรวจสอบกฎไฟร์วอลล์ขาเข้าของเซิร์ฟเวอร์ SMTP และกฎไฟร์วอลล์ขาออกของเซิร์ฟเวอร์ GCDS
- ตรวจสอบว่าคุณได้อนุญาตการรับส่งข้อมูลในพอร์ต SMTP แล้ว
ข้อผิดพลาด "แปลงซ็อกเก็ตเป็น TLS ไม่ได้" ในบันทึก
ปิดการตรวจสอบรายการยกเลิกใบรับรอง (CRL) โปรดดูรายละเอียดที่หัวข้อวิธีที่ GCDS ตรวจสอบรายการยกเลิกใบรับรอง
ฉันจะเปิดไฟล์ XML ที่บันทึกไว้ในเครื่องอื่นหรือไฟล์ที่ผู้ใช้คนอื่นบันทึกได้อย่างไร
โปรดดูวิธีเปิดไฟล์ XML ที่บันทึกไว้ในเครื่องอื่นหรือไฟล์ที่ผู้ใช้คนอื่นบันทึกลงในเครื่องเดียวกันที่หัวข้อใช้งานไฟล์การกำหนดค่า
ฉันจะส่งออกข้อมูลจากไดเรกทอรี LDAP ได้อย่างไร
หากข้อมูล LDAP ในบันทึกระดับการติดตามของ GCDS ไม่ตรงกับสิ่งที่คุณคาดหวังว่าจะเห็นในเซิร์ฟเวอร์ LDAP (เช่น ไม่พบผู้ใช้หรือแอตทริบิวต์ไม่มีค่าที่ถูกต้อง) ให้ส่งออกข้อมูลจากไดเรกทอรี LDAP ในรูปแบบ LDIF ฝ่ายสนับสนุนจะเปรียบเทียบข้อมูลดังกล่าวกับข้อมูล LDAP ได้จากบันทึกของ GCDS
เมื่อส่งออกข้อมูล ให้ใช้เครื่องมือ Query ของ LDAP เช่น ldapsearch (Linux) หรือ ldifde (Windows) และจําลองเงื่อนไขแบบเดียวกับที่ GCDS ใช้งาน โดยให้ทำดังนี้
- ใช้การตั้งค่าการเชื่อมต่อเดียวกับที่ GCDS กําหนดค่าไว้ใช้
- เรียกใช้เครื่องมือ Query จากเครื่องเดียวกับที่ GCDS ทำงานอยู่
- ใช้ชื่อผู้ใช้เดียวกันสําหรับการตรวจสอบสิทธิ์ LDAP ของ GCDS
ตัวอย่าง
บันทึก GCDS ไม่ได้แสดงแอตทริบิวต์ mail ของผู้ใช้ และการตั้งค่ากฎการค้นหาของ GCDS มีลักษณะดังนี้
- 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
- ภาพหน้าจอของ Command Prompt หรือหน้าต่างเทอร์มินัลที่คุณเรียกใช้คําสั่ง
(อย่าลืมนํารหัสผ่านออกก่อน) - ไฟล์บันทึกระดับการติดตามของ GCDS
การจำลองและการซิงค์
ฉันต้องใช้เซิร์ฟเวอร์การแจ้งเตือนเพื่อจำลองการซิงค์ไหม
หากต้องการจำลองการซิงค์ข้อมูล คุณต้องใช้เซิร์ฟเวอร์ที่ส่งอีเมลได้ หากต้องการใช้งาน GCDS ในเครื่องเซิร์ฟเวอร์อีเมล คุณจะใช้ที่อยู่ IP ของเซิร์ฟเวอร์อีเมลเป็น 127.0.0.1 หรือติดต่อผู้ดูแลระบบอีเมลเพื่อขอข้อมูลอีเมลที่ถูกต้องก็ได้
เพราะเหตุใด GCDS จึงไม่เรียกใช้การซิงค์จากบรรทัดคำสั่ง
หากใช้บรรทัดคำสั่งเพื่อเรียกใช้การซิงค์และการซิงค์ไม่เริ่มขึ้น ให้ตรวจสอบว่าคุณใช้อาร์กิวเมนต์ -o หรือ --oneinstance ในบรรทัดคำสั่ง
หากคุณใช้อาร์กิวเมนต์ดังกล่าว GCDS จะสร้างไฟล์ LOCK (.lock) ที่เชื่อมโยงกับไฟล์การกำหนดค่า XML และหากพบไฟล์ LOCK อื่นในเซิร์ฟเวอร์เดียวกัน GCDS จะไม่เรียกใช้การซิงค์เพื่อป้องกันไม่ให้มีอินสแตนซ์หลายรายการของ GCDS ทำงานพร้อมกัน
หากไม่มีอินสแตนซ์อื่นๆ ของ GCDS ทำงานอยู่ ให้ตรวจหาไฟล์ LOCK อื่นในเซิร์ฟเวอร์ จากนั้นลบไฟล์ด้วยตนเองและลองเรียกใช้การซิงค์อีกครั้ง
การซิงค์ของฉันไม่เสร็จสมบูรณ์ ปัญหานี้อาจเกิดจาก API หรือไม่
หากการซิงค์ไม่สมบูรณ์ เช่น การเป็นสมาชิกทั้งหมดของกลุ่มไม่ได้ซิงค์ แสดงว่า Directory API อาจมีปัญหา หากต้องการยืนยันว่าปัญหาเกี่ยวข้องกับ API หรือผลิตภัณฑ์ GCDS ให้เรียกใช้ Directory API ด้วยตนเองและตรวจสอบผลลัพธ์ หากต้องการเรียก API ด้วยตนเอง ให้เลือก 1 ใน 2 ตัวเลือกดังนี้
ตัวเลือกที่ 1: ใช้หน้าเอกสารอ้างอิง API
- ไปที่ภาพรวมเอกสารอ้างอิง API ของ Admin SDK
- ทางด้านซ้าย ให้คลิก Directory API สำหรับ REST Resources ให้ไปที่ REST Resource ที่ต้องการค้นหา
- ทางด้านขวา ให้คลิกเมธอดที่ต้องการลองใช้ แล้วคลิกลองเลย
หากหน้าเอกสารอ้างอิง API ไม่แสดงตัวเลือกลองใช้เลย ให้ไปที่ตัวเลือกที่ 2: ใช้ OAuth 2.0 Playground
- ป้อนข้อมูลเข้าสู่ระบบของผู้ดูแลระบบที่คุณใช้ให้สิทธิ์ GCDS
โปรดดูรายละเอียดที่หัวข้อกำหนดการตั้งค่าโดเมน Google
- ตรวจสอบข้อมูลเพื่อให้แน่ใจว่า API ตอบกลับตามที่คาดไว้
ตัวเลือกที่ 2: ใช้ OAuth 2.0 Playground
- เปิด OAuth 2.0 Playground
- เลือกตัวเลือกต่อไปนี้
- เลือกขอบเขตจากรายการ
- คัดลอกขอบเขตจากรายการขอบเขตการให้สิทธิ์ในหน้าเอกสารอ้างอิง API จากนั้นวางขอบเขตในช่องป้อนขอบเขตของคุณเอง
- คลิกให้สิทธิ์ API
- ป้อนข้อมูลเข้าสู่ระบบของผู้ดูแลระบบที่คุณใช้ให้สิทธิ์ GCDS
โปรดดูรายละเอียดที่หัวข้อกำหนดการตั้งค่าโดเมน Google
- คลิกเปลี่ยนรหัสการให้สิทธิ์ของโทเค็น
หากการประมวลผลสำเร็จ ระบบจะเปลี่ยนเส้นทางคุณไปยังขั้นตอนที่ 3: กำหนดค่าคำขอไปยัง API
- กรอกข้อมูลที่ขอให้ครบถ้วน
เคล็ดลับ: คุณดูข้อมูลส่วนใหญ่ได้ในหน้าเว็บแหล่งข้อมูลเมธอด API
- คลิกส่งคำขอ
- ตรวจสอบข้อมูลเพื่อให้แน่ใจว่า API ตอบกลับตามที่คาดไว้
ข้อผิดพลาด
ข้อผิดพลาดหรือความขัดแย้งเกี่ยวกับ EntityDoesNotExist/EntityExists เกิดจากอะไร
ตั้งค่าตัวเลือก useDynamicMaxCacheLifetime ในไฟล์การกำหนดค่า XML ตัวเลือกนี้จะกำหนดค่าให้ GCDS แคชข้อมูลได้สูงสุด 8 วัน และจะล้างแคชของชุดข้อมูลขนาดเล็กถึงขนาดกลางให้บ่อยขึ้นเพื่อลดปริมาณข้อมูลเก่าที่ไม่ได้ใช้งาน รวมทั้งลดโอกาสที่ข้อมูลในแคชจะไม่ตรงกับข้อมูลใหม่ด้วย ตัวเลือก useDynamicMaxCacheLifetime จะเปิดใช้งานโดยอัตโนมัติในการกำหนดค่าที่สร้างด้วย GCDS 3.2.1 ขึ้นไป
หมายเหตุ: ข้อผิดพลาดดังกล่าวมักเกิดจากการแก้ไขที่ทำในโดเมนของ Google โดยตรง คุณไม่ควรแก้ไขในโดเมน Google โดยตรงเมื่อใช้ GCDS ในการซิงค์ แต่ให้แก้ไขที่ผู้ใช้ กลุ่ม หรือเอนทิตีอื่นในไดเรกทอรี LDAP แทน จากนั้นจึงใช้ GCDS เพื่อซิงค์การเปลี่ยนแปลงนี้ไปยังโดเมนของ Google
ฉันจะแก้ไขข้อผิดพลาดเกี่ยวกับหน่วยความจำได้อย่างไร
หากคุณพบข้อผิดพลาดเกี่ยวกับหน่วยความจำ ให้เพิ่มขนาดของฮีปสำหรับ Java Virtual Machine โดยให้แก้ไขไฟล์ sync-cmd.vmoptions และ config-manager.vmoptions ในไดเรกทอรีการติดตั้งของ GCDS ไฟล์ที่เกี่ยวข้องจะมีลักษณะดังนี้
-Xmx1000m(ปริมาณหน่วยความจำสูงสุดที่จัดสรรให้กับขนาดฮีป)-Xms64m(ปริมาณหน่วยความจำต่ำสุดที่จัดสรรให้กับขนาดฮีป)
ให้แก้ไขไฟล์ sync-cmd.vmoptions และ config-manager.vmoptions เพื่อให้การเปลี่ยนแปลงนี้มีผลทั้งจากการใช้ผ่าน sync-cmd หรือเครื่องมือจัดการการกำหนดค่า
แก้ไขตัวเลข -Xmx เพื่อเพิ่มปริมาณหน่วยความจำ "m" ที่ต่อท้ายตัวเลขคือหน่วยความจำที่มีหน่วยเป็นเมกะไบต์ (MB) จำนวนหน่วยความจำที่เหมาะสมจะขึ้นอยู่กับหน่วยความจำที่เซิร์ฟเวอร์ GCDS มี และจำนวนที่ต้องใช้สำหรับการซิงค์ข้อมูล คุณอาจต้องแก้ไขตัวเลขไปเรื่อยๆ จนกว่าจะได้ขนาดที่เหมาะสม หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับปริมาณพื้นที่ว่างของ RAM ที่จำเป็นสำหรับการใช้งาน GCDS โปรดดูหัวข้อข้อกำหนดของระบบสำหรับ GCDS
ทำไม GCDS จึงแจ้งข้อผิดพลาดซ้ำๆ เมื่อปิดแคชแล้ว
ปัญหาอาจเกิดจากปัญหาด้านการกำหนดค่า เช่น การกำหนดค่ากฎการยกเว้นไม่ถูกต้อง โดยการแคชของ GCDS อาจซ่อนการกำหนดค่าที่ไม่ถูกต้องประเภทนี้ได้
GCDS จะเก็บแคชของข้อมูลสำหรับบริการของ Google (เช่น Google Workspace หรือ Cloud Identity) ไว้นานสูงสุด 8 วัน ทั้งนี้ GCDS อาจล้างแคชบ่อยขึ้นโดยขึ้นอยู่กับขนาดของข้อมูลที่แคชไว้ แต่หากไม่มีการล้างแคช คุณอาจไม่เห็นอัปเดตนานถึง 8 วัน
เช่น คุณซิงค์ข้อมูล LDAP แล้วสร้างกลุ่มใหม่สำหรับบริการของ Google (เช่น Google Workspace หรือ Cloud Identity) จากนั้นจึงสร้างกฎการยกเว้นเพื่อให้ไม่ต้องซิงค์กลุ่มนั้นอีก กฎการยกเว้นแบบนี้ไม่ถูกต้องและจะใช้ไม่ได้ แต่การซิงค์ครั้งต่อไปนี้จะเรียกข้อมูลที่แคชไว้และกลุ่มดังกล่าวจะยังอยู่ในบริการของ Google เหมือนเดิม เมื่อซิงค์อีกครั้งตอนที่ล้างแคชไปแล้ว การกำหนดค่าที่ไม่ถูกต้องนี้จะทำให้ระบบนำกลุ่มออกจากบริการของ Google
วิธีล้างแคชด้วยตัวเอง
- ซิงค์จากเครื่องมือจัดการการกำหนดค่า แล้วเลือกตัวเลือกที่ล้างแคชเมื่อซิงค์
- ซิงค์จากคำสั่งและใช้อาร์กิวเมนต์ -f เพื่อบังคับให้ล้างแคช
- แก้ไขไฟล์การกำหนดค่า XML เพื่อตั้งค่า maxCacheLifetime เป็น 0
ข้อสำคัญ: การบังคับให้ล้างแคชอาจทำให้ใช้เวลาในการซิงค์นานขึ้นมาก
ผู้ใช้และกลุ่ม
ทำไม GCDS จึงพยายามสร้างผู้ใช้ Google ที่มีอยู่แล้ว
หากคุณได้รับข้อผิดพลาด 409: มีเอนทิตีนี้อยู่แล้ว แสดงว่า GCDS กำลังพยายามสร้างผู้ใช้ Google ที่มีอยู่แล้ว หากคุณไม่เห็นข้อผิดพลาดในการซิงค์ครั้งต่อๆ ไป อาจเป็นเพราะแคชของ GCDS นั้นล้าสมัย และคุณจะข้ามข้อผิดพลาดดังกล่าวไปก็ได้
หากปัญหาเกิดขึ้นในทุกๆ การซิงค์หรือทุกๆ หลายวัน สาเหตุที่เป็นไปได้มากที่สุดมีดังนี้
- กฎการยกเว้นผู้ใช้ Google นั้นกว้างเกินไป ซึ่งจะทำให้กฎจับคู่ผู้ใช้ Google บางรายที่มีอยู่ในไดเรกทอรี LDAP ด้วย
- คำค้นหานั้นแคบเกินไป ซึ่งจะทำให้คำค้นหาดังกล่าวไม่จับคู่กับผู้ใช้ Google บางรายที่มีอยู่ในไดเรกทอรี LDAP ด้วย
ทั้ง 2 กรณีข้างต้นอาจทำให้ GCDS ยกเว้นผู้ใช้ Google ที่มีอยู่แล้วได้ หากผู้ใช้ดังกล่าวปรากฏในผลลัพธ์ของกฎการค้นหาผู้ใช้ LDAP เครื่องมือ GCDS จะพยายามสร้างผู้ใช้ในบัญชี Google ของคุณ
หากต้องการแก้ไขปัญหานี้ ให้ปรับกฎการยกเว้นหรือคำค้นหา หรือหากต้องการให้ GCDS ยกเว้นผู้ใช้ในไดเรกทอรี LDAP โดยสิ้นเชิง คุณก็สามารถปรับกฎการค้นหาผู้ใช้ LDAP หรือสร้างกฎการยกเว้นผู้ใช้ LDAP ได้ โปรดดูรายละเอียดที่หัวข้อยกเว้นข้อมูลด้วยกฎการยกเว้นและการค้นหา
ทำไมระบบจึงไม่ซิงค์ผู้ใช้บางรายเป็นสมาชิกกลุ่ม
GCDS เปิด INDEPENDENT_GROUP_SYNC โดยค่าเริ่มต้นเพื่อซิงค์ข้อมูลสมาชิกกลุ่มโดยแยกจากผลลัพธ์ของกฎการค้นหาผู้ใช้ หากคุณใช้แอตทริบิวต์การอ้างอิงสมาชิกเพื่อซิงค์ข้อมูลกลุ่ม GCDS จะพยายามหาอีเมลของผู้ใช้ทุกรายในไดเรกทอรี LDAP โดยไม่คำนึงถึงกฎการค้นหาผู้ใช้
หากต้องการซิงค์ข้อมูลสมาชิกกลุ่มตามผลลัพธ์ของกฎการค้นหาผู้ใช้เท่านั้น ให้นำ INDEPENDENT_GROUP_SYNC ออกจากไฟล์ XML ของการกำหนดค่า GCDS ทำสิ่งต่อไปนี้
- ใช้ผลลัพธ์ของกฎการค้นหาผู้ใช้เพื่อแก้ปัญหาการเป็นสมาชิกกลุ่ม
- ซิงค์เป็นสมาชิกกลุ่มที่ผู้ใช้ดังกล่าวรวมอยู่ในการซิงค์ผู้ใช้เท่านั้น
- ใช้กฎการค้นหาผู้ใช้ แม้ว่าคุณจะปิดการซิงค์บัญชีผู้ใช้ในการตั้งค่าทั่วไปก็ตาม
(ผลลัพธ์จะไม่ซิงค์กับ Google เป็นผู้ใช้ แต่เป็นสมาชิกกลุ่ม หากผู้ใช้ที่มีสิทธิ์ถือว่าเป็นสมาชิกกลุ่มด้วย)
ปกติแล้วเราจะไม่แนะนำให้ซิงค์ด้วยวิธีนี้ โดยเฉพาะกรณีที่คุณซิงค์รายชื่อติดต่อที่แชร์และมีสมาชิกกลุ่มที่อยู่ในรายชื่อติดต่อ ในกรณีนี้ รายชื่อติดต่อจะไม่ซิงค์ข้อมูลเป็นสมาชิกกลุ่ม
ทำไมระบบจึงสร้างผู้ใช้บางรายหรือบางกลุ่มขึ้นมาใหม่ทุกครั้งที่ซิงค์
ปัญหานี้จะเกิดขึ้นเมื่อแอตทริบิวต์ LDAP ที่กำหนดค่าเป็นแอตทริบิวต์ชื่อกลุ่มไม่มีอีเมลแบบเต็ม คุณจะแก้ไขปัญหานี้ได้โดยตรวจสอบกฎการค้นหากลุ่มของคุณ และตรวจสอบว่า GCDS ใช้อีเมลแบบเต็มสำหรับชื่อกลุ่ม โดยใช้วิธีการใดวิธีการหนึ่งต่อไปนี้
- ตั้งค่าแอตทริบิวต์ชื่อกลุ่มเป็นแอตทริบิวต์ LDAP อื่นที่ระบุอีเมลแบบเต็มสำหรับแต่ละกลุ่ม เช่น อีเมล
- เปิดแทนที่ชื่อโดเมนในอีเมล LDAP ในการตั้งค่าโดเมน Google เพื่อให้แอตทริบิวต์ชื่อกลุ่มตรงกับชื่อกลุ่มของด้าน Google
- เพิ่มชื่อโดเมนไปยังชื่อกลุ่มโดยระบุค่าต่อท้ายชื่อกลุ่มในกฎการค้นหากลุ่ม
กลุ่มใน Active Directory ที่มีสมาชิกมากกว่า 1,500 คนจะไม่ได้รับการซิงค์อย่างถูกต้อง
ตรวจสอบว่าคุณเลือกฟิลด์ประเภทของเซิร์ฟเวอร์ในส่วนของการกำหนดค่า LDAP ให้เป็น 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
ผลลัพธ์ของการค้นหา LDAP จะขึ้นอยู่กับการตั้งค่าเครื่องมือจัดการการกำหนดค่าและเซิร์ฟเวอร์ LDAP โปรดใช้เคล็ดลับการแก้ปัญหาต่อไปนี้หากกฎการค้นหา LDAP แสดงผลลัพธ์ที่ไม่คาดคิด ตรวจสอบดังนี้
- การค้นหา LDAP ได้รับการตั้งค่าอย่างถูกต้องในเครื่องมือจัดการการกําหนดค่า - เมื่อคุณตั้งค่ากฎการค้นหา ให้คลิกทดสอบการค้นหา LDAP เพื่อยืนยัน โปรดดูรายละเอียดที่หัวข้อใช้กฎการค้นหา LDAP เพื่อซิงค์ข้อมูล
- การค้นหาหลายรายการไม่ขัดแย้งกัน - ตรวจสอบว่าคุณไม่ได้ตั้งค่ากฎการค้นหาหรือกฎการยกเว้นที่เปลี่ยนผลลัพธ์ของการค้นหา
- ผู้ใช้ที่ได้รับอนุญาตสําหรับเซิร์ฟเวอร์ LDAP มีสิทธิ์เพียงพอ โปรดตรวจสอบว่าผู้ดูแลระบบที่ทำหน้าที่ตรวจสอบสิทธิ์เซิร์ฟเวอร์ LDAP สามารถใช้บรรทัดคําสั่งในเซิร์ฟเวอร์เดียวกันได้ ลองทำการค้นหาในเซิร์ฟเวอร์ LDAP และยืนยันผลลัพธ์
ข้อผิดพลาดระบุว่าสร้างกลุ่มไม่ได้
คุณอาจได้รับข้อความแสดงข้อผิดพลาดว่าสร้างกลุ่ม ... ไม่ได้ ข้อความ: ไม่ได้รับสิทธิ์ให้เข้าถึงทรัพยากร/API นี้ในบันทึกของ GCDS
หากต้องการแก้ปัญหา ให้ตรวจสอบว่าแอตทริบิวต์ Active Directory (AD) ที่มีโดเมนสำหรับอีเมลของผู้ใช้และกลุ่มตรงกับโดเมนที่บัญชีผู้ดูแลระบบขั้นสูงใช้หรือไม่
รายชื่อติดต่อและปฏิทิน
ทำไมจึงมีรายชื่อติดต่อซ้ำกันในไดเรกทอรีของโดเมนหลังจากซิงค์กับ GCDS
ปัญหานี้มักเกิดขึ้นเมื่อคุณซิงค์รายชื่อติดต่อที่ใช้ร่วมกัน รวมทั้งกำหนดกฎการค้นหาไม่ถูกต้อง
ออบเจกต์ที่เกี่ยวข้องซึ่งคุณจะซิงค์กับ GCDS ได้มี 2 ประเภทดังนี้
- โปรไฟล์ผู้ใช้ - ผู้ใช้ในโดเมน Google ของคุณที่มีข้อมูลอื่นเพิ่มเข้ามา เช่น หมายเลขโทรศัพท์และที่อยู่ คุณจะซิงค์ได้เฉพาะโปรไฟล์ของผู้ใช้ที่อยู่ในโดเมนเท่านั้น
- รายชื่อติดต่อที่ใช้ร่วมกัน - รายชื่อติดต่อของบุคคลภายนอกที่ผู้ใช้ในโดเมนจำเป็นต้องใช้
หากต้องการแก้ไขปัญหานี้ ให้ปรับกฎการค้นหารายชื่อติดต่อที่ใช้ร่วมกันเพื่อยกเว้นผู้ใช้ในโดเมน เมื่อซิงค์ครั้งถัดไป GCDS จะพยายามลบรายชื่อติดต่อที่ซ้ำกันออก คุณอาจต้องปรับข้อจำกัดในการลบรายชื่อติดต่อที่ใช้ร่วมกันสำหรับการซิงค์ครั้งแรก
ทำไมผู้ใช้บางรายจึงมองไม่เห็นสถานที่ทำงานหลักของตนเองใน Google ปฏิทิน
ผู้ใช้อาจมองไม่เห็นสถานที่ทำงานหลักของตนเองใน Google ปฏิทินในขณะที่กำลังวางกำหนดการหรือจัดการประชุมได้เป็นบางครั้ง
หากพบปัญหานี้ โปรดตรวจสอบว่าได้ตั้งค่าประเภทสถานที่และแอตทริบิวต์ของพื้นที่ให้เป็น "โต๊ะทำงาน"
กฎ
ทำไมกฎการค้นหาจึงไม่พบผลลัพธ์ใดๆ เลย
หากคุณประสบปัญหาเกี่ยวกับผลการค้นหา ให้ตรวจสอบดังนี้
- ขอบเขตของกฎ คุณอาจต้องตั้งค่าขอบเขตให้เป็น Sub-tree
- กฎการค้นหาที่คุณใช้อยู่ถูกต้องแล้ว
- แอตทริบิวต์ที่ใช้มีอยู่และมองเห็นได้
การค้นหา LDAP ตรวจสอบว่าการค้นหาในเซิร์ฟเวอร์ LDAP ใช้ชื่อผู้ใช้ของผู้ดูแลระบบชื่อเดียวกับที่กำหนดค่าไว้ใน GCDS
โปรดดูรายละเอียดที่หัวข้อใช้กฎการค้นหา LDAP เพื่อซิงค์ข้อมูล
ทำไมฉันจึงไม่เห็นปุ่ม "ตกลง" เมื่อสร้างกฎการยกเว้น
คุณอาจใช้แบบอักษรที่ใหญ่เกินไปสำหรับหน้าจอ กล่องโต้ตอบใช้ไม่ได้กับแบบอักษรขนาดใหญ่หรือใหญ่มาก ให้เปลี่ยนขนาดแบบอักษรหรือแก้ไขไฟล์ XML โดยตรง
หัวข้อที่เกี่ยวข้อง
ปัญหาที่ทราบเกี่ยวกับ Google Workspace
Google, Google Workspace รวมถึงเครื่องหมายและโลโก้ที่เกี่ยวข้องเป็นเครื่องหมายการค้าของ Google LLC ชื่อบริษัทและชื่อผลิตภัณฑ์อื่นๆ ทั้งหมดเป็นเครื่องหมายการค้าของ บริษัทที่เกี่ยวข้อง